From erik.joelsson at oracle.com Tue Oct 1 01:35:09 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 01 Oct 2013 10:35:09 +0200 Subject: [7u] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol In-Reply-To: <524A6004.1020904@oracle.com> References: <524A6004.1020904@oracle.com> Message-ID: <524A893D.4000706@oracle.com> Build part looks ok. /Erik On 2013-10-01 07:39, dmitry markov wrote: > Hello, > > Could you review a back-port of 7129133 to JDK 7u, please? The > back-port and the main fix integrated into jdk8 are slightly different. > > bug: http://bugs.sun.com/view_bug.do?bug_id=7129133 > webrev for jdk7u: http://cr.openjdk.java.net/~dmarkov/7129133/webrev.00/ > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/602e5d0141d3 > technical review for jdk8: > http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005450.html > > Thanks, > Dmitry From konstantin.shefov at oracle.com Tue Oct 1 02:20:17 2013 From: konstantin.shefov at oracle.com (konstantin.shefov at oracle.com) Date: Tue, 01 Oct 2013 09:20:17 +0000 Subject: hg: jdk8/awt/jdk: 7125471: [macosx] NofocusListDblClickTest should wait between doublr clicks Message-ID: <20131001092147.6301B62C2D@hg.openjdk.java.net> Changeset: 2d8418d68a3c Author: kshefov Date: 2013-10-01 13:19 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2d8418d68a3c 7125471: [macosx] NofocusListDblClickTest should wait between doublr clicks Reviewed-by: anthony, serb Contributed-by: vera.akulova at oracle.com + test/java/awt/List/NofocusListDblClickTest/NofocusListDblClickTest.java From konstantin.shefov at oracle.com Tue Oct 1 02:32:41 2013 From: konstantin.shefov at oracle.com (konstantin.shefov at oracle.com) Date: Tue, 01 Oct 2013 09:32:41 +0000 Subject: hg: jdk8/awt/jdk: 8012468: [TEST_BUG] javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java doesn't release mouse button Message-ID: <20131001093647.211A962C2E@hg.openjdk.java.net> Changeset: 329011aad090 Author: kshefov Date: 2013-10-01 13:30 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/329011aad090 8012468: [TEST_BUG] javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java doesn't release mouse button Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com ! test/javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java From konstantin.shefov at oracle.com Tue Oct 1 02:39:01 2013 From: konstantin.shefov at oracle.com (konstantin.shefov at oracle.com) Date: Tue, 01 Oct 2013 09:39:01 +0000 Subject: hg: jdk8/awt/jdk: 8012466: [TEST_BUG] javax/swing/JInternalFrame/Test6505027.java doesn't release mouse button Message-ID: <20131001093919.5064B62C30@hg.openjdk.java.net> Changeset: 0887aad989fb Author: kshefov Date: 2013-10-01 13:38 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0887aad989fb 8012466: [TEST_BUG] javax/swing/JInternalFrame/Test6505027.java doesn't release mouse button Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com ! test/javax/swing/JInternalFrame/Test6505027.java From konstantin.shefov at oracle.com Tue Oct 1 02:41:00 2013 From: konstantin.shefov at oracle.com (konstantin.shefov at oracle.com) Date: Tue, 01 Oct 2013 09:41:00 +0000 Subject: hg: jdk8/awt/jdk: 8004294: [TEST_BUG] javax/swing/JSpinner/4973721/bug4973721.java failed on win2003 Message-ID: <20131001094112.3732562C31@hg.openjdk.java.net> Changeset: 1043bd1f7fca Author: kshefov Date: 2013-10-01 13:40 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1043bd1f7fca 8004294: [TEST_BUG] javax/swing/JSpinner/4973721/bug4973721.java failed on win2003 Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSpinner/4973721/bug4973721.java From konstantin.shefov at oracle.com Tue Oct 1 02:48:40 2013 From: konstantin.shefov at oracle.com (konstantin.shefov at oracle.com) Date: Tue, 01 Oct 2013 09:48:40 +0000 Subject: hg: jdk8/awt/jdk: 3 new changesets Message-ID: <20131001094936.10A0662C32@hg.openjdk.java.net> Changeset: 68157255f3eb Author: kshefov Date: 2013-10-01 13:45 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/68157255f3eb 8012461: [TEST_BUG] closed/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java doesn't release mouse button Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java + test/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.xml Changeset: 172405287fde Author: kshefov Date: 2013-10-01 13:46 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/172405287fde 7133545: [macosx] closed/javax/swing/JSplitPane/4514858/bug4514858.java fails on MacOS Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSplitPane/4514858/bug4514858.java Changeset: 291e66f4cb83 Author: kshefov Date: 2013-10-01 13:47 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/291e66f4cb83 7133532: [macosx] closed/javax/swing/JScrollBar/bug4202954/bug4202954.java fails on MacOS Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JScrollBar/bug4202954/bug4202954.java From leonid.romanov at oracle.com Tue Oct 1 03:35:51 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 01 Oct 2013 14:35:51 +0400 Subject: [7u] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol In-Reply-To: <524A6004.1020904@oracle.com> References: <524A6004.1020904@oracle.com> Message-ID: <524AA587.4050304@oracle.com> I'm not sure whether I'm allowed to review the backport of my own fix, but anyway, it looks good. On 10/1/2013 9:39, dmitry markov wrote: > Hello, > > Could you review a back-port of 7129133 to JDK 7u, please? The > back-port and the main fix integrated into jdk8 are slightly different. > > bug: http://bugs.sun.com/view_bug.do?bug_id=7129133 > webrev for jdk7u: http://cr.openjdk.java.net/~dmarkov/7129133/webrev.00/ > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/602e5d0141d3 > technical review for jdk8: > http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005450.html > > Thanks, > Dmitry From konstantin.shefov at oracle.com Tue Oct 1 03:39:59 2013 From: konstantin.shefov at oracle.com (konstantin.shefov at oracle.com) Date: Tue, 01 Oct 2013 10:39:59 +0000 Subject: hg: jdk8/awt/jdk: 8025707: Frogot to add a file to fix for JDK-8012461 Message-ID: <20131001104024.455C962C37@hg.openjdk.java.net> Changeset: 560ede42bd2e Author: kshefov Date: 2013-10-01 14:38 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/560ede42bd2e 8025707: Frogot to add a file to fix for JDK-8012461 Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/plaf/synth/SynthButtonUI/6276188/red.gif From Sergey.Bylokhov at oracle.com Tue Oct 1 03:41:53 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 01 Oct 2013 14:41:53 +0400 Subject: [8] Review request for 8025145: MacOSX: java 7 does not recognize tiff image on clipboard In-Reply-To: <523C5F0D.1000106@oracle.com> References: <523C5F0D.1000106@oracle.com> Message-ID: <524AA6F1.2070304@oracle.com> Hi, Anton. The fix looks good. On 20.09.2013 18:43, anton nashatyrev wrote: > Hello, > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~vkarnauk/8025145/jdk8/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8025145 > > Problem: it looks like the TIFF format is popular in the MacOS: > several programs when copying images to clipboard put there only a > TIFF data flavor. Though the datatransfer and macos native code > supports the TIFF format, it couldn't be used since it's missing in > flavormap.properties. > > Fix: add TIFF entry to the macos flavormap.properties. > > Thanks! > Anton. -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Oct 1 04:29:44 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 15:29:44 +0400 Subject: [8] Review request for 7033533: realSync() doesn't work with Xfce In-Reply-To: <5243E8C4.7060004@oracle.com> References: <5242D93C.4070809@oracle.com> <5242EEF6.2010609@oracle.com> <5243E8C4.7060004@oracle.com> Message-ID: <524AB228.80803@oracle.com> Hi Oleg, I second to Leonid: you should add a comment and explain why you expect exactly 4 (or more) events to be processed. Preferably, you should list each event to clearly understand this. A minor comment is, lines 2404 - 2407 should be moved to the nearest try{} block at line 2409. A major concern is that I'm not sure the new solution is reliable in all cases. Previously, we expected to get a notification from another process (the WM). Now we process the notification ourselves and are the owners of the selection. I don't know for sure, but suppose some xlib implementations could optimize this scenario and process events locally w/o even sending them to the X server. In which case there wouldn't be any real synchronization of the native event queue. That's why communicating with another process was an important part of this procedure. How about we try the original method first, and only if it fails, then try this workaround solution? Also, this is a very sensitive method because a lot of code relies on it. I suggest running all automatic regression tests for AWT and Swing areas to make sure we don't introduce a regression with this fix. -- best regards, Anthony On 09/26/2013 11:56 AM, Oleg Pekhovskiy wrote: > Hi Leonid, > > I did it mostly logically, because my fix added one more service event > (SelectionRequest), that should be excluded from the number of > dispatched native events. > IMHO, the previous number "2" should have been commented, but, that did > not happen. > > Thanks, > Oleg > > On 25.09.2013 18:11, Leonid Romanov wrote: >> Hi, >> I'm not an expert in X11 programming, so I can't comment about the fix >> in general, but I think the line 2436, "return getEventNumber() - >> event_number > 3", really asks for a comment. >> >> On 9/25/2013 16:38, Oleg Pekhovskiy wrote: >>> Hi all, >>> >>> please review the fix >>> http://cr.openjdk.java.net/~bagiras/7033533.1/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-7033533 >>> >>> Previous implementation of XToolkit.syncNativeQueue() relied upon >>> WM_S0 atom existence and that it was owned by current window manager. >>> But several WMs (like XFCE and LXDE) don't send SelectionNotify event >>> to the client on XConvertSelection() for that atom. That led >>> XToolkit.syncNativeQueue() to hang until TimeOutException. >>> >>> I decided to keep XConvertSelection() usage, but make root toolkit >>> window as an owner for selection atom (with another name), and handle >>> SelectionRequest event from X Server, sending SelectionNotify in >>> response (as window manager is supposed to do). >>> >>> Tested on both XFCE and LXDE. >>> >>> Thanks, >>> Oleg >> From leonid.romanov at oracle.com Tue Oct 1 05:01:42 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 01 Oct 2013 16:01:42 +0400 Subject: [8] Review request for 7033533: realSync() doesn't work with Xfce In-Reply-To: <524AB228.80803@oracle.com> References: <5242D93C.4070809@oracle.com> <5242EEF6.2010609@oracle.com> <5243E8C4.7060004@oracle.com> <524AB228.80803@oracle.com> Message-ID: <524AB9A6.8040500@oracle.com> By the way, I was reading Inter-Client Communication Conventions Manual so I could better understand the fix, and found the following: "4.3. Communication with the Window Manager by Means of Selections For each screen they manage, window managers will acquire ownership of a selection named WM_Sn, where n is the screen number, as described in section 1.2.6. Window managers should comply with the conventions for "Manager Selections" described in section 2.8. The intent is for clients to be able to request a variety of information or services by issuing conversion requests on this selection." Considering this, can we say that Xfce is not complying to the spec? On 10/1/2013 15:29, Anthony Petrov wrote: > Hi Oleg, > > I second to Leonid: you should add a comment and explain why you > expect exactly 4 (or more) events to be processed. Preferably, you > should list each event to clearly understand this. > > A minor comment is, lines 2404 - 2407 should be moved to the nearest > try{} block at line 2409. > > A major concern is that I'm not sure the new solution is reliable in > all cases. Previously, we expected to get a notification from another > process (the WM). Now we process the notification ourselves and are > the owners of the selection. I don't know for sure, but suppose some > xlib implementations could optimize this scenario and process events > locally w/o even sending them to the X server. In which case there > wouldn't be any real synchronization of the native event queue. That's > why communicating with another process was an important part of this > procedure. > > How about we try the original method first, and only if it fails, then > try this workaround solution? > > Also, this is a very sensitive method because a lot of code relies on > it. I suggest running all automatic regression tests for AWT and Swing > areas to make sure we don't introduce a regression with this fix. > > -- > best regards, > Anthony > > On 09/26/2013 11:56 AM, Oleg Pekhovskiy wrote: >> Hi Leonid, >> >> I did it mostly logically, because my fix added one more service event >> (SelectionRequest), that should be excluded from the number of >> dispatched native events. >> IMHO, the previous number "2" should have been commented, but, that did >> not happen. >> >> Thanks, >> Oleg >> >> On 25.09.2013 18:11, Leonid Romanov wrote: >>> Hi, >>> I'm not an expert in X11 programming, so I can't comment about the fix >>> in general, but I think the line 2436, "return getEventNumber() - >>> event_number > 3", really asks for a comment. >>> >>> On 9/25/2013 16:38, Oleg Pekhovskiy wrote: >>>> Hi all, >>>> >>>> please review the fix >>>> http://cr.openjdk.java.net/~bagiras/7033533.1/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-7033533 >>>> >>>> Previous implementation of XToolkit.syncNativeQueue() relied upon >>>> WM_S0 atom existence and that it was owned by current window manager. >>>> But several WMs (like XFCE and LXDE) don't send SelectionNotify event >>>> to the client on XConvertSelection() for that atom. That led >>>> XToolkit.syncNativeQueue() to hang until TimeOutException. >>>> >>>> I decided to keep XConvertSelection() usage, but make root toolkit >>>> window as an owner for selection atom (with another name), and handle >>>> SelectionRequest event from X Server, sending SelectionNotify in >>>> response (as window manager is supposed to do). >>>> >>>> Tested on both XFCE and LXDE. >>>> >>>> Thanks, >>>> Oleg >>> From yuri.nesterenko at oracle.com Tue Oct 1 05:27:50 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Tue, 01 Oct 2013 16:27:50 +0400 Subject: [8] Review request for 7033533: realSync() doesn't work with Xfce In-Reply-To: <524AB9A6.8040500@oracle.com> References: <5242D93C.4070809@oracle.com> <5242EEF6.2010609@oracle.com> <5243E8C4.7060004@oracle.com> <524AB228.80803@oracle.com> <524AB9A6.8040500@oracle.com> Message-ID: <524ABFC6.8000200@oracle.com> Sure we can say that Xfce is not complying -- it is not officially supported by JDK -- neither is LXDE etc. -- but saying that gets us nowhere. As to testing, could you suggest a platform selection? I'm afraid we'll not be able to test Xsun properly but Xorg with Gnome on Linux and Solaris, Unity and Xfce4 -- all that we can do by the weekend. Thanks, -yan On 10/01/2013 04:01 PM, Leonid Romanov wrote: > By the way, I was reading Inter-Client Communication Conventions Manual > so I could better understand the fix, and found the following: > > "4.3. Communication with the Window Manager by Means of Selections > > For each screen they manage, window managers will acquire ownership of a > selection named WM_Sn, where n is the screen number, as described in > section 1.2.6. Window managers should comply with the conventions for > "Manager Selections" described in section 2.8. The intent is for clients > to be able to request a variety of information or services by issuing > conversion requests on this selection." > > Considering this, can we say that Xfce is not complying to the spec? > > On 10/1/2013 15:29, Anthony Petrov wrote: >> Hi Oleg, >> >> I second to Leonid: you should add a comment and explain why you >> expect exactly 4 (or more) events to be processed. Preferably, you >> should list each event to clearly understand this. >> >> A minor comment is, lines 2404 - 2407 should be moved to the nearest >> try{} block at line 2409. >> >> A major concern is that I'm not sure the new solution is reliable in >> all cases. Previously, we expected to get a notification from another >> process (the WM). Now we process the notification ourselves and are >> the owners of the selection. I don't know for sure, but suppose some >> xlib implementations could optimize this scenario and process events >> locally w/o even sending them to the X server. In which case there >> wouldn't be any real synchronization of the native event queue. That's >> why communicating with another process was an important part of this >> procedure. >> >> How about we try the original method first, and only if it fails, then >> try this workaround solution? >> >> Also, this is a very sensitive method because a lot of code relies on >> it. I suggest running all automatic regression tests for AWT and Swing >> areas to make sure we don't introduce a regression with this fix. >> >> -- >> best regards, >> Anthony >> >> On 09/26/2013 11:56 AM, Oleg Pekhovskiy wrote: >>> Hi Leonid, >>> >>> I did it mostly logically, because my fix added one more service event >>> (SelectionRequest), that should be excluded from the number of >>> dispatched native events. >>> IMHO, the previous number "2" should have been commented, but, that did >>> not happen. >>> >>> Thanks, >>> Oleg >>> >>> On 25.09.2013 18:11, Leonid Romanov wrote: >>>> Hi, >>>> I'm not an expert in X11 programming, so I can't comment about the fix >>>> in general, but I think the line 2436, "return getEventNumber() - >>>> event_number > 3", really asks for a comment. >>>> >>>> On 9/25/2013 16:38, Oleg Pekhovskiy wrote: >>>>> Hi all, >>>>> >>>>> please review the fix >>>>> http://cr.openjdk.java.net/~bagiras/7033533.1/ >>>>> for >>>>> https://bugs.openjdk.java.net/browse/JDK-7033533 >>>>> >>>>> Previous implementation of XToolkit.syncNativeQueue() relied upon >>>>> WM_S0 atom existence and that it was owned by current window manager. >>>>> But several WMs (like XFCE and LXDE) don't send SelectionNotify event >>>>> to the client on XConvertSelection() for that atom. That led >>>>> XToolkit.syncNativeQueue() to hang until TimeOutException. >>>>> >>>>> I decided to keep XConvertSelection() usage, but make root toolkit >>>>> window as an owner for selection atom (with another name), and handle >>>>> SelectionRequest event from X Server, sending SelectionNotify in >>>>> response (as window manager is supposed to do). >>>>> >>>>> Tested on both XFCE and LXDE. >>>>> >>>>> Thanks, >>>>> Oleg >>>> > From oleg.pekhovskiy at oracle.com Tue Oct 1 05:37:40 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Tue, 01 Oct 2013 16:37:40 +0400 Subject: [8] Review request for 7068423: Spec for java.awt.GraphicsDevice.getFullScreenWindow() needs clarification Message-ID: <524AC214.3000806@oracle.com> Hi all, please review the fix http://cr.openjdk.java.net/~bagiras/7068423.1/ for https://bugs.openjdk.java.net/browse/JDK-7068423 It's just a Javadoc fix. Thanks, Oleg From leonid.romanov at oracle.com Tue Oct 1 05:38:11 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 01 Oct 2013 16:38:11 +0400 Subject: [8] Review request for 7033533: realSync() doesn't work with Xfce In-Reply-To: <524ABFC6.8000200@oracle.com> References: <5242D93C.4070809@oracle.com> <5242EEF6.2010609@oracle.com> <5243E8C4.7060004@oracle.com> <524AB228.80803@oracle.com> <524AB9A6.8040500@oracle.com> <524ABFC6.8000200@oracle.com> Message-ID: <524AC233.9090009@oracle.com> I agree with you, but it would change our approach to the fix: for instance, we might want to use the new realSync() version for Xfce only. Also, we should a bug in Xfce bug tracking system then. On 10/1/2013 16:27, Yuri Nesterenko wrote: > Sure we can say that Xfce is not complying -- it is not officially > supported by JDK -- neither is LXDE etc. -- but saying that gets > us nowhere. > > As to testing, could you suggest a platform selection? I'm afraid > we'll not be able to test Xsun properly but Xorg with Gnome on > Linux and Solaris, Unity and Xfce4 -- > all that we can do by the weekend. > > Thanks, > -yan > > On 10/01/2013 04:01 PM, Leonid Romanov wrote: >> By the way, I was reading Inter-Client Communication Conventions Manual >> so I could better understand the fix, and found the following: >> >> "4.3. Communication with the Window Manager by Means of Selections >> >> For each screen they manage, window managers will acquire ownership of a >> selection named WM_Sn, where n is the screen number, as described in >> section 1.2.6. Window managers should comply with the conventions for >> "Manager Selections" described in section 2.8. The intent is for clients >> to be able to request a variety of information or services by issuing >> conversion requests on this selection." >> >> Considering this, can we say that Xfce is not complying to the spec? >> >> On 10/1/2013 15:29, Anthony Petrov wrote: >>> Hi Oleg, >>> >>> I second to Leonid: you should add a comment and explain why you >>> expect exactly 4 (or more) events to be processed. Preferably, you >>> should list each event to clearly understand this. >>> >>> A minor comment is, lines 2404 - 2407 should be moved to the nearest >>> try{} block at line 2409. >>> >>> A major concern is that I'm not sure the new solution is reliable in >>> all cases. Previously, we expected to get a notification from another >>> process (the WM). Now we process the notification ourselves and are >>> the owners of the selection. I don't know for sure, but suppose some >>> xlib implementations could optimize this scenario and process events >>> locally w/o even sending them to the X server. In which case there >>> wouldn't be any real synchronization of the native event queue. That's >>> why communicating with another process was an important part of this >>> procedure. >>> >>> How about we try the original method first, and only if it fails, then >>> try this workaround solution? >>> >>> Also, this is a very sensitive method because a lot of code relies on >>> it. I suggest running all automatic regression tests for AWT and Swing >>> areas to make sure we don't introduce a regression with this fix. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 09/26/2013 11:56 AM, Oleg Pekhovskiy wrote: >>>> Hi Leonid, >>>> >>>> I did it mostly logically, because my fix added one more service event >>>> (SelectionRequest), that should be excluded from the number of >>>> dispatched native events. >>>> IMHO, the previous number "2" should have been commented, but, that >>>> did >>>> not happen. >>>> >>>> Thanks, >>>> Oleg >>>> >>>> On 25.09.2013 18:11, Leonid Romanov wrote: >>>>> Hi, >>>>> I'm not an expert in X11 programming, so I can't comment about the >>>>> fix >>>>> in general, but I think the line 2436, "return getEventNumber() - >>>>> event_number > 3", really asks for a comment. >>>>> >>>>> On 9/25/2013 16:38, Oleg Pekhovskiy wrote: >>>>>> Hi all, >>>>>> >>>>>> please review the fix >>>>>> http://cr.openjdk.java.net/~bagiras/7033533.1/ >>>>>> for >>>>>> https://bugs.openjdk.java.net/browse/JDK-7033533 >>>>>> >>>>>> Previous implementation of XToolkit.syncNativeQueue() relied upon >>>>>> WM_S0 atom existence and that it was owned by current window >>>>>> manager. >>>>>> But several WMs (like XFCE and LXDE) don't send SelectionNotify >>>>>> event >>>>>> to the client on XConvertSelection() for that atom. That led >>>>>> XToolkit.syncNativeQueue() to hang until TimeOutException. >>>>>> >>>>>> I decided to keep XConvertSelection() usage, but make root toolkit >>>>>> window as an owner for selection atom (with another name), and >>>>>> handle >>>>>> SelectionRequest event from X Server, sending SelectionNotify in >>>>>> response (as window manager is supposed to do). >>>>>> >>>>>> Tested on both XFCE and LXDE. >>>>>> >>>>>> Thanks, >>>>>> Oleg >>>>> >> > From oleg.pekhovskiy at oracle.com Tue Oct 1 05:46:42 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Tue, 01 Oct 2013 16:46:42 +0400 Subject: [8] Review request for 7033533: realSync() doesn't work with Xfce In-Reply-To: <524AB9A6.8040500@oracle.com> References: <5242D93C.4070809@oracle.com> <5242EEF6.2010609@oracle.com> <5243E8C4.7060004@oracle.com> <524AB228.80803@oracle.com> <524AB9A6.8040500@oracle.com> Message-ID: <524AC432.2070600@oracle.com> Hi Leonid, On 01.10.2013 16:01, Leonid Romanov wrote: > By the way, I was reading Inter-Client Communication Conventions Manual > so I could better understand the fix, and found the following: > > "4.3. Communication with the Window Manager by Means of Selections > > For each screen they manage, window managers will acquire ownership of a > selection named WM_Sn, where n is the screen number, as described in > section 1.2.6. Window managers should comply with the conventions for > "Manager Selections" described in section 2.8. The intent is for clients > to be able to request a variety of information or services by issuing > conversion requests on this selection." > > Considering this, can we say that Xfce is not complying to the spec? not really, because Xfce HAS "VESRION" target for "WM_S0" selection, but in spite of the fast we request this atom as a target, we ask for "OOPS" property which is not mentioned anywhere. Thanks, Oleg > > On 10/1/2013 15:29, Anthony Petrov wrote: >> Hi Oleg, >> >> I second to Leonid: you should add a comment and explain why you >> expect exactly 4 (or more) events to be processed. Preferably, you >> should list each event to clearly understand this. >> >> A minor comment is, lines 2404 - 2407 should be moved to the nearest >> try{} block at line 2409. >> >> A major concern is that I'm not sure the new solution is reliable in >> all cases. Previously, we expected to get a notification from another >> process (the WM). Now we process the notification ourselves and are >> the owners of the selection. I don't know for sure, but suppose some >> xlib implementations could optimize this scenario and process events >> locally w/o even sending them to the X server. In which case there >> wouldn't be any real synchronization of the native event queue. That's >> why communicating with another process was an important part of this >> procedure. >> >> How about we try the original method first, and only if it fails, then >> try this workaround solution? >> >> Also, this is a very sensitive method because a lot of code relies on >> it. I suggest running all automatic regression tests for AWT and Swing >> areas to make sure we don't introduce a regression with this fix. >> >> -- >> best regards, >> Anthony >> >> On 09/26/2013 11:56 AM, Oleg Pekhovskiy wrote: >>> Hi Leonid, >>> >>> I did it mostly logically, because my fix added one more service event >>> (SelectionRequest), that should be excluded from the number of >>> dispatched native events. >>> IMHO, the previous number "2" should have been commented, but, that did >>> not happen. >>> >>> Thanks, >>> Oleg >>> >>> On 25.09.2013 18:11, Leonid Romanov wrote: >>>> Hi, >>>> I'm not an expert in X11 programming, so I can't comment about the fix >>>> in general, but I think the line 2436, "return getEventNumber() - >>>> event_number > 3", really asks for a comment. >>>> >>>> On 9/25/2013 16:38, Oleg Pekhovskiy wrote: >>>>> Hi all, >>>>> >>>>> please review the fix >>>>> http://cr.openjdk.java.net/~bagiras/7033533.1/ >>>>> for >>>>> https://bugs.openjdk.java.net/browse/JDK-7033533 >>>>> >>>>> Previous implementation of XToolkit.syncNativeQueue() relied upon >>>>> WM_S0 atom existence and that it was owned by current window manager. >>>>> But several WMs (like XFCE and LXDE) don't send SelectionNotify event >>>>> to the client on XConvertSelection() for that atom. That led >>>>> XToolkit.syncNativeQueue() to hang until TimeOutException. >>>>> >>>>> I decided to keep XConvertSelection() usage, but make root toolkit >>>>> window as an owner for selection atom (with another name), and handle >>>>> SelectionRequest event from X Server, sending SelectionNotify in >>>>> response (as window manager is supposed to do). >>>>> >>>>> Tested on both XFCE and LXDE. >>>>> >>>>> Thanks, >>>>> Oleg >>>> > From petr.pchelko at oracle.com Tue Oct 1 05:51:11 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 1 Oct 2013 16:51:11 +0400 Subject: [8] Review request: JDK-8024600 [macosx] code prevents use of -Xlint:auxiliaryclass, empty in jdk build Message-ID: Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8024600 The fix is available at: http://cr.openjdk.java.net/~pchelko/8024600/webrev.00/ The warnings were fixed. The only behavioural change is in the AquaMenuBarUI: previously the if result was ignored, but it's incorrect: we should return (0, 0) only if we succeeded in setting the screen menu bar, I suppose that semicolon was a typo. With best regards. Petr. From anton.tarasov at oracle.com Tue Oct 1 05:56:00 2013 From: anton.tarasov at oracle.com (Anton Tarasov) Date: Tue, 01 Oct 2013 16:56:00 +0400 Subject: [8] Review request for CR 7161320 TEST_BUG: java/awt/event/KeyEvent/SwallowKeyEvents/SwallowKeyEvents.java fails (Invalid key code) In-Reply-To: <52418650.4060306@oracle.com> References: <851b27b5-d98d-46a8-98df-83db77a94d84@default> <52418473.7060801@oracle.com> <52418650.4060306@oracle.com> Message-ID: <524AC660.6020007@oracle.com> (Sorry, I was away on J1) I'm personnaly not against expanding the test to the platfroms where META is supported. I'm Ok with sun.awt.OSInfo.getOSType() as well. Thanks, Anton. On 24.09.2013 16:32, Anthony Petrov wrote: > Perhaps we should filter out the Windows platform then, and let the > test run on any other platform instead of restricting it to OS X only? > > Konstantin, Sergey, what do you think? > > -- > best regards, > Anthony > > On 09/24/2013 04:24 PM, Konstantin Shefov wrote: >> >> On 24-Sep-13 15:57, Sergey Bylokhov wrote: >>> Hello. >>> I am not sure why r.keyPress(KeyEvent.VK_META) is not supported on >>> windows and where/when is it supported? >> I have run this test on OS X - meta is supported, on Ubuntu Linux 12 - >> meta is supported, on Windows 7 - Meta is NOT supported. >>> =============================== >>> Hi Konstantin, >>> >>> What is the reason to check the toolkit name as opposed to using the >>> sun.awt.OSInfo.getOSType() in this case? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 09/24/2013 02:51 PM, Konstantin Shefov wrote: >>>> Hello, >>>> >>>> Please review a fix for the issue: >>>> >>>> 7161320 TEST_BUG: >>>> java/awt/event/KeyEvent/SwallowKeyEvents/SwallowKeyEvents.java fails >>>> (Invalid key code) >>>> >>>> Test bug fix. >>>> >>>> http://bugs.sun.com/view_bug.do?bug_id=7161320 >>>> >>>> The webrev is: http://cr.openjdk.java.net/~kshefov/7161320/webrev.00 >>>> >>>> Thanks, >>>> Konstantin >> From Sergey.Bylokhov at oracle.com Tue Oct 1 06:08:02 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 01 Oct 2013 17:08:02 +0400 Subject: [8] Review request: JDK-8024600 [macosx] code prevents use of -Xlint:auxiliaryclass, empty in jdk build In-Reply-To: References: Message-ID: <524AC932.9000103@oracle.com> Hi, Petr. The fix looks good. On 01.10.2013 16:51, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8024600 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/8024600/webrev.00/ > > The warnings were fixed. The only behavioural change is in the AquaMenuBarUI: previously the if result was ignored, > but it's incorrect: we should return (0, 0) only if we succeeded in setting the screen menu bar, I suppose that semicolon was a typo. > > With best regards. Petr. -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Oct 1 06:11:48 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 17:11:48 +0400 Subject: [8] Review request for 7033533: realSync() doesn't work with Xfce In-Reply-To: <524AC233.9090009@oracle.com> References: <5242D93C.4070809@oracle.com> <5242EEF6.2010609@oracle.com> <5243E8C4.7060004@oracle.com> <524AB228.80803@oracle.com> <524AB9A6.8040500@oracle.com> <524ABFC6.8000200@oracle.com> <524AC233.9090009@oracle.com> Message-ID: <524ACA14.4070503@oracle.com> I agree with Leonid on both points. -- best regards, Anthony On 10/01/2013 04:38 PM, Leonid Romanov wrote: > I agree with you, but it would change our approach to the fix: for > instance, we might want to use the new realSync() version for Xfce only. > Also, we should a bug in Xfce bug tracking system then. > > On 10/1/2013 16:27, Yuri Nesterenko wrote: >> Sure we can say that Xfce is not complying -- it is not officially >> supported by JDK -- neither is LXDE etc. -- but saying that gets >> us nowhere. >> >> As to testing, could you suggest a platform selection? I'm afraid >> we'll not be able to test Xsun properly but Xorg with Gnome on >> Linux and Solaris, Unity and Xfce4 -- >> all that we can do by the weekend. >> >> Thanks, >> -yan >> >> On 10/01/2013 04:01 PM, Leonid Romanov wrote: >>> By the way, I was reading Inter-Client Communication Conventions Manual >>> so I could better understand the fix, and found the following: >>> >>> "4.3. Communication with the Window Manager by Means of Selections >>> >>> For each screen they manage, window managers will acquire ownership of a >>> selection named WM_Sn, where n is the screen number, as described in >>> section 1.2.6. Window managers should comply with the conventions for >>> "Manager Selections" described in section 2.8. The intent is for clients >>> to be able to request a variety of information or services by issuing >>> conversion requests on this selection." >>> >>> Considering this, can we say that Xfce is not complying to the spec? >>> >>> On 10/1/2013 15:29, Anthony Petrov wrote: >>>> Hi Oleg, >>>> >>>> I second to Leonid: you should add a comment and explain why you >>>> expect exactly 4 (or more) events to be processed. Preferably, you >>>> should list each event to clearly understand this. >>>> >>>> A minor comment is, lines 2404 - 2407 should be moved to the nearest >>>> try{} block at line 2409. >>>> >>>> A major concern is that I'm not sure the new solution is reliable in >>>> all cases. Previously, we expected to get a notification from another >>>> process (the WM). Now we process the notification ourselves and are >>>> the owners of the selection. I don't know for sure, but suppose some >>>> xlib implementations could optimize this scenario and process events >>>> locally w/o even sending them to the X server. In which case there >>>> wouldn't be any real synchronization of the native event queue. That's >>>> why communicating with another process was an important part of this >>>> procedure. >>>> >>>> How about we try the original method first, and only if it fails, then >>>> try this workaround solution? >>>> >>>> Also, this is a very sensitive method because a lot of code relies on >>>> it. I suggest running all automatic regression tests for AWT and Swing >>>> areas to make sure we don't introduce a regression with this fix. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 09/26/2013 11:56 AM, Oleg Pekhovskiy wrote: >>>>> Hi Leonid, >>>>> >>>>> I did it mostly logically, because my fix added one more service event >>>>> (SelectionRequest), that should be excluded from the number of >>>>> dispatched native events. >>>>> IMHO, the previous number "2" should have been commented, but, that >>>>> did >>>>> not happen. >>>>> >>>>> Thanks, >>>>> Oleg >>>>> >>>>> On 25.09.2013 18:11, Leonid Romanov wrote: >>>>>> Hi, >>>>>> I'm not an expert in X11 programming, so I can't comment about the >>>>>> fix >>>>>> in general, but I think the line 2436, "return getEventNumber() - >>>>>> event_number > 3", really asks for a comment. >>>>>> >>>>>> On 9/25/2013 16:38, Oleg Pekhovskiy wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> please review the fix >>>>>>> http://cr.openjdk.java.net/~bagiras/7033533.1/ >>>>>>> for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-7033533 >>>>>>> >>>>>>> Previous implementation of XToolkit.syncNativeQueue() relied upon >>>>>>> WM_S0 atom existence and that it was owned by current window >>>>>>> manager. >>>>>>> But several WMs (like XFCE and LXDE) don't send SelectionNotify >>>>>>> event >>>>>>> to the client on XConvertSelection() for that atom. That led >>>>>>> XToolkit.syncNativeQueue() to hang until TimeOutException. >>>>>>> >>>>>>> I decided to keep XConvertSelection() usage, but make root toolkit >>>>>>> window as an owner for selection atom (with another name), and >>>>>>> handle >>>>>>> SelectionRequest event from X Server, sending SelectionNotify in >>>>>>> response (as window manager is supposed to do). >>>>>>> >>>>>>> Tested on both XFCE and LXDE. >>>>>>> >>>>>>> Thanks, >>>>>>> Oleg >>>>>> >>> >> > From yuri.nesterenko at oracle.com Tue Oct 1 06:21:28 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Tue, 01 Oct 2013 17:21:28 +0400 Subject: [8] Review request for 7033533: realSync() doesn't work with Xfce In-Reply-To: <524AC233.9090009@oracle.com> References: <5242D93C.4070809@oracle.com> <5242EEF6.2010609@oracle.com> <5243E8C4.7060004@oracle.com> <524AB228.80803@oracle.com> <524AB9A6.8040500@oracle.com> <524ABFC6.8000200@oracle.com> <524AC233.9090009@oracle.com> Message-ID: <524ACC58.2080205@oracle.com> Leonid, I think you would not deny that fix is elegant even if risky. Adding a sniffer will make it ugly; besides, modern lightweight desktop environments become wildly popular really fast -- look at LXDE -- much faster than Java version juggernaut is changing version. What to sniff? Perhaps we would have to file bugs in too many bug tracking systems. "ICCCM establishes conventions, which are basically suggestions." Thanks, -yan On 10/01/2013 04:38 PM, Leonid Romanov wrote: > I agree with you, but it would change our approach to the fix: for > instance, we might want to use the new realSync() version for Xfce only. > Also, we should a bug in Xfce bug tracking system then. > > On 10/1/2013 16:27, Yuri Nesterenko wrote: >> Sure we can say that Xfce is not complying -- it is not officially >> supported by JDK -- neither is LXDE etc. -- but saying that gets >> us nowhere. >> >> As to testing, could you suggest a platform selection? I'm afraid >> we'll not be able to test Xsun properly but Xorg with Gnome on >> Linux and Solaris, Unity and Xfce4 -- >> all that we can do by the weekend. >> >> Thanks, >> -yan >> >> On 10/01/2013 04:01 PM, Leonid Romanov wrote: >>> By the way, I was reading Inter-Client Communication Conventions Manual >>> so I could better understand the fix, and found the following: >>> >>> "4.3. Communication with the Window Manager by Means of Selections >>> >>> For each screen they manage, window managers will acquire ownership of a >>> selection named WM_Sn, where n is the screen number, as described in >>> section 1.2.6. Window managers should comply with the conventions for >>> "Manager Selections" described in section 2.8. The intent is for clients >>> to be able to request a variety of information or services by issuing >>> conversion requests on this selection." >>> >>> Considering this, can we say that Xfce is not complying to the spec? >>> >>> On 10/1/2013 15:29, Anthony Petrov wrote: >>>> Hi Oleg, >>>> >>>> I second to Leonid: you should add a comment and explain why you >>>> expect exactly 4 (or more) events to be processed. Preferably, you >>>> should list each event to clearly understand this. >>>> >>>> A minor comment is, lines 2404 - 2407 should be moved to the nearest >>>> try{} block at line 2409. >>>> >>>> A major concern is that I'm not sure the new solution is reliable in >>>> all cases. Previously, we expected to get a notification from another >>>> process (the WM). Now we process the notification ourselves and are >>>> the owners of the selection. I don't know for sure, but suppose some >>>> xlib implementations could optimize this scenario and process events >>>> locally w/o even sending them to the X server. In which case there >>>> wouldn't be any real synchronization of the native event queue. That's >>>> why communicating with another process was an important part of this >>>> procedure. >>>> >>>> How about we try the original method first, and only if it fails, then >>>> try this workaround solution? >>>> >>>> Also, this is a very sensitive method because a lot of code relies on >>>> it. I suggest running all automatic regression tests for AWT and Swing >>>> areas to make sure we don't introduce a regression with this fix. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 09/26/2013 11:56 AM, Oleg Pekhovskiy wrote: >>>>> Hi Leonid, >>>>> >>>>> I did it mostly logically, because my fix added one more service event >>>>> (SelectionRequest), that should be excluded from the number of >>>>> dispatched native events. >>>>> IMHO, the previous number "2" should have been commented, but, that >>>>> did >>>>> not happen. >>>>> >>>>> Thanks, >>>>> Oleg >>>>> >>>>> On 25.09.2013 18:11, Leonid Romanov wrote: >>>>>> Hi, >>>>>> I'm not an expert in X11 programming, so I can't comment about the >>>>>> fix >>>>>> in general, but I think the line 2436, "return getEventNumber() - >>>>>> event_number > 3", really asks for a comment. >>>>>> >>>>>> On 9/25/2013 16:38, Oleg Pekhovskiy wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> please review the fix >>>>>>> http://cr.openjdk.java.net/~bagiras/7033533.1/ >>>>>>> for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-7033533 >>>>>>> >>>>>>> Previous implementation of XToolkit.syncNativeQueue() relied upon >>>>>>> WM_S0 atom existence and that it was owned by current window >>>>>>> manager. >>>>>>> But several WMs (like XFCE and LXDE) don't send SelectionNotify >>>>>>> event >>>>>>> to the client on XConvertSelection() for that atom. That led >>>>>>> XToolkit.syncNativeQueue() to hang until TimeOutException. >>>>>>> >>>>>>> I decided to keep XConvertSelection() usage, but make root toolkit >>>>>>> window as an owner for selection atom (with another name), and >>>>>>> handle >>>>>>> SelectionRequest event from X Server, sending SelectionNotify in >>>>>>> response (as window manager is supposed to do). >>>>>>> >>>>>>> Tested on both XFCE and LXDE. >>>>>>> >>>>>>> Thanks, >>>>>>> Oleg >>>>>> >>> >> > From leonid.romanov at oracle.com Tue Oct 1 06:59:26 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 01 Oct 2013 17:59:26 +0400 Subject: [8] Review request for 7033533: realSync() doesn't work with Xfce In-Reply-To: <524ACC58.2080205@oracle.com> References: <5242D93C.4070809@oracle.com> <5242EEF6.2010609@oracle.com> <5243E8C4.7060004@oracle.com> <524AB228.80803@oracle.com> <524AB9A6.8040500@oracle.com> <524ABFC6.8000200@oracle.com> <524AC233.9090009@oracle.com> <524ACC58.2080205@oracle.com> Message-ID: <524AD53E.4050009@oracle.com> I share Anthony's concern that the fix might not be reliable. There is a new generation of window systems on the way, like Wayland or Mir, which provide xlib compatibility layer on top of its own protocol, so they might implement the optimization described by Anthony. On 10/1/2013 17:21, Yuri Nesterenko wrote: > Leonid, I think you would not deny that fix is elegant even if risky. > Adding a sniffer will make it ugly; besides, modern lightweight > desktop environments become wildly popular really fast -- > look at LXDE -- much faster than Java version juggernaut is > changing version. What to sniff? > Perhaps we would have to file bugs in too many bug tracking systems. > "ICCCM establishes conventions, which are basically suggestions." > > Thanks, > -yan > > On 10/01/2013 04:38 PM, Leonid Romanov wrote: >> I agree with you, but it would change our approach to the fix: for >> instance, we might want to use the new realSync() version for Xfce only. >> Also, we should a bug in Xfce bug tracking system then. >> >> On 10/1/2013 16:27, Yuri Nesterenko wrote: >>> Sure we can say that Xfce is not complying -- it is not officially >>> supported by JDK -- neither is LXDE etc. -- but saying that gets >>> us nowhere. >>> >>> As to testing, could you suggest a platform selection? I'm afraid >>> we'll not be able to test Xsun properly but Xorg with Gnome on >>> Linux and Solaris, Unity and Xfce4 -- >>> all that we can do by the weekend. >>> >>> Thanks, >>> -yan >>> >>> On 10/01/2013 04:01 PM, Leonid Romanov wrote: >>>> By the way, I was reading Inter-Client Communication Conventions >>>> Manual >>>> so I could better understand the fix, and found the following: >>>> >>>> "4.3. Communication with the Window Manager by Means of Selections >>>> >>>> For each screen they manage, window managers will acquire ownership >>>> of a >>>> selection named WM_Sn, where n is the screen number, as described in >>>> section 1.2.6. Window managers should comply with the conventions for >>>> "Manager Selections" described in section 2.8. The intent is for >>>> clients >>>> to be able to request a variety of information or services by issuing >>>> conversion requests on this selection." >>>> >>>> Considering this, can we say that Xfce is not complying to the spec? >>>> >>>> On 10/1/2013 15:29, Anthony Petrov wrote: >>>>> Hi Oleg, >>>>> >>>>> I second to Leonid: you should add a comment and explain why you >>>>> expect exactly 4 (or more) events to be processed. Preferably, you >>>>> should list each event to clearly understand this. >>>>> >>>>> A minor comment is, lines 2404 - 2407 should be moved to the nearest >>>>> try{} block at line 2409. >>>>> >>>>> A major concern is that I'm not sure the new solution is reliable in >>>>> all cases. Previously, we expected to get a notification from another >>>>> process (the WM). Now we process the notification ourselves and are >>>>> the owners of the selection. I don't know for sure, but suppose some >>>>> xlib implementations could optimize this scenario and process events >>>>> locally w/o even sending them to the X server. In which case there >>>>> wouldn't be any real synchronization of the native event queue. >>>>> That's >>>>> why communicating with another process was an important part of this >>>>> procedure. >>>>> >>>>> How about we try the original method first, and only if it fails, >>>>> then >>>>> try this workaround solution? >>>>> >>>>> Also, this is a very sensitive method because a lot of code relies on >>>>> it. I suggest running all automatic regression tests for AWT and >>>>> Swing >>>>> areas to make sure we don't introduce a regression with this fix. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 09/26/2013 11:56 AM, Oleg Pekhovskiy wrote: >>>>>> Hi Leonid, >>>>>> >>>>>> I did it mostly logically, because my fix added one more service >>>>>> event >>>>>> (SelectionRequest), that should be excluded from the number of >>>>>> dispatched native events. >>>>>> IMHO, the previous number "2" should have been commented, but, that >>>>>> did >>>>>> not happen. >>>>>> >>>>>> Thanks, >>>>>> Oleg >>>>>> >>>>>> On 25.09.2013 18:11, Leonid Romanov wrote: >>>>>>> Hi, >>>>>>> I'm not an expert in X11 programming, so I can't comment about the >>>>>>> fix >>>>>>> in general, but I think the line 2436, "return getEventNumber() - >>>>>>> event_number > 3", really asks for a comment. >>>>>>> >>>>>>> On 9/25/2013 16:38, Oleg Pekhovskiy wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> please review the fix >>>>>>>> http://cr.openjdk.java.net/~bagiras/7033533.1/ >>>>>>>> for >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7033533 >>>>>>>> >>>>>>>> Previous implementation of XToolkit.syncNativeQueue() relied upon >>>>>>>> WM_S0 atom existence and that it was owned by current window >>>>>>>> manager. >>>>>>>> But several WMs (like XFCE and LXDE) don't send SelectionNotify >>>>>>>> event >>>>>>>> to the client on XConvertSelection() for that atom. That led >>>>>>>> XToolkit.syncNativeQueue() to hang until TimeOutException. >>>>>>>> >>>>>>>> I decided to keep XConvertSelection() usage, but make root toolkit >>>>>>>> window as an owner for selection atom (with another name), and >>>>>>>> handle >>>>>>>> SelectionRequest event from X Server, sending SelectionNotify in >>>>>>>> response (as window manager is supposed to do). >>>>>>>> >>>>>>>> Tested on both XFCE and LXDE. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Oleg >>>>>>> >>>> >>> >> > From anthony.petrov at oracle.com Tue Oct 1 07:23:13 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 18:23:13 +0400 Subject: [8] Review request 7059886: 6 JCK manual awt/Desktop tests fail with GTKLookAndFeel - GTK intialization issue In-Reply-To: <524969BB.2020700@oracle.com> References: <52416C0D.6010903@oracle.com> <524181A9.6010903@oracle.com> <52458FE4.6010906@oracle.com> <5245954A.9060503@oracle.com> <5245BDA2.9010100@oracle.com> <524969BB.2020700@oracle.com> Message-ID: <524ADAD1.8080005@oracle.com> +1 -- best regards, Anthony On 09/30/2013 04:08 PM, Artem Ananiev wrote: > > This version of the fix looks fine. > > Thanks, > > Artem > > On 9/27/2013 9:17 PM, Alexander Zvegintsev wrote: >> Anthony, >> >> please see inline: >> >> On 09/27/2013 06:25 PM, Anthony Petrov wrote: >>> Hi Alexander, >>> >>> How about getAndSetInitializationNeededFlag ? >>> >>>> 74 * If it returns {@code false} user must call >>>> g_thread_init() on his own. >>> >>> "on their own"? :) Yet, it might be better phrased as: >>> >>> "A return value of {@code false} indicates that the calling code should >>> call the g_thread_init() function in Glib before releasing the lock." >>> >>> >> Thanks, this sounds much better. >>> src/solaris/native/sun/awt/gtk2_interface.c >>>> 837 //According the GTK documentation, >>>> gdk_threads_init() should be >>>> 838 //called before gtk_init() or gtk_init_check() >>>> 839 fp_gdk_threads_init(); >>> >>> Interesting. I see we only specify we want user code to call >>> g_thread_init(), while here we also call gdk_threads_init() and use >>> the same flag to decide whether to call it or not. Is this OK? What >>> about other clients (FX)? >>> >> FX will call gdk_threads_init() within the lock, since it internally >> sets global g_mutex, second call to gdk_threads_init() will replace this >> mutex. >> We can get into a trouble if we call gdk_threads_init() while other >> thread holding lock on this mutex. >> >> Here is updated webrev: >> http://cr.openjdk.java.net/~serb/alexz/7059886/webrev.02/ >> >> Thanks, >> >> Alexander. >> >>> -- >>> best regards, >>> Anthony >>> >>> On 09/27/2013 06:02 PM, Alexander Zvegintsev wrote: >>>> Hi Anthony, Artem, >>>> >>>> here is a new version of webrev with suggested improvements: >>>> http://cr.openjdk.java.net/~serb/alexz/7059886/webrev.01/ >>>> >>>> Name of a function in GThreadHelper is not ideal, but I can't think out >>>> any better. >>>> >>>>> We don't expect C code to use try - finally, but when we use >>>>> GThreadHelper from FX, we'll do. >>>> In FX we will use it from native too. >>>> >>>>> BTW, is g_thread_get_initialized() really deprecated? If that is the >>>>> case, it doesn't worth to use it, but rely on GThreadHelper only. >>>> I think it worth to use it. It is deprerecated due to: >>>>> |g_thread_init| has been deprecated since version 2.32 and should not >>>>> be used in newly-written code. The GLib threading system is >>>>> automatically initialized at the start of your program. >>>> hence g_thread_get_initialized() returns always true on a modern GLib >>>> versions. >>>> >>>> >>>> Thanks, >>>> >>>> Alexander. >>>> >>>> On 09/24/2013 04:12 PM, Anthony Petrov wrote: >>>>> Hi Alexander, >>>>> >>>>> A few comments on the GThreadHelper class: >>>>> >>>>> 1. I think the static methods in the GThreadHelper class should be >>>>> public, because they are intended to be called by external code. Note >>>>> that all public symbols should have a javadoc. >>>>> >>>>> 2. Why do we need both isInitializationNeeded() and initFinished()? >>>>> Can the isInitializationNeeded() act (and be named) like the >>>>> AtomicBoolean.compareAndSet/getAndSet() methods, in that it would >>>>> automatically set the initialized flag to true? >>>>> Or do you see a use case when a code may want to check that GTK isn't >>>>> initialized yet and still not initialize it afterwards? What could >>>>> this be needed for? >>>>> >>>>> 3. Since the flag has to be queried/modified under the LOCK only, it >>>>> doesn't need to be volatile. >>>>> >>>>> 4. In Javadocs, the first sentence usually summarizes what a method >>>>> does. Locking requirements should be stated either at the end of the >>>>> first sentence, or in a subsequent sentence. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 09/24/2013 02:40 PM, Alexander Zvegintsev wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the fix for the issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-7059886 >>>>>> The webrev is available here: >>>>>> http://cr.openjdk.java.net/~serb/alexz/7059886/webrev.00/ >>>>>> >>>>>> For old versions of GLib (< 2.24) calling g_thread_init () [1] >>>>>> multiple >>>>>> times will crash an application. >>>>>> There are two ways to find out if g_thread_init() has been called: >>>>>> g_thread_supported ()[2] and g_thread_get_initialized ()[3] >>>>>> >>>>>> g_thread_supported () is a macro, so we cannot load it with dlsym >>>>>> g_thread_get_initialized () was introduced in 2.20, but we have to >>>>>> support versions < 2.20 >>>>>> >>>>>> Currently in JDK we have an internal flag which protects us from such >>>>>> multiple calls, but at least we >>>>>> have Java FX which does not have access to this flag. >>>>>> >>>>>> The idea of the fix it to make single entry point for everyone who is >>>>>> about to call g_thread_init () to >>>>>> check if it has been called. >>>>>> >>>>>> Should we bring back g_thread_get_initialized () check for GLib >= >>>>>> 2.20 >>>>>> for safety? >>>>>> >>>>>> [1] >>>>>> https://developer.gnome.org/glib/stable/glib-Deprecated-Thread-APIs.html#g-thread-init >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [2] >>>>>> https://developer.gnome.org/glib/stable/glib-Deprecated-Thread-APIs.html#g-thread-supported >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [3] >>>>>> https://developer.gnome.org/glib/stable/glib-Deprecated-Thread-APIs.html#g-thread-get-initialized >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> From alexander.zvegintsev at oracle.com Tue Oct 1 07:35:53 2013 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 01 Oct 2013 18:35:53 +0400 Subject: [8] Review request for 7158311 GraphicsDevice.setDisplayMode(...) leads to hang when DISPLAY variable points to Oracle Linux Message-ID: <524ADDC9.8060103@oracle.com> Hello, Could you please review a fix for following issues: https://bugs.openjdk.java.net/browse/JDK-7158311 https://bugs.openjdk.java.net/browse/JDK-8001463 webrev: http://cr.openjdk.java.net/~serb/alexz/7158311/webrev.00/ All X11 implementations of DisplayChangedListener does not call any X11 routines, hence SunGraphicsEnvironment.displayChanged() callback does not require an AWTLock and we can temporarily release it to avoid deadlock. -- Thanks, Alexander. From anton.litvinov at oracle.com Tue Oct 1 07:43:08 2013 From: anton.litvinov at oracle.com (anton.litvinov at oracle.com) Date: Tue, 01 Oct 2013 14:43:08 +0000 Subject: hg: jdk8/awt/jdk: 8025145: [macosx]: java 7 does not recognize tiff image on clipboard Message-ID: <20131001144345.210CE62C46@hg.openjdk.java.net> Changeset: a0c28e64c049 Author: alitvinov Date: 2013-10-01 18:40 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a0c28e64c049 8025145: [macosx]: java 7 does not recognize tiff image on clipboard Reviewed-by: anthony, serb Contributed-by: anton.nashatyrev at oracle.com ! src/macosx/lib/flavormap.properties From alexander.zvegintsev at oracle.com Tue Oct 1 07:57:14 2013 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 01 Oct 2013 18:57:14 +0400 Subject: [8] Review request for 8013563: Memory leak in JFrame on Linux Message-ID: <524AE2CA.30204@oracle.com> Hello, please review a fix for following issue: https://bugs.openjdk.java.net/browse/JDK-8013563 webrev: http://cr.openjdk.java.net/~serb/alexz/8013563/webrev.00/ This issue is a regression of 6758673 changes in java.awt.Window, where call to Disposer.addRecord was moved from init(gc) to ownedInit(). But we have constructors without a ownedInit() call, hence we never call removeFromWindowList() for Frame. -- Thanks, Alexander. From leonid.romanov at oracle.com Tue Oct 1 09:06:52 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 1 Oct 2013 20:06:52 +0400 Subject: [8] Review request for 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. In-Reply-To: <291D11C7-FAFB-45D0-9494-6BC4591B2F97@oracle.com> References: <5245BF90.4010001@oracle.com> <291D11C7-FAFB-45D0-9494-6BC4591B2F97@oracle.com> Message-ID: I've investigated this issue and couldn't find a situation where the call to XToolkit.targetDisposedPeer() from XBaseMenuWindow.doDispose() would make sense (we call XToolkit.targetDisposedPeer() with correct targets in XPopupMenuPeer and XMenuBarPeer), so I decided to remove it to avoid any confusion in the future. We still have the time to fix any regressions, in case they arise. Here is an updated webrev: http://cr.openjdk.java.net/~leonidr/8023994/webrev.01/ On Sep 27, 2013, at 9:33 PM, Leonid Romanov wrote: > Yes, this code looked suspicious for me as well, I suspect it is a result of copy pasting XWindow's dispose() code. For a wrong peer/target pair, XToolkit.targetDisposedPeer() is a no-op, so no harm is done, but perhaps it makes sense to remove that call altogether. I'll check it. > > On Sep 27, 2013, at 9:25 PM, Sergey Bylokhov wrote: > >> Hi, Leonid. >> In this case the code in the XBaseMenuWindow.doDispose() call XToolkit.targetDisposedPeer(target, this); for the wrong target? Or probably this target is alwase null? >> >> On 27.09.2013 20:32, Leonid Romanov wrote: >>> Hello, >>> Please review a fix for 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. The problem here is that for popup menus the "target" field of XBaseMenuWindow class is not a MenuComponent corresponding to the popup, but a component for which the popup is being shown. Therefore, if the menu has never been shown, the the target is null, so we can't use it for the InvocationEvent in dispose(). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023994 >>> Webrev: http://cr.openjdk.java.net/~leonidr/8023994/webrev.00/ >>> >>> Thanks, >>> Leonid. >>> >>> >>> >> >> >> -- >> Best regards, Sergey. >> > From Sergey.Bylokhov at oracle.com Tue Oct 1 09:22:05 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 01 Oct 2013 20:22:05 +0400 Subject: [8] Review request for 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. In-Reply-To: References: <5245BF90.4010001@oracle.com> <291D11C7-FAFB-45D0-9494-6BC4591B2F97@oracle.com> Message-ID: <524AF6AD.2080500@oracle.com> Hi, Leonid. The fix looks good. On 01.10.2013 20:06, Leonid Romanov wrote: > I've investigated this issue and couldn't find a situation where the call to XToolkit.targetDisposedPeer() from XBaseMenuWindow.doDispose() would make sense (we call XToolkit.targetDisposedPeer() with correct targets in XPopupMenuPeer and XMenuBarPeer), so I decided to remove it to avoid any confusion in the future. We still have the time to fix any regressions, in case they arise. Here is an updated webrev: > > http://cr.openjdk.java.net/~leonidr/8023994/webrev.01/ > > On Sep 27, 2013, at 9:33 PM, Leonid Romanov wrote: > >> Yes, this code looked suspicious for me as well, I suspect it is a result of copy pasting XWindow's dispose() code. For a wrong peer/target pair, XToolkit.targetDisposedPeer() is a no-op, so no harm is done, but perhaps it makes sense to remove that call altogether. I'll check it. >> >> On Sep 27, 2013, at 9:25 PM, Sergey Bylokhov wrote: >> >>> Hi, Leonid. >>> In this case the code in the XBaseMenuWindow.doDispose() call XToolkit.targetDisposedPeer(target, this); for the wrong target? Or probably this target is alwase null? >>> >>> On 27.09.2013 20:32, Leonid Romanov wrote: >>>> Hello, >>>> Please review a fix for 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. The problem here is that for popup menus the "target" field of XBaseMenuWindow class is not a MenuComponent corresponding to the popup, but a component for which the popup is being shown. Therefore, if the menu has never been shown, the the target is null, so we can't use it for the InvocationEvent in dispose(). >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023994 >>>> Webrev: http://cr.openjdk.java.net/~leonidr/8023994/webrev.00/ >>>> >>>> Thanks, >>>> Leonid. >>>> >>>> >>>> >>> >>> -- >>> Best regards, Sergey. >>> -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Oct 1 10:17:09 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 21:17:09 +0400 Subject: [8] Review Request: JDK-8025585 Win: Popups in JFXPanel do not receive MouseWheel events In-Reply-To: <5CBB81CC-BC3C-41A9-89C5-C1952582477A@oracle.com> References: <5CBB81CC-BC3C-41A9-89C5-C1952582477A@oracle.com> Message-ID: <524B0395.7060803@oracle.com> Hi Petr, MS Windows always sends WHEEL events to the focused window. And my testing shows that when you scroll the wheel outside of an AWT window, the scroll events are consumed (by AWT, supposedly). With your fix you seem to always redirect the events to the window under the mouse. Now suppose you have a 3rd-party window with a scroll bar in background (e.g. Windows Explorer). If an AWT window is currently focused, but you move the mouse pointer outside of it and above the Explorer window, and start scrolling, will the Explorer window scroll its contents? Currently it doesn't. What about if we apply your fix? -- best regards, Anthony On 09/27/2013 07:24 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8025585 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/ > > The fix is needed for JFXPanel support. We need to redispatch MOUSEWHEEL messages to the window under mouse. In case of Popups in a JFXPanel the HWND belongs to a different tollkit, so we need to use ::SendMessage to redispatch the message. > > With best regards. Petr. > From anthony.petrov at oracle.com Tue Oct 1 10:47:54 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 21:47:54 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <5245B70D.4070507@oracle.com> References: <5245B70D.4070507@oracle.com> Message-ID: <524B0ACA.2060708@oracle.com> Hi Sergey, I'm wondering what compatibility impact of this change is. The specification for Component.getToolkit() suggests that in theory several toolkits may co-exist in a single application. And thanks to delegating to the ComponentPeer, the Component.getToolkit() could return the actual toolkit for this component. However, your fix effectively disallows a component to belong to any toolkit other than the default one, because its getToolkit() will never return anything else (unless you extend the component's class and override the method). I really don't know whether this is widely used, but I think this may impact some applications. Also, imagine a window is made to belong to another toolkit somehow, even with your changes. Now, why should its ability to be always-on-top depend on the default toolkit instead of the window's own toolkit? -- best regards, Anthony On 09/27/2013 08:49 PM, sergey malenkov wrote: > Hello, > > Could you please review the following fix: > fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ > bug:https://bugs.openjdk.java.net/browse/JDK-7081584 > > The specification of the Window class waits for CCC approval. This fix > removes the getTookit method from the ComponentPeer class and its > subclasses. > > Thanks, > SAM > From artem.ananiev at oracle.com Tue Oct 1 10:54:03 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 01 Oct 2013 21:54:03 +0400 Subject: [8] Review Request: JDK-8025585 Win: Popups in JFXPanel do not receive MouseWheel events In-Reply-To: <524B0395.7060803@oracle.com> References: <5CBB81CC-BC3C-41A9-89C5-C1952582477A@oracle.com> <524B0395.7060803@oracle.com> Message-ID: <524B0C3B.8080702@oracle.com> On 10/1/2013 9:17 PM, Anthony Petrov wrote: > Hi Petr, > > MS Windows always sends WHEEL events to the focused window. And my > testing shows that when you scroll the wheel outside of an AWT window, > the scroll events are consumed (by AWT, supposedly). > > With your fix you seem to always redirect the events to the window under > the mouse. Now suppose you have a 3rd-party window with a scroll bar in > background (e.g. Windows Explorer). If an AWT window is currently > focused, but you move the mouse pointer outside of it and above the > Explorer window, and start scrolling, will the Explorer window scroll > its contents? Currently it doesn't. What about if we apply your fix? It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't. Thanks, Artem > -- > best regards, > Anthony > > On 09/27/2013 07:24 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8025585 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/ >> >> The fix is needed for JFXPanel support. We need to redispatch >> MOUSEWHEEL messages to the window under mouse. In case of Popups in a >> JFXPanel the HWND belongs to a different tollkit, so we need to use >> ::SendMessage to redispatch the message. >> >> With best regards. Petr. >> From anthony.petrov at oracle.com Tue Oct 1 10:55:11 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 21:55:11 +0400 Subject: [8] Review Request: JDK-8024163 [macosx] NullPointerException at javax.swing.TransferHandler$DropHandler.handleDrag since jdk8b93, 7u40b28 In-Reply-To: <560D2CCC-AFBF-4580-A20B-93D56C56148B@oracle.com> References: <01F0EBB9-74CF-498F-8FA4-924D9924AA6D@oracle.com> <99756FDF-46AB-4C72-B4F1-F32A5AB262EC@oracle.com> <560D2CCC-AFBF-4580-A20B-93D56C56148B@oracle.com> Message-ID: <524B0C7F.6060409@oracle.com> Hi Petr, There's some formatting issues with missing spaces, like: > 97 if(event.getComponent().getDropTarget() == insideTarget) { > 98 if(!eventInsideTarget) { or > 103 if(eventInsideTarget) { Otherwise the changes look good, although I'm not an expert in this code. -- best regards, Anthony On 09/30/2013 01:13 PM, Petr Pchelko wrote: > Hello. > > This is a reminder. Could I please get the second review on this? > > The bug: https://bugs.openjdk.java.net/browse/JDK-8024163 > The fix: http://cr.openjdk.java.net/~pchelko/8024163/webrev.01 > > Thank you. With best regards. Petr. > > On Sep 25, 2013, at 3:05 PM, Petr Pchelko > wrote: > >> Hello, AWT Team. >> >> Please review the updated version of this fix. >> It's available at: http://cr.openjdk.java.net/~pchelko/8024163/webrev.01/ >> >> I have changed the dragExit events generation a bit and added a couple >> of tests. >> >> With best regards. Petr. >> >> On Sep 24, 2013, at 6:30 PM, Petr Pchelko > > wrote: >> >>> Hello, AWT Team. >>> >>> Please review the fix for the following issue: >>> https://bugs.openjdk.java.net/browse/JDK-8024163 >>> The fix is available here: >>> http://cr.openjdk.java.net/~pchelko/8024163/webrev.00/ >>> >>> The problem is with the DropTarget Enter/Exit events. For real >>> heavyweights they are generated by native code. For lightweights - in >>> shared code. But for AWT components they should be generated in >>> CDropTargetContextPeer. >>> Before the fix these events could be generated incorrectly: sometimes >>> duplicated events were sent (this broke autoscrolling) and sometimes >>> events were not sent at all - this caused NPEs in the shared code. >>> The insideTarget boolean was replaced by a reference to DropTarget to >>> handle nested components correctly. >>> >>> Tested on Mac OS X (no shared code affected). >>> No new regression test failures. >>> >>> With best regards. Petr. >>> >>> >> > From anthony.petrov at oracle.com Tue Oct 1 11:05:08 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 22:05:08 +0400 Subject: [8] Review Request: JDK-7124363 [macosx] ClassCastException: CFileDialog cannot be cast to LWWindowPeer In-Reply-To: <4049D026-597F-4E32-9573-1DD76019DE93@oracle.com> References: <4049D026-597F-4E32-9573-1DD76019DE93@oracle.com> Message-ID: <524B0ED4.9040907@oracle.com> Looks good. -- best regards, Anthony On 09/30/2013 01:25 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-7124363 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/7124363/webrev.00/ > > This is a direct forward port form JDK-7. We do not need to set a fileDialog as a blocker, because it's natively application-modal. > > With best regards. Petr. > > From anthony.petrov at oracle.com Tue Oct 1 11:06:14 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 22:06:14 +0400 Subject: [8] Review request for 7092283 Property Window.locationByPlatform is not cleared by calling setVisible(false) In-Reply-To: <52497302.5030406@oracle.com> References: <5242DC1D.5040207@oracle.com> <5242E71F.30503@oracle.com> <52455EFD.1070102@oracle.com> <52457900.3060501@oracle.com> <52458237.4020501@oracle.com> <52458F3B.3090203@oracle.com> <52497302.5030406@oracle.com> Message-ID: <524B0F16.7080708@oracle.com> Looks fine. Thank you. -- best regards, Anthony On 09/30/2013 04:48 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7092283/webrev.02/ > - synchronization on tree lock is used instead of the setter method > - the readObject() method is not modified > > Thanks, > Alexandr. > > > On 9/27/2013 5:59 PM, Anthony Petrov wrote: >> On 09/27/2013 05:03 PM, Alexander Scherbatiy wrote: >>> On 9/27/2013 4:24 PM, Anthony Petrov wrote: >>>> I'm not sure if this is the right approach because the setter is >>>> overridable. So whenever you update the field, you may actually call >>>> user's code which in most cases is undesirable. Also, you really >>>> shouldn't do this in the context of readObject() because the object >>>> isn't fully initialized yet, so calling overridable methods at this >>>> stage is asking for troubles. >>>> >>>> I still suggest to access the field directly, but wrap the accessing >>>> statement with synchronized (getTreeLock()) {}. >>> Is it a common practice in awt to use synchronized block directly >>> instead of the setter method? >> >> Yes, in AWT we rarely (if ever) use public overridable setters to >> change fields. Usually we access the fields directly. >> >>> If a user's code does not use synchronization for the >>> locationByPlatform setting he really violates the AWT design for this >>> variable. >> >> User code can't access the private field directly. They can only call >> the setter (as super.set...() for example). Hence, user code can't >> violate the synchronization scheme directly. But our own code can, and >> in fact often does, which needs fixing. Hence my suggestion. >> >> -- >> best regards, >> Anthony >> >> >>> >>> Thanks, >>> Alexandr. >>> >>> >>>> And I wouldn't modify the readObject() at all. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 09/27/2013 02:33 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/7092283/webrev.01 >>>>> >>>>> - the locationByPlatform property is updated by setter method >>>>> - the open and closed tests are passed with the fix except one >>>>> which >>>>> fails without the fix too: >>>>> java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 9/25/2013 5:37 PM, Anthony Petrov wrote: >>>>>> Hi Alexander, >>>>>> >>>>>> The setter and getter for this property access the boolean flag under >>>>>> the tree lock. I suppose this was the locking design for this field. >>>>>> So you should reset it under this lock, too. You could also go ahead >>>>>> and add proper locking to other methods that access it (e.g. show(), >>>>>> etc.) >>>>>> >>>>>> Please run Window, Frame, and Dialog automatic regression tests (open >>>>>> and closed) to ensure no regressions after this change. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 09/25/2013 04:50 PM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the fix: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-7092283 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7092283/webrev.00 >>>>>>> >>>>>>> The Window.hide() method does not clear the locationByPlatform >>>>>>> property. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>> >>> > From anthony.petrov at oracle.com Tue Oct 1 11:08:16 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 22:08:16 +0400 Subject: [8] Review Request for 8025649: need test to cover JDK-8000423 In-Reply-To: <5249772F.6060503@oracle.com> References: <5249772F.6060503@oracle.com> Message-ID: <524B0F90.4080108@oracle.com> Looks good. -- best regards, Anthony On 09/30/2013 05:05 PM, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following [TEST] bug: > https://bugs.openjdk.java.net/browse/JDK-8025649 > > Webrev corresponding: > http://cr.openjdk.java.net/~alexsch/alexander-stepanov/8025649/webrev.00/ > > Just a new test added; no other code affected. > The patch contains a simple manual test to make sure if diacritical > marks could be typed for TextArea and TextField (hard to automate; the > test requires some internationalization settings on a machine). > > Thanks, > Alexander. From anthony.petrov at oracle.com Tue Oct 1 11:12:28 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 22:12:28 +0400 Subject: [8] Review Request: JDK-8025440 [TEST_BUG] com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java failed since jdk8b108 In-Reply-To: <21A39B7B-6159-4C98-A54A-1888BD26DEFD@oracle.com> References: <52457271.4020603@oracle.com> <7D5BD178-542B-4D40-A34A-938E2582C268@oracle.com> <21A39B7B-6159-4C98-A54A-1888BD26DEFD@oracle.com> Message-ID: <524B108C.1020009@oracle.com> Looks fine. Thank you. -- best regards, Anthony On 09/27/2013 06:39 PM, Petr Pchelko wrote: > Hello, Anthony. > > I've updated the fix: http://cr.openjdk.java.net/~pchelko/8025440/webrev.01/ > > Now the CopyClassFile utility is also copying the inner classes. It also supports class name in different packages. > > With best regards. Petr. > > On Sep 27, 2013, at 4:05 PM, Petr Pchelko wrote: > >> Hello, Anthony. >> >>> Note that the new utility class has limitations. For instance, it won't copy inner classes belonging to the main copied class. I suggest to document this, or implement this. Also, I suggest to add a message to the IllegalArgumentException thrown from the utility class. >> >> Ok, I'll fix that and resend the webrev. >> >>> I have a question though, why do we need it in the first place? Wouldn't it be sufficient to just override the checkPermission() method in the inner SecurityManager instance in the test itself? Why move it to a top-level class? >> If we just override the CheckPermission method the SecurityManager itself becomes an untrusted code. So the SecurityManager would check access to checkPermission by invoking checkPermissiom. So we would get an infinite recursion. >> To avoid this the SecurityManager should be loaded from the boot classpath. But in jtreg comments we are not able to determine the path to the folder which the SecurityManager was compiled to, it's possible only in runtume. So we need to copy the SecurityManager class to some temp location and than use it in VM arguments for an actual test. >> >> With best regards. Petr. >> >> On Sep 27, 2013, at 3:56 PM, Anthony Petrov wrote: >> >>> Hi Petr, >>> >>> Note that the new utility class has limitations. For instance, it won't copy inner classes belonging to the main copied class. I suggest to document this, or implement this. Also, I suggest to add a message to the IllegalArgumentException thrown from the utility class. >>> >>> I have a question though, why do we need it in the first place? Wouldn't it be sufficient to just override the checkPermission() method in the inner SecurityManager instance in the test itself? Why move it to a top-level class? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 09/26/2013 01:11 PM, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the following issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8025440 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/8025440/webrev.00/ >>>> >>>> After SecurityManager.checkTopLevelWindow was deprecated in JDK-8008981 the test fails. >>>> This fix updates the test. The CopyClassFile util is introduced - it's copying the class file into the specified directory in the test working dir. This is needed to use the -Xbootclasspath, so that the new SecurityManager could work. >>>> >>>> This is a test fix, no code is affected. >>>> >>>> With best regards. Petr. >>>> >> > From anthony.petrov at oracle.com Tue Oct 1 11:14:53 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 22:14:53 +0400 Subject: [8] Review Request: JDK-8025236 [javadoc] fix some errors in AWT In-Reply-To: <5249821E.2030409@oracle.com> References: <52442E3F.6000109@oracle.com> <524442D6.3030007@oracle.com> <52458D96.2090005@oracle.com> <5249821E.2030409@oracle.com> Message-ID: <524B111D.5000804@oracle.com> You should only change the issues in lines that are already modified in your fix. No massive reformatting please. And yes, the rest of the procedure is to publish the second version of the webrev, and post a link to this mailing list. -- best regards, Anthony On 09/30/2013 05:52 PM, Dmitry Ginzburg wrote: > So, should I fix all the issues with this ""'s, do webrev again > and send it to yan, and send it here again? > > Thanks, > > -Dmitry > > 27.09.2013 17:52, Anthony Petrov wrote: >> The fix looks good to me. Again, if possible, I'd suggest to replace >> with {@code ..} if you're changing a line anyway. >> >> -- >> best regards, >> Anthony >> >> On 09/26/2013 06:21 PM, Dmitry Ginzburg wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the following issue: >>> https://bugs.openjdk.java.net/browse/JDK-8025236 >>> The fix is available at: >>> http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.00/ >>> >>> This is the fix for javadoc errors, on which doclint was showing some >>> issues. >>> >>> The patch contains only simple markup fixes; no changes/fixes in >>> documentation text; the specification itself wasn't changed. >>> >>> Thanks, >>> -Dmitry From anthony.petrov at oracle.com Tue Oct 1 11:21:42 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 22:21:42 +0400 Subject: [8] Review request for 8020688: broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. In-Reply-To: <5245A508.4040707@oracle.com> References: <52433994.1090403@oracle.com> <5243635C.7070007@oracle.com> <52454506.8090500@oracle.com> <52457F15.7090501@oracle.com> <52459263.7040704@oracle.com> <524593EB.2010600@oracle.com> <524596A8.2040700@oracle.com> <5245A508.4040707@oracle.com> Message-ID: <524B12B6.3060803@oracle.com> Hi Mikhail, This "Advanced JList Programming" article seems to vanish, indeed. Although there's a copy at: http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/tech_topics/jlist_1/jlist.html but generally we shouldn't refer to 3rd-party web-sites from our specification. I briefly looked into the copy, and I think that referring to the Swing tutorial should be just fine as a replacement for this article. -- best regards, Anthony On 09/27/2013 07:32 PM, mikhail cherkasov wrote: > Anthony thank you for this link, it's good replacement for removed link. > > Also I didn't find replacement for : > - * Also see the article href="http://java.sun.com/products/jfc/tsc/tech_topics/jlist_1/jlist.html">Advanced > JList Programming > - * in The Swing > Connection. > > Do you have any suggestion about this link? the link to swing tutorial > already are there: > http://docs.oracle.com/javase/tutorial/uiswing/components/list.html > > Thanks, > Mikhail. > > On 27.09.2013 18:31, Anthony Petrov wrote: >> On 09/27/2013 06:19 PM, mikhail cherkasov wrote: >>> Anthony, some links, like this one, we lost for ever. >> >> How about >> http://docs.oracle.com/javase/tutorial/uiswing/events/actionlistener.html >> ? >> >> >>> On 27.09.2013 18:12, Anthony Petrov wrote: >>>> Thanks. I skimmed through the changes and they look good generally. A >>>> couple of nits: >>>> >>>> src/share/classes/java/awt/event/ActionListener.java >>>>> - * @see >>>> href="http://java.sun.com/docs/books/tutorial/post1.0/ui/eventmodel.html">Tutorial: >>>>> >>>>> Java 1.1 Event Model >>>> >>>> You're only removing the link here. You should add a new one, too, I >>>> guess. >>>> >>>> >>>> src/share/classes/sun/text/normalizer/UCharacter.java >>>>> - * >>>> href="http://java.sun.com/j2se/1.5/docs/api/java/lang/Character.html"> >>>>> + * >>>> href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Character.html"> >>>>> >>>>> >>>>> * java.lang.Character class. These extensions provide support >>>>> for >>>> >>>> I believe the here should be replaced with a usual javadoc's >>>> {@link ...} kind of thing. >>> Agree, and this should be done in all places, but this will be too much >>> changes for this fix. >> >> Certainly, we shouldn't change all and every occurrence of this. >> However, this line is updated in your fix anyway, so why not apply the >> correct pattern just for this particular case now? >> >> -- >> best regards, >> Anthony >> >> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 09/27/2013 04:50 PM, mikhail cherkasov wrote: >>>>> Hi Anthony, >>>>> >>>>> Please review a new version: >>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.02/ >>>>> >>>>> I rely on http redirect, but it doesn't always work correctly. Now I >>>>> re-checked all links. >>>>> >>>>> Thanks, >>>>> Mikhail. >>>>> >>>>> On 27.09.2013 12:42, Anthony Petrov wrote: >>>>>> Hi Mikhail, >>>>>> >>>>>> Please comment on the following: >>>>>> >>>>>> src/share/classes/java/awt/Component.java: >>>>>>> - * >>>>>> href="http://java.sun.com/products/jfc/tsc/articles/painting/index.html">Painting >>>>>>> >>>>>>> >>>>>>> in AWT and Swing. >>>>>>> + * >>>>>> href="http://www.oracle.com/technetwork/java/index.html">Painting in >>>>>>> AWT and Swing. >>>>>> >>>>>> The new link doesn't point to the "Painting..." article (and it is a >>>>>> very good article, btw). Could you please check all the new links and >>>>>> update the webrev? >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 09/26/2013 02:27 AM, mikhail cherkasov wrote: >>>>>>> a new webrev: >>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.01/ >>>>>>> >>>>>>> no changes, I've turned off laptop before the webrev upload was >>>>>>> complete, so >>>>>>> the first could be corrupted. >>>>>>> >>>>>>> On 25.09.2013 23:29, mikhail cherkasov wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Could you please review the fix for the following bug: >>>>>>>> 8020688: broken links in documentation at >>>>>>>> http://docs.oracle.com/javase/6/docs/api/index. >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020688 >>>>>>>> The webrev: http://cr.openjdk.java.net/~mcherkas/8020688/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Mikhail. >>>>>>> >>>>> >>> > From anthony.petrov at oracle.com Tue Oct 1 11:33:02 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 22:33:02 +0400 Subject: [7u] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol In-Reply-To: <524A6004.1020904@oracle.com> References: <524A6004.1020904@oracle.com> Message-ID: <524B155E.4000709@oracle.com> The fix looks fine to me. -- best regards, Anthony On 10/01/2013 09:39 AM, dmitry markov wrote: > Hello, > > Could you review a back-port of 7129133 to JDK 7u, please? The back-port > and the main fix integrated into jdk8 are slightly different. > > bug: http://bugs.sun.com/view_bug.do?bug_id=7129133 > webrev for jdk7u: http://cr.openjdk.java.net/~dmarkov/7129133/webrev.00/ > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/602e5d0141d3 > technical review for jdk8: > http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005450.html > > Thanks, > Dmitry From anthony.petrov at oracle.com Tue Oct 1 11:34:40 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 22:34:40 +0400 Subject: [8] Review request for 7068423: Spec for java.awt.GraphicsDevice.getFullScreenWindow() needs clarification In-Reply-To: <524AC214.3000806@oracle.com> References: <524AC214.3000806@oracle.com> Message-ID: <524B15C0.1040402@oracle.com> Looks fine. -- best regards, Anthony On 10/01/2013 04:37 PM, Oleg Pekhovskiy wrote: > Hi all, > > please review the fix > http://cr.openjdk.java.net/~bagiras/7068423.1/ > for > https://bugs.openjdk.java.net/browse/JDK-7068423 > > It's just a Javadoc fix. > > Thanks, > Oleg From anthony.petrov at oracle.com Tue Oct 1 11:38:21 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 22:38:21 +0400 Subject: [8] Review request: JDK-8024600 [macosx] code prevents use of -Xlint:auxiliaryclass, empty in jdk build In-Reply-To: References: Message-ID: <524B169D.5080106@oracle.com> I didn't make a line-to-line comparison of the classes moved to files, but the changes looks good to me generally. -- best regards, Anthony On 10/01/2013 04:51 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8024600 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/8024600/webrev.00/ > > The warnings were fixed. The only behavioural change is in the AquaMenuBarUI: previously the if result was ignored, > but it's incorrect: we should return (0, 0) only if we succeeded in setting the screen menu bar, I suppose that semicolon was a typo. > > With best regards. Petr. > From anthony.petrov at oracle.com Tue Oct 1 11:42:26 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 22:42:26 +0400 Subject: [8] Review request for 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. In-Reply-To: References: <5245BF90.4010001@oracle.com> <291D11C7-FAFB-45D0-9494-6BC4591B2F97@oracle.com> Message-ID: <524B1792.3040105@oracle.com> The fix looks good to me as well. -- best regards, Anthony On 10/01/2013 08:06 PM, Leonid Romanov wrote: > I've investigated this issue and couldn't find a situation where the call to XToolkit.targetDisposedPeer() from XBaseMenuWindow.doDispose() would make sense (we call XToolkit.targetDisposedPeer() with correct targets in XPopupMenuPeer and XMenuBarPeer), so I decided to remove it to avoid any confusion in the future. We still have the time to fix any regressions, in case they arise. Here is an updated webrev: > > http://cr.openjdk.java.net/~leonidr/8023994/webrev.01/ > > On Sep 27, 2013, at 9:33 PM, Leonid Romanov wrote: > >> Yes, this code looked suspicious for me as well, I suspect it is a result of copy pasting XWindow's dispose() code. For a wrong peer/target pair, XToolkit.targetDisposedPeer() is a no-op, so no harm is done, but perhaps it makes sense to remove that call altogether. I'll check it. >> >> On Sep 27, 2013, at 9:25 PM, Sergey Bylokhov wrote: >> >>> Hi, Leonid. >>> In this case the code in the XBaseMenuWindow.doDispose() call XToolkit.targetDisposedPeer(target, this); for the wrong target? Or probably this target is alwase null? >>> >>> On 27.09.2013 20:32, Leonid Romanov wrote: >>>> Hello, >>>> Please review a fix for 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. The problem here is that for popup menus the "target" field of XBaseMenuWindow class is not a MenuComponent corresponding to the popup, but a component for which the popup is being shown. Therefore, if the menu has never been shown, the the target is null, so we can't use it for the InvocationEvent in dispose(). >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023994 >>>> Webrev: http://cr.openjdk.java.net/~leonidr/8023994/webrev.00/ >>>> >>>> Thanks, >>>> Leonid. >>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> > From anthony.petrov at oracle.com Tue Oct 1 14:03:24 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 Oct 2013 01:03:24 +0400 Subject: [8] Review request for 7158311 GraphicsDevice.setDisplayMode(...) leads to hang when DISPLAY variable points to Oracle Linux In-Reply-To: <524ADDC9.8060103@oracle.com> References: <524ADDC9.8060103@oracle.com> Message-ID: <524B389C.7090601@oracle.com> The fix looks fine to me. -- best regards, Anthony On 10/01/2013 06:35 PM, Alexander Zvegintsev wrote: > Hello, > > Could you please review a fix for following issues: > https://bugs.openjdk.java.net/browse/JDK-7158311 > https://bugs.openjdk.java.net/browse/JDK-8001463 > > webrev: > http://cr.openjdk.java.net/~serb/alexz/7158311/webrev.00/ > > All X11 implementations of DisplayChangedListener does not call any X11 > routines, hence > SunGraphicsEnvironment.displayChanged() callback does not require an > AWTLock and we > can temporarily release it to avoid deadlock. > From srikalyan.chandrashekar at oracle.com Tue Oct 1 14:51:43 2013 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Tue, 01 Oct 2013 14:51:43 -0700 Subject: [8] Review request for JDK-8025684 - Fix Raw and unchecked warnings java.awt.image classes Message-ID: <524B43EF.4080603@oracle.com> Hi team , could someone review the fix Bug : https://bugs.openjdk.java.net/browse/JDK-8025684 Webrev : https://github.com/srikalyc/JDKfixes/blob/master/java.awt.image.raw_unchecked_webrev.zip Fix : Raw and unchecked warnings in AWT image classes fixed -- -- Thanks kalyan From mikhail.cherkasov at oracle.com Wed Oct 2 00:20:11 2013 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Wed, 02 Oct 2013 11:20:11 +0400 Subject: [7] Review request for backport of 8023310- Fix Raw and unchecked warnings java.awt.image classes Message-ID: <524BC92B.5070500@oracle.com> Hello all, Please review a backport for the following bug: https://bugs.openjdk.java.net/browse/JDK-8023310 webrev: http://cr.openjdk.java.net/~mcherkas/8023310/webrev.00/ Thanks, Mikhail. From petr.pchelko at oracle.com Wed Oct 2 00:21:11 2013 From: petr.pchelko at oracle.com (petr.pchelko at oracle.com) Date: Wed, 02 Oct 2013 07:21:11 +0000 Subject: hg: jdk8/awt/jdk: 7124363: [macosx] ClassCastException: CFileDialog cannot be cast to LWWindowPeer Message-ID: <20131002072152.ADDFF62C8E@hg.openjdk.java.net> Changeset: 5e205645d990 Author: pchelko Date: 2013-10-02 11:18 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5e205645d990 7124363: [macosx] ClassCastException: CFileDialog cannot be cast to LWWindowPeer Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/LWWindowPeer.java From petr.pchelko at oracle.com Wed Oct 2 00:31:46 2013 From: petr.pchelko at oracle.com (petr.pchelko at oracle.com) Date: Wed, 02 Oct 2013 07:31:46 +0000 Subject: hg: jdk8/awt/jdk: 8024163: [macosx] NullPointerException at javax.swing.TransferHandler$DropHandler.handleDrag since jdk8b93, 7u40b28 Message-ID: <20131002073158.0C31962C91@hg.openjdk.java.net> Changeset: 1189f954d52f Author: pchelko Date: 2013-10-02 11:32 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1189f954d52f 8024163: [macosx] NullPointerException at javax.swing.TransferHandler$DropHandler.handleDrag since jdk8b93, 7u40b28 Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java ! src/macosx/native/sun/awt/CDropTarget.m + test/java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java + test/java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java From petr.pchelko at oracle.com Wed Oct 2 00:49:57 2013 From: petr.pchelko at oracle.com (petr.pchelko at oracle.com) Date: Wed, 02 Oct 2013 07:49:57 +0000 Subject: hg: jdk8/awt/jdk: 8024600: [macosx] code prevents use of -Xlint:auxiliaryclass, empty in jdk build Message-ID: <20131002075009.AFE5562C93@hg.openjdk.java.net> Changeset: 01198c681710 Author: pchelko Date: 2013-10-02 11:50 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/01198c681710 8024600: [macosx] code prevents use of -Xlint:auxiliaryclass,empty in jdk build Reviewed-by: anthony, serb ! src/macosx/classes/com/apple/eawt/_AppEventLegacyHandler.java + src/macosx/classes/com/apple/eawt/_OpenAppHandler.java ! src/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java + src/macosx/classes/com/apple/laf/AquaComboBoxRendererInternal.java ! src/macosx/classes/com/apple/laf/AquaMenuBarUI.java From artem.ananiev at oracle.com Wed Oct 2 03:02:41 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 Oct 2013 14:02:41 +0400 Subject: [8] Review request for JDK-8025684 - Fix Raw and unchecked warnings java.awt.image classes In-Reply-To: <524B43EF.4080603@oracle.com> References: <524B43EF.4080603@oracle.com> Message-ID: <524BEF41.2000304@oracle.com> java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to CC. Please, wait for at least one approval from Java2D team. For easier review, I put the webrev here: http://cr.openjdk.java.net/~art/srikalyc/8025684.00/ It looks fine to me. There is one "unchecked" warning still left, at BufferedImage.java:645, it can be fixed by introducing a local variable and @SuppressWarnings("unchecked"), but I'm not sure it's worth doing. Thanks, Artem On 10/2/2013 1:51 AM, srikalyan chandrashekar wrote: > Hi team , could someone review the fix > Bug : https://bugs.openjdk.java.net/browse/JDK-8025684 > Webrev : > https://github.com/srikalyc/JDKfixes/blob/master/java.awt.image.raw_unchecked_webrev.zip > > Fix : Raw and unchecked warnings in AWT image classes fixed > From christine.lu at oracle.com Tue Oct 1 17:05:37 2013 From: christine.lu at oracle.com (christine.lu at oracle.com) Date: Tue, 01 Oct 2013 17:05:37 -0700 Subject: Review request for JDK-8025409: Fix javadoc comments errors and warning reported by doclint report Message-ID: <524B6351.4090307@oracle.com> Hi, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8025409 Fix javadoc comments errors and warning reported by doclint report webrev: http://cr.openjdk.java.net/~cl/8025409/webrev.00/ Thanks Christine From artem.ananiev at oracle.com Wed Oct 2 03:12:11 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 Oct 2013 14:12:11 +0400 Subject: [8] Review request for 8013563: Memory leak in JFrame on Linux In-Reply-To: <524AE2CA.30204@oracle.com> References: <524AE2CA.30204@oracle.com> Message-ID: <524BF17B.9030903@oracle.com> Tho short questions: 1. Is a new weak reference (victimWindowRef) really required? Can't we re-use weakThis, which is victim.weakThis? 2. When a window is deserialized, does it have an owner? Shouldn't we call WDR.updateOwner() in initDeserializedWindow()? Thanks, Artem On 10/1/2013 6:57 PM, Alexander Zvegintsev wrote: > Hello, > > please review a fix for following issue: > https://bugs.openjdk.java.net/browse/JDK-8013563 > webrev: > http://cr.openjdk.java.net/~serb/alexz/8013563/webrev.00/ > > This issue is a regression of 6758673 changes in java.awt.Window, where > call to Disposer.addRecord > was moved from init(gc) to ownedInit(). But we have constructors without > a ownedInit() call, hence > we never call removeFromWindowList() for Frame. > From sergey.malenkov at oracle.com Wed Oct 2 03:32:08 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Wed, 02 Oct 2013 14:32:08 +0400 Subject: [7] Review request for backport of 8023310: Thread contention in the method Beans.IsDesignTime() In-Reply-To: <524BC92B.5070500@oracle.com> References: <524BC92B.5070500@oracle.com> Message-ID: <524BF628.8090208@oracle.com> I changed the subject, which is incorrect. The backport looks good. Do you have a build for Windows to test a performance? Thanks, SAM On 02.10.2013 11:20, mikhail cherkasov wrote: > Hello all, > > Please review a backport for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8023310 > webrev: > http://cr.openjdk.java.net/~mcherkas/8023310/webrev.00/ > > > Thanks, > Mikhail. > From anthony.petrov at oracle.com Wed Oct 2 03:34:30 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 Oct 2013 14:34:30 +0400 Subject: [8] Review request for 7174704: [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure Message-ID: <524BF6B6.9020306@oracle.com> Hello, Please review a long-awaited back-port of a fix for https://bugs.openjdk.java.net/browse/JDK-7174704 at: http://cr.openjdk.java.net/~anthony/8-61-headlessPrinting-7174704.0/ It is not a direct back-port because the code in JDK8 slightly differs from 7u, but the basic idea is the same: we always load the lwawt dynamic library on Mac, regardless of the headless/headful mode. Also with this fix I remove support for the undocumented AWT_TOOLKIT environment variable. It's become obsolete with removal of the MToolkit from JDK7. For selecting custom toolkits users still can use the documented -Dawt.toolkit= system property. I've tested the fix with a test mentioned in the bug report, and it passes well. -- best regards, Anthony From artem.ananiev at oracle.com Wed Oct 2 03:45:01 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 Oct 2013 14:45:01 +0400 Subject: [8] Review request for 7174704: [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure In-Reply-To: <524BF6B6.9020306@oracle.com> References: <524BF6B6.9020306@oracle.com> Message-ID: <524BF92D.9030204@oracle.com> Looks fine. Thanks, Artem On 10/2/2013 2:34 PM, Anthony Petrov wrote: > Hello, > > Please review a long-awaited back-port of a fix for > https://bugs.openjdk.java.net/browse/JDK-7174704 at: > > http://cr.openjdk.java.net/~anthony/8-61-headlessPrinting-7174704.0/ > > It is not a direct back-port because the code in JDK8 slightly differs > from 7u, but the basic idea is the same: we always load the lwawt > dynamic library on Mac, regardless of the headless/headful mode. > > Also with this fix I remove support for the undocumented AWT_TOOLKIT > environment variable. It's become obsolete with removal of the MToolkit > from JDK7. For selecting custom toolkits users still can use the > documented -Dawt.toolkit= system property. > > I've tested the fix with a test mentioned in the bug report, and it > passes well. > > -- > best regards, > Anthony From oleg.pekhovskiy at oracle.com Wed Oct 2 03:52:09 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Wed, 02 Oct 2013 14:52:09 +0400 Subject: [8] Review request for 7033533: realSync() doesn't work with Xfce In-Reply-To: <524AB228.80803@oracle.com> References: <5242D93C.4070809@oracle.com> <5242EEF6.2010609@oracle.com> <5243E8C4.7060004@oracle.com> <524AB228.80803@oracle.com> Message-ID: <524BFAD9.8080103@oracle.com> Hi Anthony, thank you for the review, please see my comment below... On 01.10.2013 15:29, Anthony Petrov wrote: > Hi Oleg, > > I second to Leonid: you should add a comment and explain why you expect > exactly 4 (or more) events to be processed. Preferably, you should list > each event to clearly understand this. I'll investigate why the previous number was 2... > > A minor comment is, lines 2404 - 2407 should be moved to the nearest > try{} block at line 2409. Agree. > > A major concern is that I'm not sure the new solution is reliable in all > cases. Previously, we expected to get a notification from another > process (the WM). Now we process the notification ourselves and are the > owners of the selection. I don't know for sure, but suppose some xlib > implementations could optimize this scenario and process events locally > w/o even sending them to the X server. In which case there wouldn't be > any real synchronization of the native event queue. That's why > communicating with another process was an important part of this procedure. > > How about we try the original method first, and only if it fails, then > try this workaround solution? In my fix XSendEvent is used to send SelectionNotify event and in the doc http://www.x.org/archive/X11R7.5/doc/man/man3/XSendEvent.3.html there is a paragraph saying that XSendEvent always works with the server: "The event in the XEvent structure must be one of the core events or one of the events defined by an extension (or a BadValue error results) so that the X server can correctly byte-swap the contents as necessary. The contents of the event are otherwise unaltered and unchecked by the X server except to force send_event to True in the forwarded event and to set the serial number in the event correctly; therefore these fields and the display field are ignored by XSendEvent." So no optimization expected in this case. Leaving the original method along with the new one will complicate the code and could produce pitfalls. IMHO it would be better to thoroughly test my fix. > > Also, this is a very sensitive method because a lot of code relies on > it. I suggest running all automatic regression tests for AWT and Swing > areas to make sure we don't introduce a regression with this fix. As I mentioned Yuri ran tests on XFCE and LXDE. But we could do even more of course. > > -- > best regards, > Anthony > > On 09/26/2013 11:56 AM, Oleg Pekhovskiy wrote: >> Hi Leonid, >> >> I did it mostly logically, because my fix added one more service event >> (SelectionRequest), that should be excluded from the number of >> dispatched native events. >> IMHO, the previous number "2" should have been commented, but, that did >> not happen. >> >> Thanks, >> Oleg >> >> On 25.09.2013 18:11, Leonid Romanov wrote: >>> Hi, >>> I'm not an expert in X11 programming, so I can't comment about the fix >>> in general, but I think the line 2436, "return getEventNumber() - >>> event_number > 3", really asks for a comment. >>> >>> On 9/25/2013 16:38, Oleg Pekhovskiy wrote: >>>> Hi all, >>>> >>>> please review the fix >>>> http://cr.openjdk.java.net/~bagiras/7033533.1/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-7033533 >>>> >>>> Previous implementation of XToolkit.syncNativeQueue() relied upon >>>> WM_S0 atom existence and that it was owned by current window manager. >>>> But several WMs (like XFCE and LXDE) don't send SelectionNotify event >>>> to the client on XConvertSelection() for that atom. That led >>>> XToolkit.syncNativeQueue() to hang until TimeOutException. >>>> >>>> I decided to keep XConvertSelection() usage, but make root toolkit >>>> window as an owner for selection atom (with another name), and handle >>>> SelectionRequest event from X Server, sending SelectionNotify in >>>> response (as window manager is supposed to do). >>>> >>>> Tested on both XFCE and LXDE. >>>> >>>> Thanks, >>>> Oleg >>> From sergey.malenkov at oracle.com Wed Oct 2 04:31:29 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Wed, 02 Oct 2013 15:31:29 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524B0ACA.2060708@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> Message-ID: <524C0411.7060709@oracle.com> This bug is about javadoc. What if I replace "the default toolkit" with "the current window toolkit"? As I understand the Peer API is not public. So we can modify it without thinking about backward compatibility. Thanks, SAM On 01.10.2013 21:47, Anthony Petrov wrote: > Hi Sergey, > > I'm wondering what compatibility impact of this change is. The > specification for Component.getToolkit() suggests that in theory > several toolkits may co-exist in a single application. And thanks to > delegating to the ComponentPeer, the Component.getToolkit() could > return the actual toolkit for this component. > > However, your fix effectively disallows a component to belong to any > toolkit other than the default one, because its getToolkit() will > never return anything else (unless you extend the component's class > and override the method). > > I really don't know whether this is widely used, but I think this may > impact some applications. > > Also, imagine a window is made to belong to another toolkit somehow, > even with your changes. Now, why should its ability to be > always-on-top depend on the default toolkit instead of the window's > own toolkit? > > -- > best regards, > Anthony > > On 09/27/2013 08:49 PM, sergey malenkov wrote: >> Hello, >> >> Could you please review the following fix: >> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >> >> The specification of the Window class waits for CCC approval. This fix >> removes the getTookit method from the ComponentPeer class and its >> subclasses. >> >> Thanks, >> SAM >> From mikhail.cherkasov at oracle.com Wed Oct 2 04:58:09 2013 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Wed, 02 Oct 2013 15:58:09 +0400 Subject: [7] Review request for backport of 8023310: Thread contention in the method Beans.IsDesignTime() In-Reply-To: <524BF628.8090208@oracle.com> References: <524BC92B.5070500@oracle.com> <524BF628.8090208@oracle.com> Message-ID: <524C0A51.7070809@oracle.com> Hi Sergey, here is results of benchmark: with fix: Result : 103130,558 ?(95%) 381,949 ?(99%) 522,101 ops/ms without fix: Result : 15276,871 ?(95%) 12,841 ?(99%) 17,553 ops/ms What did you change the subject? as I can see you use the same subject in your commit: 8023310: Thread contention in the method Beans.IsDesignTime() http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a284da808700 Thanks, Mikhail. On 02.10.2013 14:32, sergey malenkov wrote: > I changed the subject, which is incorrect. The backport looks good. > Do you have a build for Windows to test a performance? > > Thanks, > SAM > > On 02.10.2013 11:20, mikhail cherkasov wrote: >> Hello all, >> >> Please review a backport for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8023310 >> webrev: >> http://cr.openjdk.java.net/~mcherkas/8023310/webrev.00/ >> >> >> Thanks, >> Mikhail. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131002/853c63e9/attachment.html From petr.pchelko at oracle.com Wed Oct 2 05:17:01 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Oct 2013 16:17:01 +0400 Subject: [8] Review Request: JDK-8024158 [macosx] java/awt/EventDispatchThread/LoopRobustness/LoopRobustness still failed after fix JDK-8022247; since jdk8b96 Message-ID: <3F09AC65-BB40-49DA-A20E-990A12373642@oracle.com> Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8024158 The fix is available at: http://cr.openjdk.java.net/~pchelko/8024158/webrev.00/ The problem: Appkit thread could not have an AppContext, so we cannot call KeyboardFocusManager. getCurrentKeyboardFocusManager on it. The solution: use the Window AppContext to get the KeyboardFocusManager. With best regards. Petr. From anthony.petrov at oracle.com Wed Oct 2 05:26:55 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 Oct 2013 16:26:55 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524C0411.7060709@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> <524C0411.7060709@oracle.com> Message-ID: <524C110F.6000905@oracle.com> On 10/02/2013 03:31 PM, sergey malenkov wrote: > This bug is about javadoc. What if I replace "the default toolkit" with > "the current window toolkit"? I'd be fine with such a change. > As I understand the Peer API is not public. So we can modify it without > thinking about backward compatibility. We can. But I don't think this is necessary for this fix at all. -- best regards, Anthony > > Thanks, > SAM > > On 01.10.2013 21:47, Anthony Petrov wrote: >> Hi Sergey, >> >> I'm wondering what compatibility impact of this change is. The >> specification for Component.getToolkit() suggests that in theory >> several toolkits may co-exist in a single application. And thanks to >> delegating to the ComponentPeer, the Component.getToolkit() could >> return the actual toolkit for this component. >> >> However, your fix effectively disallows a component to belong to any >> toolkit other than the default one, because its getToolkit() will >> never return anything else (unless you extend the component's class >> and override the method). >> >> I really don't know whether this is widely used, but I think this may >> impact some applications. >> >> Also, imagine a window is made to belong to another toolkit somehow, >> even with your changes. Now, why should its ability to be >> always-on-top depend on the default toolkit instead of the window's >> own toolkit? >> >> -- >> best regards, >> Anthony >> >> On 09/27/2013 08:49 PM, sergey malenkov wrote: >>> Hello, >>> >>> Could you please review the following fix: >>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >>> >>> The specification of the Window class waits for CCC approval. This fix >>> removes the getTookit method from the ComponentPeer class and its >>> subclasses. >>> >>> Thanks, >>> SAM >>> > From artem.ananiev at oracle.com Wed Oct 2 05:29:29 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 Oct 2013 16:29:29 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524C0411.7060709@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> <524C0411.7060709@oracle.com> Message-ID: <524C11A9.3000307@oracle.com> On 10/2/2013 3:31 PM, sergey malenkov wrote: > This bug is about javadoc. What if I replace "the default toolkit" with > "the current window toolkit"? "The current window toolkit" sounds strange. It should be clarified or replaced with "this window's toolkit" + {@see #getToolkit}. Thanks, Artem > As I understand the Peer API is not public. So we can modify it without > thinking about backward compatibility. > > Thanks, > SAM > > On 01.10.2013 21:47, Anthony Petrov wrote: >> Hi Sergey, >> >> I'm wondering what compatibility impact of this change is. The >> specification for Component.getToolkit() suggests that in theory >> several toolkits may co-exist in a single application. And thanks to >> delegating to the ComponentPeer, the Component.getToolkit() could >> return the actual toolkit for this component. >> >> However, your fix effectively disallows a component to belong to any >> toolkit other than the default one, because its getToolkit() will >> never return anything else (unless you extend the component's class >> and override the method). >> >> I really don't know whether this is widely used, but I think this may >> impact some applications. >> >> Also, imagine a window is made to belong to another toolkit somehow, >> even with your changes. Now, why should its ability to be >> always-on-top depend on the default toolkit instead of the window's >> own toolkit? >> >> -- >> best regards, >> Anthony >> >> On 09/27/2013 08:49 PM, sergey malenkov wrote: >>> Hello, >>> >>> Could you please review the following fix: >>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >>> >>> The specification of the Window class waits for CCC approval. This fix >>> removes the getTookit method from the ComponentPeer class and its >>> subclasses. >>> >>> Thanks, >>> SAM >>> > From artem.ananiev at oracle.com Wed Oct 2 05:30:39 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 Oct 2013 16:30:39 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524C110F.6000905@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> <524C0411.7060709@oracle.com> <524C110F.6000905@oracle.com> Message-ID: <524C11EF.2040905@oracle.com> On 10/2/2013 4:26 PM, Anthony Petrov wrote: > On 10/02/2013 03:31 PM, sergey malenkov wrote: >> This bug is about javadoc. What if I replace "the default toolkit" with >> "the current window toolkit"? > > I'd be fine with such a change. > > >> As I understand the Peer API is not public. So we can modify it without >> thinking about backward compatibility. > > We can. But I don't think this is necessary for this fix at all. You're right, it's not necessary. However, since we touch this code anyway, I'd be glad to have this redundant code removed. Thanks, Artem > -- > best regards, > Anthony > >> >> Thanks, >> SAM >> >> On 01.10.2013 21:47, Anthony Petrov wrote: >>> Hi Sergey, >>> >>> I'm wondering what compatibility impact of this change is. The >>> specification for Component.getToolkit() suggests that in theory >>> several toolkits may co-exist in a single application. And thanks to >>> delegating to the ComponentPeer, the Component.getToolkit() could >>> return the actual toolkit for this component. >>> >>> However, your fix effectively disallows a component to belong to any >>> toolkit other than the default one, because its getToolkit() will >>> never return anything else (unless you extend the component's class >>> and override the method). >>> >>> I really don't know whether this is widely used, but I think this may >>> impact some applications. >>> >>> Also, imagine a window is made to belong to another toolkit somehow, >>> even with your changes. Now, why should its ability to be >>> always-on-top depend on the default toolkit instead of the window's >>> own toolkit? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 09/27/2013 08:49 PM, sergey malenkov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix: >>>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >>>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >>>> >>>> The specification of the Window class waits for CCC approval. This fix >>>> removes the getTookit method from the ComponentPeer class and its >>>> subclasses. >>>> >>>> Thanks, >>>> SAM >>>> >> From artem.ananiev at oracle.com Wed Oct 2 05:31:19 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 Oct 2013 16:31:19 +0400 Subject: [8] Review Request: JDK-8024158 [macosx] java/awt/EventDispatchThread/LoopRobustness/LoopRobustness still failed after fix JDK-8022247; since jdk8b96 In-Reply-To: <3F09AC65-BB40-49DA-A20E-990A12373642@oracle.com> References: <3F09AC65-BB40-49DA-A20E-990A12373642@oracle.com> Message-ID: <524C1217.5080000@oracle.com> Looks fine. Thanks, Artem On 10/2/2013 4:17 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8024158 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/8024158/webrev.00/ > > The problem: Appkit thread could not have an AppContext, so we cannot call KeyboardFocusManager. getCurrentKeyboardFocusManager on it. > > The solution: use the Window AppContext to get the KeyboardFocusManager. > > With best regards. Petr. > From anthony.petrov at oracle.com Wed Oct 2 05:38:10 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 Oct 2013 16:38:10 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524C11EF.2040905@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> <524C0411.7060709@oracle.com> <524C110F.6000905@oracle.com> <524C11EF.2040905@oracle.com> Message-ID: <524C13B2.2020700@oracle.com> On 10/02/2013 04:30 PM, Artem Ananiev wrote: > > On 10/2/2013 4:26 PM, Anthony Petrov wrote: >> On 10/02/2013 03:31 PM, sergey malenkov wrote: >>> This bug is about javadoc. What if I replace "the default toolkit" with >>> "the current window toolkit"? >> >> I'd be fine with such a change. >> >> >>> As I understand the Peer API is not public. So we can modify it without >>> thinking about backward compatibility. >> >> We can. But I don't think this is necessary for this fix at all. > > You're right, it's not necessary. However, since we touch this code > anyway, I'd be glad to have this redundant code removed. It's not redundant. Please see my message below in the quote for details. -- best regards, Anthony > > Thanks, > > Artem > >> -- >> best regards, >> Anthony >> >>> >>> Thanks, >>> SAM >>> >>> On 01.10.2013 21:47, Anthony Petrov wrote: >>>> Hi Sergey, >>>> >>>> I'm wondering what compatibility impact of this change is. The >>>> specification for Component.getToolkit() suggests that in theory >>>> several toolkits may co-exist in a single application. And thanks to >>>> delegating to the ComponentPeer, the Component.getToolkit() could >>>> return the actual toolkit for this component. >>>> >>>> However, your fix effectively disallows a component to belong to any >>>> toolkit other than the default one, because its getToolkit() will >>>> never return anything else (unless you extend the component's class >>>> and override the method). >>>> >>>> I really don't know whether this is widely used, but I think this may >>>> impact some applications. >>>> >>>> Also, imagine a window is made to belong to another toolkit somehow, >>>> even with your changes. Now, why should its ability to be >>>> always-on-top depend on the default toolkit instead of the window's >>>> own toolkit? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 09/27/2013 08:49 PM, sergey malenkov wrote: >>>>> Hello, >>>>> >>>>> Could you please review the following fix: >>>>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >>>>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >>>>> >>>>> The specification of the Window class waits for CCC approval. This fix >>>>> removes the getTookit method from the ComponentPeer class and its >>>>> subclasses. >>>>> >>>>> Thanks, >>>>> SAM >>>>> >>> From sergey.malenkov at oracle.com Wed Oct 2 05:41:14 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Wed, 02 Oct 2013 16:41:14 +0400 Subject: Approved: [7] Review request for backport of 8023310: Thread contention in the method Beans.IsDesignTime() In-Reply-To: <524C0A51.7070809@oracle.com> References: <524BC92B.5070500@oracle.com> <524BF628.8090208@oracle.com> <524C0A51.7070809@oracle.com> Message-ID: <524C146A.4020400@oracle.com> I approve. > here is results of benchmark: > with fix: Result : 103130,558 ?(95%) 381,949 ?(99%) 522,101 ops/ms > without fix: Result : 15276,871 ?(95%) 12,841 ?(99%) 17,553 ops/ms Excellent! > What did you change the subject? as I can see you use the same subject > in your commit: > 8023310: Thread contention in the method Beans.IsDesignTime() > http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a284da808700 See the subject of your first letter. I almost missed it. SAM > Thanks, > Mikhail. > > On 02.10.2013 14:32, sergey malenkov wrote: >> I changed the subject, which is incorrect. The backport looks good. >> Do you have a build for Windows to test a performance? >> >> Thanks, >> SAM >> >> On 02.10.2013 11:20, mikhail cherkasov wrote: >>> Hello all, >>> >>> Please review a backport for the following bug: >>> https://bugs.openjdk.java.net/browse/JDK-8023310 >>> webrev: >>> http://cr.openjdk.java.net/~mcherkas/8023310/webrev.00/ >>> >>> >>> Thanks, >>> Mikhail. >>> >> > From leonid.romanov at oracle.com Wed Oct 2 05:43:24 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 02 Oct 2013 16:43:24 +0400 Subject: [8] Review Request: JDK-8024158 [macosx] java/awt/EventDispatchThread/LoopRobustness/LoopRobustness still failed after fix JDK-8022247; since jdk8b96 In-Reply-To: <3F09AC65-BB40-49DA-A20E-990A12373642@oracle.com> References: <3F09AC65-BB40-49DA-A20E-990A12373642@oracle.com> Message-ID: <524C14EC.60300@oracle.com> Looks good, assuming that the rest of the requestWindowFocus() code doesn't call anything that eventually calls getAppContext(). On 10/2/2013 16:17, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8024158 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/8024158/webrev.00/ > > The problem: Appkit thread could not have an AppContext, so we cannot call KeyboardFocusManager. getCurrentKeyboardFocusManager on it. > > The solution: use the Window AppContext to get the KeyboardFocusManager. > > With best regards. Petr. From anthony.petrov at oracle.com Wed Oct 2 05:45:22 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 Oct 2013 16:45:22 +0400 Subject: [8] Review request for 7033533: realSync() doesn't work with Xfce In-Reply-To: <524BFAD9.8080103@oracle.com> References: <5242D93C.4070809@oracle.com> <5242EEF6.2010609@oracle.com> <5243E8C4.7060004@oracle.com> <524AB228.80803@oracle.com> <524BFAD9.8080103@oracle.com> Message-ID: <524C1562.2030107@oracle.com> On 10/02/2013 02:52 PM, Oleg Pekhovskiy wrote: > On 01.10.2013 15:29, Anthony Petrov wrote: >> I second to Leonid: you should add a comment and explain why you expect >> exactly 4 (or more) events to be processed. Preferably, you should list >> each event to clearly understand this. > > I'll investigate why the previous number was 2... > >> A minor comment is, lines 2404 - 2407 should be moved to the nearest >> try{} block at line 2409. > > Agree. Thanks. >> A major concern is that I'm not sure the new solution is reliable in all >> cases. Previously, we expected to get a notification from another >> process (the WM). Now we process the notification ourselves and are the >> owners of the selection. I don't know for sure, but suppose some xlib >> implementations could optimize this scenario and process events locally >> w/o even sending them to the X server. In which case there wouldn't be >> any real synchronization of the native event queue. That's why >> communicating with another process was an important part of this >> procedure. >> >> How about we try the original method first, and only if it fails, then >> try this workaround solution? > > In my fix XSendEvent is used to send SelectionNotify event and in the > doc http://www.x.org/archive/X11R7.5/doc/man/man3/XSendEvent.3.html > there is a paragraph saying that XSendEvent always works with the server: > > "The event in the XEvent structure must be one of the core events or one > of the events defined by an extension (or a BadValue error results) so > that the X server can correctly byte-swap the contents as necessary. The > contents of the event are otherwise unaltered and unchecked by the X > server except to force send_event to True in the forwarded event and to > set the serial number in the event correctly; therefore these fields and > the display field are ignored by XSendEvent." > > So no optimization expected in this case. I don't see how this statement follows from the spec. An Xlib implementation could still optimize requests when they manipulate entities belonging to the same app. > Leaving the original method along with the new one will complicate the > code and could produce pitfalls. IMHO it would be better to thoroughly > test my fix. That would be fine to do early in JDK 8, or early in JDK 9. But at this point it is too risky for JDK 8. That's the reason Leonid and I suggest to make it a workaround rather than the main method for syncing the native event queue. -- best regards, Anthony >> Also, this is a very sensitive method because a lot of code relies on >> it. I suggest running all automatic regression tests for AWT and Swing >> areas to make sure we don't introduce a regression with this fix. > > As I mentioned Yuri ran tests on XFCE and LXDE. But we could do even > more of course. > >> >> -- >> best regards, >> Anthony >> >> On 09/26/2013 11:56 AM, Oleg Pekhovskiy wrote: >>> Hi Leonid, >>> >>> I did it mostly logically, because my fix added one more service event >>> (SelectionRequest), that should be excluded from the number of >>> dispatched native events. >>> IMHO, the previous number "2" should have been commented, but, that did >>> not happen. >>> >>> Thanks, >>> Oleg >>> >>> On 25.09.2013 18:11, Leonid Romanov wrote: >>>> Hi, >>>> I'm not an expert in X11 programming, so I can't comment about the fix >>>> in general, but I think the line 2436, "return getEventNumber() - >>>> event_number > 3", really asks for a comment. >>>> >>>> On 9/25/2013 16:38, Oleg Pekhovskiy wrote: >>>>> Hi all, >>>>> >>>>> please review the fix >>>>> http://cr.openjdk.java.net/~bagiras/7033533.1/ >>>>> for >>>>> https://bugs.openjdk.java.net/browse/JDK-7033533 >>>>> >>>>> Previous implementation of XToolkit.syncNativeQueue() relied upon >>>>> WM_S0 atom existence and that it was owned by current window manager. >>>>> But several WMs (like XFCE and LXDE) don't send SelectionNotify event >>>>> to the client on XConvertSelection() for that atom. That led >>>>> XToolkit.syncNativeQueue() to hang until TimeOutException. >>>>> >>>>> I decided to keep XConvertSelection() usage, but make root toolkit >>>>> window as an owner for selection atom (with another name), and handle >>>>> SelectionRequest event from X Server, sending SelectionNotify in >>>>> response (as window manager is supposed to do). >>>>> >>>>> Tested on both XFCE and LXDE. >>>>> >>>>> Thanks, >>>>> Oleg >>>> From mikhail.cherkasov at oracle.com Wed Oct 2 05:52:41 2013 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Wed, 02 Oct 2013 16:52:41 +0400 Subject: Approved: [7] Review request for backport of 8023310: Thread contention in the method Beans.IsDesignTime() In-Reply-To: <524C146A.4020400@oracle.com> References: <524BC92B.5070500@oracle.com> <524BF628.8090208@oracle.com> <524C0A51.7070809@oracle.com> <524C146A.4020400@oracle.com> Message-ID: <524C1719.8050603@oracle.com> oh, thank you for subject fixing, I just copy/pasted email and updated only bug id and forgot to update the rest part. On 02.10.2013 16:41, sergey malenkov wrote: > I approve. >> here is results of benchmark: >> with fix: Result : 103130,558 ?(95%) 381,949 ?(99%) 522,101 ops/ms >> without fix: Result : 15276,871 ?(95%) 12,841 ?(99%) 17,553 ops/ms > Excellent! >> What did you change the subject? as I can see you use the same >> subject in your commit: >> 8023310: Thread contention in the method Beans.IsDesignTime() >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a284da808700 > See the subject of your first letter. I almost missed it. > > SAM >> Thanks, >> Mikhail. >> >> On 02.10.2013 14:32, sergey malenkov wrote: >>> I changed the subject, which is incorrect. The backport looks good. >>> Do you have a build for Windows to test a performance? >>> >>> Thanks, >>> SAM >>> >>> On 02.10.2013 11:20, mikhail cherkasov wrote: >>>> Hello all, >>>> >>>> Please review a backport for the following bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8023310 >>>> webrev: >>>> http://cr.openjdk.java.net/~mcherkas/8023310/webrev.00/ >>>> >>>> >>>> Thanks, >>>> Mikhail. >>>> >>> >> > From petr.pchelko at oracle.com Wed Oct 2 05:55:25 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Oct 2013 16:55:25 +0400 Subject: [8] Review Request: JDK-8024158 [macosx] java/awt/EventDispatchThread/LoopRobustness/LoopRobustness still failed after fix JDK-8022247; since jdk8b96 In-Reply-To: <524C14EC.60300@oracle.com> References: <3F09AC65-BB40-49DA-A20E-990A12373642@oracle.com> <524C14EC.60300@oracle.com> Message-ID: <771F93E4-53E0-4A23-BCC9-1E9A09C93445@oracle.com> Hello, Leonid. > Looks good, assuming that the rest of the requestWindowFocus() code doesn't call anything that eventually calls getAppContext(). I've looked through the code and it looks like it does not. Don't know any better way to verify this. With best regards. Petr. On Oct 2, 2013, at 4:43 PM, Leonid Romanov wrote: > Looks good, assuming that the rest of the requestWindowFocus() code doesn't call anything that eventually calls getAppContext(). > > On 10/2/2013 16:17, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8024158 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/8024158/webrev.00/ >> >> The problem: Appkit thread could not have an AppContext, so we cannot call KeyboardFocusManager. getCurrentKeyboardFocusManager on it. >> >> The solution: use the Window AppContext to get the KeyboardFocusManager. >> >> With best regards. Petr. > From anthony.petrov at oracle.com Wed Oct 2 05:58:59 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 Oct 2013 16:58:59 +0400 Subject: Review request for JDK-8025409: Fix javadoc comments errors and warning reported by doclint report In-Reply-To: <524B6351.4090307@oracle.com> References: <524B6351.4090307@oracle.com> Message-ID: <524C1893.1020405@oracle.com> Hi Christine, The fix looks fine to me. Thanks for cleaning up all these errors. -- best regards, Anthony On 10/02/2013 04:05 AM, christine.lu at oracle.com wrote: > Hi, > > Please review a fix for > > https://bugs.openjdk.java.net/browse/JDK-8025409 > Fix javadoc comments errors and warning reported by doclint report > > webrev: http://cr.openjdk.java.net/~cl/8025409/webrev.00/ > > Thanks > Christine From Sergey.Bylokhov at oracle.com Wed Oct 2 06:01:51 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 02 Oct 2013 17:01:51 +0400 Subject: [8] Review request for 7158311 GraphicsDevice.setDisplayMode(...) leads to hang when DISPLAY variable points to Oracle Linux In-Reply-To: <524B389C.7090601@oracle.com> References: <524ADDC9.8060103@oracle.com> <524B389C.7090601@oracle.com> Message-ID: <524C193F.7010908@oracle.com> Does anybody know why we use awtLock for soo long time in the toolkit loop? Especially why we call dispatchEvent() under this lock? On 02.10.2013 1:03, Anthony Petrov wrote: > The fix looks fine to me. > > -- > best regards, > Anthony > > On 10/01/2013 06:35 PM, Alexander Zvegintsev wrote: >> Hello, >> >> Could you please review a fix for following issues: >> https://bugs.openjdk.java.net/browse/JDK-7158311 >> https://bugs.openjdk.java.net/browse/JDK-8001463 >> >> webrev: >> http://cr.openjdk.java.net/~serb/alexz/7158311/webrev.00/ >> >> All X11 implementations of DisplayChangedListener does not call any X11 >> routines, hence >> SunGraphicsEnvironment.displayChanged() callback does not require an >> AWTLock and we >> can temporarily release it to avoid deadlock. >> -- Best regards, Sergey. From petr.pchelko at oracle.com Wed Oct 2 06:01:05 2013 From: petr.pchelko at oracle.com (petr.pchelko at oracle.com) Date: Wed, 02 Oct 2013 13:01:05 +0000 Subject: hg: jdk8/awt/jdk: 8024158: [macosx] java/awt/EventDispatchThread/LoopRobustness/LoopRobustness still failed after fix JDK-8022247; since jdk8b96 Message-ID: <20131002130229.36AC262CA0@hg.openjdk.java.net> Changeset: 287e0a7731ff Author: pchelko Date: 2013-10-02 16:58 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/287e0a7731ff 8024158: [macosx] java/awt/EventDispatchThread/LoopRobustness/LoopRobustness still failed after fix JDK-8022247; since jdk8b96 Reviewed-by: art, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java From artem.ananiev at oracle.com Wed Oct 2 06:07:05 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 Oct 2013 17:07:05 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524C13B2.2020700@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> <524C0411.7060709@oracle.com> <524C110F.6000905@oracle.com> <524C11EF.2040905@oracle.com> <524C13B2.2020700@oracle.com> Message-ID: <524C1A79.6030101@oracle.com> On 10/2/2013 4:38 PM, Anthony Petrov wrote: > On 10/02/2013 04:30 PM, Artem Ananiev wrote: >> >> On 10/2/2013 4:26 PM, Anthony Petrov wrote: >>> On 10/02/2013 03:31 PM, sergey malenkov wrote: >>>> This bug is about javadoc. What if I replace "the default toolkit" with >>>> "the current window toolkit"? >>> >>> I'd be fine with such a change. >>> >>> >>>> As I understand the Peer API is not public. So we can modify it without >>>> thinking about backward compatibility. >>> >>> We can. But I don't think this is necessary for this fix at all. >> >> You're right, it's not necessary. However, since we touch this code >> anyway, I'd be glad to have this redundant code removed. > > It's not redundant. Please see my message below in the quote for details. Do you mean the following quote: >>>>> However, your fix effectively disallows a component to belong to any >>>>> toolkit other than the default one, because its getToolkit() will >>>>> never return anything else (unless you extend the component's class >>>>> and override the method). ? Extending the Component class and providing different implementation for getToolkit() is the way to achieve this functionality. Without this extension, it doesn't matter if Component.getToolkit() calls to the peer or directly returns the default toolkit. Thanks, Artem > -- > best regards, > Anthony > >> >> Thanks, >> >> Artem >> >>> -- >>> best regards, >>> Anthony >>> >>>> >>>> Thanks, >>>> SAM >>>> >>>> On 01.10.2013 21:47, Anthony Petrov wrote: >>>>> Hi Sergey, >>>>> >>>>> I'm wondering what compatibility impact of this change is. The >>>>> specification for Component.getToolkit() suggests that in theory >>>>> several toolkits may co-exist in a single application. And thanks to >>>>> delegating to the ComponentPeer, the Component.getToolkit() could >>>>> return the actual toolkit for this component. >>>>> >>>>> However, your fix effectively disallows a component to belong to any >>>>> toolkit other than the default one, because its getToolkit() will >>>>> never return anything else (unless you extend the component's class >>>>> and override the method). >>>>> >>>>> I really don't know whether this is widely used, but I think this may >>>>> impact some applications. >>>>> >>>>> Also, imagine a window is made to belong to another toolkit somehow, >>>>> even with your changes. Now, why should its ability to be >>>>> always-on-top depend on the default toolkit instead of the window's >>>>> own toolkit? >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 09/27/2013 08:49 PM, sergey malenkov wrote: >>>>>> Hello, >>>>>> >>>>>> Could you please review the following fix: >>>>>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >>>>>> >>>>>> The specification of the Window class waits for CCC approval. This >>>>>> fix >>>>>> removes the getTookit method from the ComponentPeer class and its >>>>>> subclasses. >>>>>> >>>>>> Thanks, >>>>>> SAM >>>>>> >>>> From leonid.romanov at oracle.com Wed Oct 2 06:06:40 2013 From: leonid.romanov at oracle.com (leonid.romanov at oracle.com) Date: Wed, 02 Oct 2013 13:06:40 +0000 Subject: hg: jdk8/awt/jdk: 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. Message-ID: <20131002130700.B67D262CA1@hg.openjdk.java.net> Changeset: 244f2ee51f31 Author: leonidr Date: 2013-10-02 17:06 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/244f2ee51f31 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java From artem.ananiev at oracle.com Wed Oct 2 06:09:00 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 Oct 2013 17:09:00 +0400 Subject: [8] Review request for 7158311 GraphicsDevice.setDisplayMode(...) leads to hang when DISPLAY variable points to Oracle Linux In-Reply-To: <524C193F.7010908@oracle.com> References: <524ADDC9.8060103@oracle.com> <524B389C.7090601@oracle.com> <524C193F.7010908@oracle.com> Message-ID: <524C1AEC.3030301@oracle.com> On 10/2/2013 5:01 PM, Sergey Bylokhov wrote: > Does anybody know why we use awtLock for soo long time in the toolkit > loop? Especially why we call dispatchEvent() under this lock? It is by design. We do everything under the awtLock on the toolkit thread, except waiting for incoming events. Thanks, Artem > On 02.10.2013 1:03, Anthony Petrov wrote: >> The fix looks fine to me. >> >> -- >> best regards, >> Anthony >> >> On 10/01/2013 06:35 PM, Alexander Zvegintsev wrote: >>> Hello, >>> >>> Could you please review a fix for following issues: >>> https://bugs.openjdk.java.net/browse/JDK-7158311 >>> https://bugs.openjdk.java.net/browse/JDK-8001463 >>> >>> webrev: >>> http://cr.openjdk.java.net/~serb/alexz/7158311/webrev.00/ >>> >>> All X11 implementations of DisplayChangedListener does not call any X11 >>> routines, hence >>> SunGraphicsEnvironment.displayChanged() callback does not require an >>> AWTLock and we >>> can temporarily release it to avoid deadlock. >>> > > From alexander.potochkin at oracle.com Wed Oct 2 06:16:21 2013 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Wed, 02 Oct 2013 17:16:21 +0400 Subject: [7u] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol In-Reply-To: <524A6004.1020904@oracle.com> References: <524A6004.1020904@oracle.com> Message-ID: <524C1CA5.4050207@oracle.com> Looks good Thanks alexp On 10/1/2013 9:39 AM, dmitry markov wrote: > Hello, > > Could you review a back-port of 7129133 to JDK 7u, please? The > back-port and the main fix integrated into jdk8 are slightly different. > > bug: http://bugs.sun.com/view_bug.do?bug_id=7129133 > webrev for jdk7u: http://cr.openjdk.java.net/~dmarkov/7129133/webrev.00/ > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/602e5d0141d3 > technical review for jdk8: > http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005450.html > > Thanks, > Dmitry From petr.pchelko at oracle.com Wed Oct 2 06:33:02 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 2 Oct 2013 17:33:02 +0400 Subject: [8] Review Request: JDK-8025585 Win: Popups in JFXPanel do not receive MouseWheel events In-Reply-To: <524B0C3B.8080702@oracle.com> References: <5CBB81CC-BC3C-41A9-89C5-C1952582477A@oracle.com> <524B0395.7060803@oracle.com> <524B0C3B.8080702@oracle.com> Message-ID: Hello, Thank you for the review. > It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't. That was indeed an issue. I've got used to Mac behaviour and did not notice the problem. The new version of the fix is available here: http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/ Now we redispatch the wheel event only if the window is in the same process. With best regards. Petr. On Oct 1, 2013, at 9:54 PM, Artem Ananiev wrote: > > On 10/1/2013 9:17 PM, Anthony Petrov wrote: >> Hi Petr, >> >> MS Windows always sends WHEEL events to the focused window. And my >> testing shows that when you scroll the wheel outside of an AWT window, >> the scroll events are consumed (by AWT, supposedly). >> >> With your fix you seem to always redirect the events to the window under >> the mouse. Now suppose you have a 3rd-party window with a scroll bar in >> background (e.g. Windows Explorer). If an AWT window is currently >> focused, but you move the mouse pointer outside of it and above the >> Explorer window, and start scrolling, will the Explorer window scroll >> its contents? Currently it doesn't. What about if we apply your fix? > > It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't. > > Thanks, > > Artem > >> -- >> best regards, >> Anthony >> >> On 09/27/2013 07:24 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8025585 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/ >>> >>> The fix is needed for JFXPanel support. We need to redispatch >>> MOUSEWHEEL messages to the window under mouse. In case of Popups in a >>> JFXPanel the HWND belongs to a different tollkit, so we need to use >>> ::SendMessage to redispatch the message. >>> >>> With best regards. Petr. >>> From yuri.nesterenko at oracle.com Wed Oct 2 06:32:37 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 02 Oct 2013 17:32:37 +0400 Subject: Review request for JDK-8025409: Fix javadoc comments errors and warning reported by doclint report In-Reply-To: <524B6351.4090307@oracle.com> References: <524B6351.4090307@oracle.com> Message-ID: <524C2075.6050901@oracle.com> Hi Christine, the fix looks OK. Thanks, -yan On 10/02/2013 04:05 AM, christine.lu at oracle.com wrote: > Hi, > > Please review a fix for > > https://bugs.openjdk.java.net/browse/JDK-8025409 > Fix javadoc comments errors and warning reported by doclint report > > webrev: http://cr.openjdk.java.net/~cl/8025409/webrev.00/ > > Thanks > Christine From sergey.malenkov at oracle.com Wed Oct 2 06:34:20 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Wed, 02 Oct 2013 17:34:20 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524C11A9.3000307@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> <524C0411.7060709@oracle.com> <524C11A9.3000307@oracle.com> Message-ID: <524C20DC.70507@oracle.com> http://cr.openjdk.java.net/~malenkov/7081584.8.1/ The specification is updated. SAM On 02.10.2013 16:29, Artem Ananiev wrote: > > On 10/2/2013 3:31 PM, sergey malenkov wrote: >> This bug is about javadoc. What if I replace "the default toolkit" with >> "the current window toolkit"? > > "The current window toolkit" sounds strange. It should be clarified or > replaced with "this window's toolkit" + {@see #getToolkit}. > > Thanks, > > Artem > >> As I understand the Peer API is not public. So we can modify it without >> thinking about backward compatibility. >> >> Thanks, >> SAM >> >> On 01.10.2013 21:47, Anthony Petrov wrote: >>> Hi Sergey, >>> >>> I'm wondering what compatibility impact of this change is. The >>> specification for Component.getToolkit() suggests that in theory >>> several toolkits may co-exist in a single application. And thanks to >>> delegating to the ComponentPeer, the Component.getToolkit() could >>> return the actual toolkit for this component. >>> >>> However, your fix effectively disallows a component to belong to any >>> toolkit other than the default one, because its getToolkit() will >>> never return anything else (unless you extend the component's class >>> and override the method). >>> >>> I really don't know whether this is widely used, but I think this may >>> impact some applications. >>> >>> Also, imagine a window is made to belong to another toolkit somehow, >>> even with your changes. Now, why should its ability to be >>> always-on-top depend on the default toolkit instead of the window's >>> own toolkit? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 09/27/2013 08:49 PM, sergey malenkov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix: >>>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >>>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >>>> >>>> The specification of the Window class waits for CCC approval. This fix >>>> removes the getTookit method from the ComponentPeer class and its >>>> subclasses. >>>> >>>> Thanks, >>>> SAM >>>> >> From alexander.zvegintsev at oracle.com Wed Oct 2 06:59:04 2013 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 02 Oct 2013 17:59:04 +0400 Subject: [8] Review request for 8013563: Memory leak in JFrame on Linux In-Reply-To: <524BF17B.9030903@oracle.com> References: <524AE2CA.30204@oracle.com> <524BF17B.9030903@oracle.com> Message-ID: <524C26A8.8000909@oracle.com> Hi Artem, 1. Oh, sure. 2. In initDeserializedWindow() owner is not set yet, but we can call it from connectOwnedWindow(). The new webrev is available here: http://cr.openjdk.java.net/~serb/alexz/8013563/webrev.01 Thanks, Alexander. On 10/02/2013 02:12 PM, Artem Ananiev wrote: > > Tho short questions: > > 1. Is a new weak reference (victimWindowRef) really required? Can't we > re-use weakThis, which is victim.weakThis? > > 2. When a window is deserialized, does it have an owner? Shouldn't we > call WDR.updateOwner() in initDeserializedWindow()? > > Thanks, > > Artem > > On 10/1/2013 6:57 PM, Alexander Zvegintsev wrote: >> Hello, >> >> please review a fix for following issue: >> https://bugs.openjdk.java.net/browse/JDK-8013563 >> webrev: >> http://cr.openjdk.java.net/~serb/alexz/8013563/webrev.00/ >> >> This issue is a regression of 6758673 changes in java.awt.Window, where >> call to Disposer.addRecord >> was moved from init(gc) to ownedInit(). But we have constructors without >> a ownedInit() call, hence >> we never call removeFromWindowList() for Frame. >> From artem.ananiev at oracle.com Wed Oct 2 07:21:05 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 Oct 2013 18:21:05 +0400 Subject: [8] Review request for 8013563: Memory leak in JFrame on Linux In-Reply-To: <524C26A8.8000909@oracle.com> References: <524AE2CA.30204@oracle.com> <524BF17B.9030903@oracle.com> <524C26A8.8000909@oracle.com> Message-ID: <524C2BD1.4000905@oracle.com> This version looks fine. Thanks, Artem On 10/2/2013 5:59 PM, Alexander Zvegintsev wrote: > Hi Artem, > > 1. Oh, sure. > 2. In initDeserializedWindow() owner is not set yet, but we can call it > from connectOwnedWindow(). > > The new webrev is available here: > http://cr.openjdk.java.net/~serb/alexz/8013563/webrev.01 > > Thanks, > > Alexander. > > On 10/02/2013 02:12 PM, Artem Ananiev wrote: >> >> Tho short questions: >> >> 1. Is a new weak reference (victimWindowRef) really required? Can't we >> re-use weakThis, which is victim.weakThis? >> >> 2. When a window is deserialized, does it have an owner? Shouldn't we >> call WDR.updateOwner() in initDeserializedWindow()? >> >> Thanks, >> >> Artem >> >> On 10/1/2013 6:57 PM, Alexander Zvegintsev wrote: >>> Hello, >>> >>> please review a fix for following issue: >>> https://bugs.openjdk.java.net/browse/JDK-8013563 >>> webrev: >>> http://cr.openjdk.java.net/~serb/alexz/8013563/webrev.00/ >>> >>> This issue is a regression of 6758673 changes in java.awt.Window, where >>> call to Disposer.addRecord >>> was moved from init(gc) to ownedInit(). But we have constructors without >>> a ownedInit() call, hence >>> we never call removeFromWindowList() for Frame. >>> > From artem.ananiev at oracle.com Wed Oct 2 07:22:12 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 Oct 2013 18:22:12 +0400 Subject: [8] Review Request: JDK-8025585 Win: Popups in JFXPanel do not receive MouseWheel events In-Reply-To: References: <5CBB81CC-BC3C-41A9-89C5-C1952582477A@oracle.com> <524B0395.7060803@oracle.com> <524B0C3B.8080702@oracle.com> Message-ID: <524C2C14.70009@oracle.com> It looks fine now. Please, let Anthony also confirm this. Thanks, Artem On 10/2/2013 5:33 PM, Petr Pchelko wrote: > Hello, Thank you for the review. > >> It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't. > That was indeed an issue. I've got used to Mac behaviour and did not notice the problem. > > The new version of the fix is available here: > http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/ > > Now we redispatch the wheel event only if the window is in the same process. > > With best regards. Petr. > > On Oct 1, 2013, at 9:54 PM, Artem Ananiev wrote: > >> >> On 10/1/2013 9:17 PM, Anthony Petrov wrote: >>> Hi Petr, >>> >>> MS Windows always sends WHEEL events to the focused window. And my >>> testing shows that when you scroll the wheel outside of an AWT window, >>> the scroll events are consumed (by AWT, supposedly). >>> >>> With your fix you seem to always redirect the events to the window under >>> the mouse. Now suppose you have a 3rd-party window with a scroll bar in >>> background (e.g. Windows Explorer). If an AWT window is currently >>> focused, but you move the mouse pointer outside of it and above the >>> Explorer window, and start scrolling, will the Explorer window scroll >>> its contents? Currently it doesn't. What about if we apply your fix? >> >> It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't. >> >> Thanks, >> >> Artem >> >>> -- >>> best regards, >>> Anthony >>> >>> On 09/27/2013 07:24 PM, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8025585 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/ >>>> >>>> The fix is needed for JFXPanel support. We need to redispatch >>>> MOUSEWHEEL messages to the window under mouse. In case of Popups in a >>>> JFXPanel the HWND belongs to a different tollkit, so we need to use >>>> ::SendMessage to redispatch the message. >>>> >>>> With best regards. Petr. >>>> > From leonid.romanov at oracle.com Wed Oct 2 07:22:26 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 2 Oct 2013 18:22:26 +0400 Subject: [8] Review request for 8019623: Lack of synchronization in AppContext.getAppContext() Message-ID: Hello, Please, review a fix for 8019623: Lack of synchronization in AppContext.getAppContext(). I don't think it makes sense to ensure that AppContext.getAppContext()/SunToolkit.createNewAppContext() is thread safe, because in practice we haven't had any problems with this combination. What we have had problems with is the getAppContext()/getAppContext() combination because of the double mainAppContext initialization. Therefore, the fix takes care of this issue. While I could have simply made the whole AppContext.getAppContext() method synchronized, I wanted the most common path through it (returning cached AppContext) to remain lock-free, so I decided to place the lock around the most critical part, where initMainAppContext() gets called. As for a regression test, I couldn't find a way to detect double initMainAppContext initialization. We put newly created AppContexts into a thread-safe map, so whatever AppContext wins the race remains in the map, and the other is simply lost, without any convenient means to detect its existence. Bug: https://bugs.openjdk.java.net/browse/JDK-8019623 Webrev: http://cr.openjdk.java.net/~leonidr/8019623/webrev.00/ Thanks, Leonid. From anthony.petrov at oracle.com Wed Oct 2 09:28:55 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 Oct 2013 20:28:55 +0400 Subject: [8] Review request for 8013563: Memory leak in JFrame on Linux In-Reply-To: <524C2BD1.4000905@oracle.com> References: <524AE2CA.30204@oracle.com> <524BF17B.9030903@oracle.com> <524C26A8.8000909@oracle.com> <524C2BD1.4000905@oracle.com> Message-ID: <524C49C7.2030404@oracle.com> +1 -- best regards, Anthony On 10/02/2013 06:21 PM, Artem Ananiev wrote: > > This version looks fine. > > Thanks, > > Artem > > On 10/2/2013 5:59 PM, Alexander Zvegintsev wrote: >> Hi Artem, >> >> 1. Oh, sure. >> 2. In initDeserializedWindow() owner is not set yet, but we can call it >> from connectOwnedWindow(). >> >> The new webrev is available here: >> http://cr.openjdk.java.net/~serb/alexz/8013563/webrev.01 >> >> Thanks, >> >> Alexander. >> >> On 10/02/2013 02:12 PM, Artem Ananiev wrote: >>> >>> Tho short questions: >>> >>> 1. Is a new weak reference (victimWindowRef) really required? Can't we >>> re-use weakThis, which is victim.weakThis? >>> >>> 2. When a window is deserialized, does it have an owner? Shouldn't we >>> call WDR.updateOwner() in initDeserializedWindow()? >>> >>> Thanks, >>> >>> Artem >>> >>> On 10/1/2013 6:57 PM, Alexander Zvegintsev wrote: >>>> Hello, >>>> >>>> please review a fix for following issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8013563 >>>> webrev: >>>> http://cr.openjdk.java.net/~serb/alexz/8013563/webrev.00/ >>>> >>>> This issue is a regression of 6758673 changes in java.awt.Window, where >>>> call to Disposer.addRecord >>>> was moved from init(gc) to ownedInit(). But we have constructors >>>> without >>>> a ownedInit() call, hence >>>> we never call removeFromWindowList() for Frame. >>>> >> From anthony.petrov at oracle.com Wed Oct 2 09:41:33 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 Oct 2013 20:41:33 +0400 Subject: [8] Review Request: JDK-8025585 Win: Popups in JFXPanel do not receive MouseWheel events In-Reply-To: References: <5CBB81CC-BC3C-41A9-89C5-C1952582477A@oracle.com> <524B0395.7060803@oracle.com> <524B0C3B.8080702@oracle.com> Message-ID: <524C4CBD.8060908@oracle.com> Hi Petr, The new version looks better. However, there's still one minor issue: > 1528 return ::SendMessage(hWndForWheel, msg.message, mouseWParam, mouseLParam); The PreProcessMouseMsg() function to which this line belongs should return a boolean value indicating whether the event must be processed (FALSE) or silently consumed (TRUE). The ::SendMessage() returns the result of calling a WndProc() for the target window when it processes the message, which we really don't care about here. And regardless of the result, I don't think that AWT should process the message any further after it's been redirected to the target toolkit. So I think we should ignore the SendMessage's return value and always return TRUE here because the message has already been processed by the target toolkit. What do you think? -- best regards, Anthony On 10/02/2013 05:33 PM, Petr Pchelko wrote: > Hello, Thank you for the review. > >> It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't. > That was indeed an issue. I've got used to Mac behaviour and did not notice the problem. > > The new version of the fix is available here: > http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/ > > Now we redispatch the wheel event only if the window is in the same process. > > With best regards. Petr. > > On Oct 1, 2013, at 9:54 PM, Artem Ananiev wrote: > >> >> On 10/1/2013 9:17 PM, Anthony Petrov wrote: >>> Hi Petr, >>> >>> MS Windows always sends WHEEL events to the focused window. And my >>> testing shows that when you scroll the wheel outside of an AWT window, >>> the scroll events are consumed (by AWT, supposedly). >>> >>> With your fix you seem to always redirect the events to the window under >>> the mouse. Now suppose you have a 3rd-party window with a scroll bar in >>> background (e.g. Windows Explorer). If an AWT window is currently >>> focused, but you move the mouse pointer outside of it and above the >>> Explorer window, and start scrolling, will the Explorer window scroll >>> its contents? Currently it doesn't. What about if we apply your fix? >> >> It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't. >> >> Thanks, >> >> Artem >> >>> -- >>> best regards, >>> Anthony >>> >>> On 09/27/2013 07:24 PM, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8025585 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/ >>>> >>>> The fix is needed for JFXPanel support. We need to redispatch >>>> MOUSEWHEEL messages to the window under mouse. In case of Popups in a >>>> JFXPanel the HWND belongs to a different tollkit, so we need to use >>>> ::SendMessage to redispatch the message. >>>> >>>> With best regards. Petr. >>>> > From sergey.bylokhov at oracle.com Wed Oct 2 10:03:40 2013 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Wed, 02 Oct 2013 17:03:40 +0000 Subject: hg: jdk8/awt/jdk: 8013563: Memory leak in JFrame on Linux Message-ID: <20131002170406.2B45762CAC@hg.openjdk.java.net> Changeset: f40f2421c60f Author: serb Date: 2013-10-02 21:02 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f40f2421c60f 8013563: Memory leak in JFrame on Linux Reviewed-by: anthony, art ! src/share/classes/java/awt/Window.java + test/java/awt/Window/WindowsLeak/WindowsLeak.java From anthony.petrov at oracle.com Wed Oct 2 10:11:47 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 Oct 2013 21:11:47 +0400 Subject: [8] Review request for 8019623: Lack of synchronization in AppContext.getAppContext() In-Reply-To: References: Message-ID: <524C53D3.6090701@oracle.com> Hi Leonid, The fix looks good to me. Just one comment: should we use a StringBuilder with some meaningful text instead of a plane Object for the lock? Even better if that were a named (inner) class. All for logging purposes when dumping a stack trace. What's your opinion? -- best regards, Anthony On 10/02/2013 06:22 PM, Leonid Romanov wrote: > Hello, > Please, review a fix for 8019623: Lack of synchronization in AppContext.getAppContext(). I don't think it makes sense to ensure that AppContext.getAppContext()/SunToolkit.createNewAppContext() is thread safe, because in practice we haven't had any problems with this combination. What we have had problems with is the getAppContext()/getAppContext() combination because of the double mainAppContext initialization. Therefore, the fix takes care of this issue. While I could have simply made the whole AppContext.getAppContext() method synchronized, I wanted the most common path through it (returning cached AppContext) to remain lock-free, so I decided to place the lock around the most critical part, where initMainAppContext() gets called. > As for a regression test, I couldn't find a way to detect double initMainAppContext initialization. We put newly created AppContexts into a thread-safe map, so whatever AppContext wins the race remains in the map, and the other is simply lost, without any convenient means to detect its existence. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8019623 > Webrev: http://cr.openjdk.java.net/~leonidr/8019623/webrev.00/ > > Thanks, > Leonid. > From christine.lu at oracle.com Wed Oct 2 11:28:46 2013 From: christine.lu at oracle.com (christine.lu at oracle.com) Date: Wed, 02 Oct 2013 18:28:46 +0000 Subject: hg: jdk8/awt/jdk: 8025409: Fix javadoc comments errors and warning reported by doclint report Message-ID: <20131002182910.8D1C362CB2@hg.openjdk.java.net> Changeset: 1da5d306e84b Author: cl Date: 2013-10-02 11:28 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1da5d306e84b 8025409: Fix javadoc comments errors and warning reported by doclint report Reviewed-by: anthony, yan ! src/share/classes/java/awt/BorderLayout.java ! src/share/classes/java/awt/Button.java ! src/share/classes/java/awt/Checkbox.java ! src/share/classes/java/awt/CheckboxGroup.java ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Color.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/FlowLayout.java ! src/share/classes/java/awt/FontMetrics.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/GridLayout.java ! src/share/classes/java/awt/Label.java ! src/share/classes/java/awt/LinearGradientPaint.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/RadialGradientPaint.java ! src/share/classes/java/awt/Scrollbar.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/font/TextAttribute.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/awt/print/PrinterJob.java ! src/share/classes/javax/print/Doc.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/MultiDoc.java ! src/share/classes/javax/print/attribute/standard/Finishings.java ! src/share/classes/javax/print/attribute/standard/JobStateReasons.java ! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java ! src/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/Sides.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/LookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java From Sergey.Bylokhov at oracle.com Wed Oct 2 11:38:39 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 02 Oct 2013 22:38:39 +0400 Subject: [8] Request for review: 8025603 Unused methods in the awt text peers should be removed Message-ID: <524C682F.3060006@oracle.com> Hello, Please review the fix for jdk 8. This is a code cleanup. Bug: https://bugs.openjdk.java.net/browse/JDK-8025603 Webrev can be found at: http://cr.openjdk.java.net/~serb/8025603/webrev.00 -- Best regards, Sergey. From oleg.pekhovskiy at oracle.com Wed Oct 2 13:18:56 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 03 Oct 2013 00:18:56 +0400 Subject: [8] Review request for 8000425: FileDialog documentation should be enhanced In-Reply-To: <5242D33F.1020001@oracle.com> References: <5242BFEB.50705@oracle.com> <5242D33F.1020001@oracle.com> Message-ID: <524C7FB0.2030101@oracle.com> Hi Anthony, thank you for the review... Please, review the second version of fix here: http://cr.openjdk.java.net/~bagiras/8000425.2/ and my comments below... Thanks, Oleg On 25.09.2013 16:12, Anthony Petrov wrote: > Hi Oleg, > > I suggest to rephrase the statements as follows: > >> 460 * The file could be highlighted or its name could be entered >> depending on >> 461 * native file dialog implementation. > > "When the dialog is shown, the specified file is selected. The kind of > selection depends on the dialog type and the native platform. For > example, the file could be highlighted in the file list, or a file name > editbox could be populated with a string containing the specified file > name." I borrowed your modification, plus mentioned 'file existence' as one of the dependencies. > >> 463 * This method accepts full path or file name with extension >> when used >> 464 * together with setDirectory() method. > > "This method accepts either a full file path, or a file name with an > extension if used together with the {@code setDirectory} method." > >> 467 * null as the file. > > {@code null} Borrowed too. > > > Please get a CCC approval before pushing this fix. > > -- > best regards, > Anthony > > On 09/25/2013 02:50 PM, Oleg Pekhovskiy wrote: >> Hi all, >> >> please review the fix >> http://cr.openjdk.java.net/~bagiras/8000425.1/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8000425 >> >> It's just a Javadoc fix. >> >> Thanks, >> Oleg From anthony.petrov at oracle.com Wed Oct 2 13:25:50 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 03 Oct 2013 00:25:50 +0400 Subject: [8] Review request for 8000425: FileDialog documentation should be enhanced In-Reply-To: <524C7FB0.2030101@oracle.com> References: <5242BFEB.50705@oracle.com> <5242D33F.1020001@oracle.com> <524C7FB0.2030101@oracle.com> Message-ID: <524C814E.4030400@oracle.com> The updated fix looks fine to me. Thanks! -- best regards, Anthony On 10/03/2013 12:18 AM, Oleg Pekhovskiy wrote: > Hi Anthony, > > thank you for the review... > > Please, review the second version of fix here: > http://cr.openjdk.java.net/~bagiras/8000425.2/ > > and my comments below... > > Thanks, > Oleg > > On 25.09.2013 16:12, Anthony Petrov wrote: >> Hi Oleg, >> >> I suggest to rephrase the statements as follows: >> >>> 460 * The file could be highlighted or its name could be entered >>> depending on >>> 461 * native file dialog implementation. >> >> "When the dialog is shown, the specified file is selected. The kind of >> selection depends on the dialog type and the native platform. For >> example, the file could be highlighted in the file list, or a file name >> editbox could be populated with a string containing the specified file >> name." > I borrowed your modification, plus mentioned 'file existence' as one of > the dependencies. >> >>> 463 * This method accepts full path or file name with extension >>> when used >>> 464 * together with setDirectory() method. >> >> "This method accepts either a full file path, or a file name with an >> extension if used together with the {@code setDirectory} method." >> >>> 467 * null as the file. >> >> {@code null} > Borrowed too. > >> >> >> Please get a CCC approval before pushing this fix. >> >> -- >> best regards, >> Anthony >> >> On 09/25/2013 02:50 PM, Oleg Pekhovskiy wrote: >>> Hi all, >>> >>> please review the fix >>> http://cr.openjdk.java.net/~bagiras/8000425.1/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8000425 >>> >>> It's just a Javadoc fix. >>> >>> Thanks, >>> Oleg From james.graham at oracle.com Wed Oct 2 15:13:59 2013 From: james.graham at oracle.com (Jim Graham) Date: Wed, 02 Oct 2013 15:13:59 -0700 Subject: [OpenJDK 2D-Dev] [8] Review request for JDK-8025684 - Fix Raw and unchecked warnings java.awt.image classes In-Reply-To: <524BEF41.2000304@oracle.com> References: <524B43EF.4080603@oracle.com> <524BEF41.2000304@oracle.com> Message-ID: <524C9AA7.6010500@oracle.com> I'm not the greatest expert on generics (in particular, in terms of issues of retrofitting generics into existing public code without breaking compatibility), but I'll note that the properties on an image were always "documented" to be String->Object, but that was well before generics and so we just accepted bare hash tables everywhere. Is it possible to have at least some of the declarations of various properties objects to be declared as even though we are loose on the acceptance criteria in various constructors - or would that just completely break compatibility. I know that we use type erasure so we would never break binary compatibility, but there may be some places where we can have them more strongly typed internally for now, but more accepting at the external API level and then possibly consider improving the externally-visible typing in future versions when a source incompatibility is more appropriate? (I'm asking because I don't understand all of the compatibility issues that this might cause...) ...jim On 10/2/13 3:02 AM, Artem Ananiev wrote: > > java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to > CC. Please, wait for at least one approval from Java2D team. > > For easier review, I put the webrev here: > > http://cr.openjdk.java.net/~art/srikalyc/8025684.00/ > > It looks fine to me. There is one "unchecked" warning still left, at > BufferedImage.java:645, it can be fixed by introducing a local variable > and @SuppressWarnings("unchecked"), but I'm not sure it's worth doing. > > Thanks, > > Artem > > On 10/2/2013 1:51 AM, srikalyan chandrashekar wrote: >> Hi team , could someone review the fix >> Bug : https://bugs.openjdk.java.net/browse/JDK-8025684 >> Webrev : >> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.image.raw_unchecked_webrev.zip >> >> >> Fix : Raw and unchecked warnings in AWT image classes fixed >> From oleg.pekhovskiy at oracle.com Thu Oct 3 00:30:15 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 03 Oct 2013 11:30:15 +0400 Subject: [8] Review request for 7068423: Spec for java.awt.GraphicsDevice.getFullScreenWindow() needs clarification In-Reply-To: <524B15C0.1040402@oracle.com> References: <524AC214.3000806@oracle.com> <524B15C0.1040402@oracle.com> Message-ID: <524D1D07.3090408@oracle.com> Hi All, please review the second version of fix: http://cr.openjdk.java.net/~bagiras/7068423.2/ Reason: Discussed with Artem and Andrew, came to conclusion that there were situations when returned object could be also set by the system, and not by the client application through setFullScreenWindow(). Thanks, Oleg On 01.10.2013 22:34, Anthony Petrov wrote: > Looks fine. > > -- > best regards, > Anthony > > On 10/01/2013 04:37 PM, Oleg Pekhovskiy wrote: >> Hi all, >> >> please review the fix >> http://cr.openjdk.java.net/~bagiras/7068423.1/ >> for >> https://bugs.openjdk.java.net/browse/JDK-7068423 >> >> It's just a Javadoc fix. >> >> Thanks, >> Oleg From oleg.pekhovskiy at oracle.com Thu Oct 3 02:07:17 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 03 Oct 2013 13:07:17 +0400 Subject: [8] Review request for 8013553: [macosx] java.awt.FileDialog removes file extensions Message-ID: <524D33C5.9020101@oracle.com> Hi all, please review the fix http://cr.openjdk.java.net/~bagiras/8013553.1/ for https://bugs.openjdk.java.net/browse/JDK-8013553 setExtensionHidden(NO) method of NSSavePanel doesn't work as expected and that's a known issue mentioned on several forums. But there is another solution based on Application system settings that allows to control showing of extension for file dialog. Thanks, Oleg From mikhail.cherkasov at oracle.com Thu Oct 3 03:33:44 2013 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 03 Oct 2013 14:33:44 +0400 Subject: [8] Review request for 8020688: broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. In-Reply-To: <524B12B6.3060803@oracle.com> References: <52433994.1090403@oracle.com> <5243635C.7070007@oracle.com> <52454506.8090500@oracle.com> <52457F15.7090501@oracle.com> <52459263.7040704@oracle.com> <524593EB.2010600@oracle.com> <524596A8.2040700@oracle.com> <5245A508.4040707@oracle.com> <524B12B6.3060803@oracle.com> Message-ID: <524D4808.2060901@oracle.com> Hi Anthony, Alexandr, Do you approve the latest version? Thanks, Mikhail. On 01.10.2013 22:21, Anthony Petrov wrote: > Hi Mikhail, > > This "Advanced JList Programming" article seems to vanish, indeed. > Although there's a copy at: > > http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/tech_topics/jlist_1/jlist.html > > > but generally we shouldn't refer to 3rd-party web-sites from our > specification. I briefly looked into the copy, and I think that > referring to the Swing tutorial should be just fine as a replacement > for this article. > > -- > best regards, > Anthony > > On 09/27/2013 07:32 PM, mikhail cherkasov wrote: >> Anthony thank you for this link, it's good replacement for removed link. >> >> Also I didn't find replacement for : >> - * Also see the article > href="http://java.sun.com/products/jfc/tsc/tech_topics/jlist_1/jlist.html">Advanced >> >> JList Programming >> - * in The Swing >> Connection. >> >> Do you have any suggestion about this link? the link to swing tutorial >> already are there: >> http://docs.oracle.com/javase/tutorial/uiswing/components/list.html >> >> Thanks, >> Mikhail. >> >> On 27.09.2013 18:31, Anthony Petrov wrote: >>> On 09/27/2013 06:19 PM, mikhail cherkasov wrote: >>>> Anthony, some links, like this one, we lost for ever. >>> >>> How about >>> http://docs.oracle.com/javase/tutorial/uiswing/events/actionlistener.html >>> >>> ? >>> >>> >>>> On 27.09.2013 18:12, Anthony Petrov wrote: >>>>> Thanks. I skimmed through the changes and they look good generally. A >>>>> couple of nits: >>>>> >>>>> src/share/classes/java/awt/event/ActionListener.java >>>>>> - * @see >>>>> href="http://java.sun.com/docs/books/tutorial/post1.0/ui/eventmodel.html">Tutorial: >>>>>> >>>>>> >>>>>> Java 1.1 Event Model >>>>> >>>>> You're only removing the link here. You should add a new one, too, I >>>>> guess. >>>>> >>>>> >>>>> src/share/classes/sun/text/normalizer/UCharacter.java >>>>>> - * >>>>> href="http://java.sun.com/j2se/1.5/docs/api/java/lang/Character.html"> >>>>>> >>>>>> + * >>>>> href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Character.html"> >>>>>> >>>>>> >>>>>> >>>>>> * java.lang.Character class. These extensions provide support >>>>>> for >>>>> >>>>> I believe the here should be replaced with a usual javadoc's >>>>> {@link ...} kind of thing. >>>> Agree, and this should be done in all places, but this will be too >>>> much >>>> changes for this fix. >>> >>> Certainly, we shouldn't change all and every occurrence of this. >>> However, this line is updated in your fix anyway, so why not apply the >>> correct pattern just for this particular case now? >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 09/27/2013 04:50 PM, mikhail cherkasov wrote: >>>>>> Hi Anthony, >>>>>> >>>>>> Please review a new version: >>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.02/ >>>>>> >>>>>> I rely on http redirect, but it doesn't always work correctly. Now I >>>>>> re-checked all links. >>>>>> >>>>>> Thanks, >>>>>> Mikhail. >>>>>> >>>>>> On 27.09.2013 12:42, Anthony Petrov wrote: >>>>>>> Hi Mikhail, >>>>>>> >>>>>>> Please comment on the following: >>>>>>> >>>>>>> src/share/classes/java/awt/Component.java: >>>>>>>> - * >>>>>>> href="http://java.sun.com/products/jfc/tsc/articles/painting/index.html">Painting >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> in AWT and Swing. >>>>>>>> + * >>>>>>> href="http://www.oracle.com/technetwork/java/index.html">Painting >>>>>>>> in >>>>>>>> AWT and Swing. >>>>>>> >>>>>>> The new link doesn't point to the "Painting..." article (and it >>>>>>> is a >>>>>>> very good article, btw). Could you please check all the new >>>>>>> links and >>>>>>> update the webrev? >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 09/26/2013 02:27 AM, mikhail cherkasov wrote: >>>>>>>> a new webrev: >>>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.01/ >>>>>>>> >>>>>>>> no changes, I've turned off laptop before the webrev upload was >>>>>>>> complete, so >>>>>>>> the first could be corrupted. >>>>>>>> >>>>>>>> On 25.09.2013 23:29, mikhail cherkasov wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Could you please review the fix for the following bug: >>>>>>>>> 8020688: broken links in documentation at >>>>>>>>> http://docs.oracle.com/javase/6/docs/api/index. >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020688 >>>>>>>>> The webrev: >>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Mikhail. >>>>>>>> >>>>>> >>>> >> From leonid.romanov at oracle.com Thu Oct 3 04:08:33 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 3 Oct 2013 15:08:33 +0400 Subject: [8] Review request for 8013553: [macosx] java.awt.FileDialog removes file extensions In-Reply-To: <524D33C5.9020101@oracle.com> References: <524D33C5.9020101@oracle.com> Message-ID: Looks good to me. On 03.10.2013, at 13:07, Oleg Pekhovskiy wrote: > Hi all, > > please review the fix > http://cr.openjdk.java.net/~bagiras/8013553.1/ > for > https://bugs.openjdk.java.net/browse/JDK-8013553 > > setExtensionHidden(NO) method of NSSavePanel doesn't work as expected and that's a known issue mentioned on several forums. > But there is another solution based on Application system settings that allows to control showing of extension for file dialog. > > Thanks, > Oleg From Sergey.Bylokhov at oracle.com Thu Oct 3 04:19:22 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 03 Oct 2013 15:19:22 +0400 Subject: [8] Review request for 8013553: [macosx] java.awt.FileDialog removes file extensions In-Reply-To: References: <524D33C5.9020101@oracle.com> Message-ID: <524D52BA.5020204@oracle.com> Hi, Oleg. Can you split the line and add the comment that setExtensionHidden is not applicable here. On 03.10.2013 15:08, Leonid Romanov wrote: > Looks good to me. > > On 03.10.2013, at 13:07, Oleg Pekhovskiy wrote: > >> Hi all, >> >> please review the fix >> http://cr.openjdk.java.net/~bagiras/8013553.1/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8013553 >> >> setExtensionHidden(NO) method of NSSavePanel doesn't work as expected and that's a known issue mentioned on several forums. >> But there is another solution based on Application system settings that allows to control showing of extension for file dialog. >> >> Thanks, >> Oleg -- Best regards, Sergey. From alexander.potochkin at oracle.com Thu Oct 3 05:19:24 2013 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Thu, 03 Oct 2013 16:19:24 +0400 Subject: [7] Review request for backport of 8023310: Thread contention in the method Beans.IsDesignTime() In-Reply-To: <524C0A51.7070809@oracle.com> References: <524BC92B.5070500@oracle.com> <524BF628.8090208@oracle.com> <524C0A51.7070809@oracle.com> Message-ID: <524D60CC.6020509@oracle.com> Hello Mikhail Also looks good for me Thanks alexp On 10/2/2013 3:58 PM, mikhail cherkasov wrote: > Hi Sergey, > > here is results of benchmark: > with fix: Result : 103130,558 ?(95%) 381,949 ?(99%) 522,101 ops/ms > without fix: Result : 15276,871 ?(95%) 12,841 ?(99%) 17,553 ops/ms > > What did you change the subject? as I can see you use the same subject > in your commit: > 8023310: Thread contention in the method Beans.IsDesignTime() > http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a284da808700 > > Thanks, > Mikhail. > > On 02.10.2013 14:32, sergey malenkov wrote: >> I changed the subject, which is incorrect. The backport looks good. >> Do you have a build for Windows to test a performance? >> >> Thanks, >> SAM >> >> On 02.10.2013 11:20, mikhail cherkasov wrote: >>> Hello all, >>> >>> Please review a backport for the following bug: >>> https://bugs.openjdk.java.net/browse/JDK-8023310 >>> webrev: >>> http://cr.openjdk.java.net/~mcherkas/8023310/webrev.00/ >>> >>> >>> Thanks, >>> Mikhail. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131003/e7a21239/attachment.html From oleg.pekhovskiy at oracle.com Thu Oct 3 05:32:25 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 03 Oct 2013 16:32:25 +0400 Subject: [8] Review request for 8013553: [macosx] java.awt.FileDialog removes file extensions In-Reply-To: References: <524D33C5.9020101@oracle.com> Message-ID: <524D63D9.3060306@oracle.com> Thank you, Leonid! Oleg. On 03.10.2013 15:08, Leonid Romanov wrote: > Looks good to me. > > On 03.10.2013, at 13:07, Oleg Pekhovskiy wrote: > >> Hi all, >> >> please review the fix >> http://cr.openjdk.java.net/~bagiras/8013553.1/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8013553 >> >> setExtensionHidden(NO) method of NSSavePanel doesn't work as expected and that's a known issue mentioned on several forums. >> But there is another solution based on Application system settings that allows to control showing of extension for file dialog. >> >> Thanks, >> Oleg > From oleg.pekhovskiy at oracle.com Thu Oct 3 05:35:09 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 03 Oct 2013 16:35:09 +0400 Subject: [8] Review request for 8013553: [macosx] java.awt.FileDialog removes file extensions In-Reply-To: <524D52BA.5020204@oracle.com> References: <524D33C5.9020101@oracle.com> <524D52BA.5020204@oracle.com> Message-ID: <524D647D.1060101@oracle.com> Hi Sergey, thank you for the review, please review the second version of fix: http://cr.openjdk.java.net/~bagiras/8013553.2/ I split the line and added more comments. Oleg. On 03.10.2013 15:19, Sergey Bylokhov wrote: > Hi, Oleg. > Can you split the line and add the comment that setExtensionHidden is > not applicable here. > > On 03.10.2013 15:08, Leonid Romanov wrote: >> Looks good to me. >> >> On 03.10.2013, at 13:07, Oleg Pekhovskiy >> wrote: >> >>> Hi all, >>> >>> please review the fix >>> http://cr.openjdk.java.net/~bagiras/8013553.1/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8013553 >>> >>> setExtensionHidden(NO) method of NSSavePanel doesn't work as expected >>> and that's a known issue mentioned on several forums. >>> But there is another solution based on Application system settings >>> that allows to control showing of extension for file dialog. >>> >>> Thanks, >>> Oleg > > From Sergey.Bylokhov at oracle.com Thu Oct 3 05:36:43 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 03 Oct 2013 16:36:43 +0400 Subject: [8] Review request for 8013553: [macosx] java.awt.FileDialog removes file extensions In-Reply-To: <524D647D.1060101@oracle.com> References: <524D33C5.9020101@oracle.com> <524D52BA.5020204@oracle.com> <524D647D.1060101@oracle.com> Message-ID: <524D64DB.3020008@oracle.com> Hi, Oleg. The fix looks good. On 03.10.2013 16:35, Oleg Pekhovskiy wrote: > Hi Sergey, thank you for the review, > > please review the second version of fix: > http://cr.openjdk.java.net/~bagiras/8013553.2/ > > I split the line and added more comments. > > Oleg. > > On 03.10.2013 15:19, Sergey Bylokhov wrote: >> Hi, Oleg. >> Can you split the line and add the comment that setExtensionHidden is >> not applicable here. >> >> On 03.10.2013 15:08, Leonid Romanov wrote: >>> Looks good to me. >>> >>> On 03.10.2013, at 13:07, Oleg Pekhovskiy >>> wrote: >>> >>>> Hi all, >>>> >>>> please review the fix >>>> http://cr.openjdk.java.net/~bagiras/8013553.1/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8013553 >>>> >>>> setExtensionHidden(NO) method of NSSavePanel doesn't work as expected >>>> and that's a known issue mentioned on several forums. >>>> But there is another solution based on Application system settings >>>> that allows to control showing of extension for file dialog. >>>> >>>> Thanks, >>>> Oleg >> >> -- Best regards, Sergey. From oleg.pekhovskiy at oracle.com Thu Oct 3 05:44:24 2013 From: oleg.pekhovskiy at oracle.com (oleg.pekhovskiy at oracle.com) Date: Thu, 03 Oct 2013 12:44:24 +0000 Subject: hg: jdk8/awt/jdk: 8013553: [macosx] java.awt.FileDialog removes file extensions Message-ID: <20131003124514.3CF0862CEA@hg.openjdk.java.net> Changeset: 998578a87c0e Author: bagiras Date: 2013-10-03 16:51 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/998578a87c0e 8013553: [macosx] java.awt.FileDialog removes file extensions Reviewed-by: leonidr, serb ! src/macosx/native/sun/awt/CFileDialog.m From alexandr.scherbatiy at oracle.com Thu Oct 3 06:03:58 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 03 Oct 2013 17:03:58 +0400 Subject: [8] Review request for 7081594 Windows owned by an always-on-top window DO NOT automatically become always-on-top Message-ID: <524D6B3E.7030401@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-7081594 webrev: http://cr.openjdk.java.net/~alexsch/7081594/webrev.00 The fix: - sets alwaysOnTop field for a new created window from the parent value - propagates the alwaysOnTop value in setAlwaysOnTop() method to the owned windows Thanks, Alexandr. From artem.ananiev at oracle.com Thu Oct 3 06:17:21 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 03 Oct 2013 17:17:21 +0400 Subject: [8] Review request for 7068423: Spec for java.awt.GraphicsDevice.getFullScreenWindow() needs clarification In-Reply-To: <524D1D07.3090408@oracle.com> References: <524AC214.3000806@oracle.com> <524B15C0.1040402@oracle.com> <524D1D07.3090408@oracle.com> Message-ID: <524D6E61.80207@oracle.com> On 10/3/2013 11:30 AM, Oleg Pekhovskiy wrote: > Hi All, > > please review the second version of fix: > http://cr.openjdk.java.net/~bagiras/7068423.2/ It looks fine to me. Thanks, Artem > Reason: > Discussed with Artem and Andrew, came to conclusion that there were > situations when returned object could be also set by the system, and not > by the client application through setFullScreenWindow(). > > Thanks, > Oleg > > On 01.10.2013 22:34, Anthony Petrov wrote: >> Looks fine. >> >> -- >> best regards, >> Anthony >> >> On 10/01/2013 04:37 PM, Oleg Pekhovskiy wrote: >>> Hi all, >>> >>> please review the fix >>> http://cr.openjdk.java.net/~bagiras/7068423.1/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-7068423 >>> >>> It's just a Javadoc fix. >>> >>> Thanks, >>> Oleg From Sergey.Bylokhov at oracle.com Thu Oct 3 06:27:33 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 03 Oct 2013 17:27:33 +0400 Subject: [8] Review request for 7174704: [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure In-Reply-To: <524BF6B6.9020306@oracle.com> References: <524BF6B6.9020306@oracle.com> Message-ID: <524D70C5.1090309@oracle.com> Hi, Anthony. The fix looks good. On 02.10.2013 14:34, Anthony Petrov wrote: > Hello, > > Please review a long-awaited back-port of a fix for > https://bugs.openjdk.java.net/browse/JDK-7174704 at: > > http://cr.openjdk.java.net/~anthony/8-61-headlessPrinting-7174704.0/ > > It is not a direct back-port because the code in JDK8 slightly differs > from 7u, but the basic idea is the same: we always load the lwawt > dynamic library on Mac, regardless of the headless/headful mode. > > Also with this fix I remove support for the undocumented AWT_TOOLKIT > environment variable. It's become obsolete with removal of the > MToolkit from JDK7. For selecting custom toolkits users still can use > the documented -Dawt.toolkit= system property. > > I've tested the fix with a test mentioned in the bug report, and it > passes well. > > -- > best regards, > Anthony -- Best regards, Sergey. From artem.ananiev at oracle.com Thu Oct 3 06:36:21 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 03 Oct 2013 17:36:21 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524C20DC.70507@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> <524C0411.7060709@oracle.com> <524C11A9.3000307@oracle.com> <524C20DC.70507@oracle.com> Message-ID: <524D72D5.9010409@oracle.com> Looks fine. Thanks, Artem On 10/2/2013 5:34 PM, sergey malenkov wrote: > http://cr.openjdk.java.net/~malenkov/7081584.8.1/ > > The specification is updated. > > SAM > > On 02.10.2013 16:29, Artem Ananiev wrote: >> >> On 10/2/2013 3:31 PM, sergey malenkov wrote: >>> This bug is about javadoc. What if I replace "the default toolkit" with >>> "the current window toolkit"? >> >> "The current window toolkit" sounds strange. It should be clarified or >> replaced with "this window's toolkit" + {@see #getToolkit}. >> >> Thanks, >> >> Artem >> >>> As I understand the Peer API is not public. So we can modify it without >>> thinking about backward compatibility. >>> >>> Thanks, >>> SAM >>> >>> On 01.10.2013 21:47, Anthony Petrov wrote: >>>> Hi Sergey, >>>> >>>> I'm wondering what compatibility impact of this change is. The >>>> specification for Component.getToolkit() suggests that in theory >>>> several toolkits may co-exist in a single application. And thanks to >>>> delegating to the ComponentPeer, the Component.getToolkit() could >>>> return the actual toolkit for this component. >>>> >>>> However, your fix effectively disallows a component to belong to any >>>> toolkit other than the default one, because its getToolkit() will >>>> never return anything else (unless you extend the component's class >>>> and override the method). >>>> >>>> I really don't know whether this is widely used, but I think this may >>>> impact some applications. >>>> >>>> Also, imagine a window is made to belong to another toolkit somehow, >>>> even with your changes. Now, why should its ability to be >>>> always-on-top depend on the default toolkit instead of the window's >>>> own toolkit? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 09/27/2013 08:49 PM, sergey malenkov wrote: >>>>> Hello, >>>>> >>>>> Could you please review the following fix: >>>>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >>>>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >>>>> >>>>> The specification of the Window class waits for CCC approval. This fix >>>>> removes the getTookit method from the ComponentPeer class and its >>>>> subclasses. >>>>> >>>>> Thanks, >>>>> SAM >>>>> >>> > From anthony.petrov at oracle.com Thu Oct 3 07:01:53 2013 From: anthony.petrov at oracle.com (anthony.petrov at oracle.com) Date: Thu, 03 Oct 2013 14:01:53 +0000 Subject: hg: jdk8/awt/jdk: 7174704: [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure Message-ID: <20131003140222.039E862CEF@hg.openjdk.java.net> Changeset: 1533a379deb0 Author: anthony Date: 2013-10-03 18:01 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1533a379deb0 7174704: [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure Summary: Load the lwawt native library on Mac regardless of the headless/headful mode. Also, some minor cleanup. Reviewed-by: art, serb ! src/macosx/native/sun/awt/awt.m ! src/solaris/native/sun/awt/awt_LoadLibrary.c From alexandr.scherbatiy at oracle.com Thu Oct 3 08:03:39 2013 From: alexandr.scherbatiy at oracle.com (alexandr.scherbatiy at oracle.com) Date: Thu, 03 Oct 2013 15:03:39 +0000 Subject: hg: jdk8/awt/jdk: 7092283: Property Window.locationByPlatform is not cleared by calling setVisible(false) Message-ID: <20131003150401.42C9B62CF5@hg.openjdk.java.net> Changeset: 39b674405270 Author: alexsch Date: 2013-10-03 19:02 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/39b674405270 7092283: Property Window.locationByPlatform is not cleared by calling setVisible(false) Reviewed-by: anthony, serb ! src/share/classes/java/awt/Window.java + test/java/awt/Window/LocationByPlatform/LocationByPlatformTest.java From anthony.petrov at oracle.com Fri Oct 4 01:13:43 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 Oct 2013 12:13:43 +0400 Subject: [8] Request for review: 8025603 Unused methods in the awt text peers should be removed In-Reply-To: <524C682F.3060006@oracle.com> References: <524C682F.3060006@oracle.com> Message-ID: <524E78B7.5030107@oracle.com> Looks fine. -- best regards, Anthony On 10/02/2013 10:38 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk 8. This is a code cleanup. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8025603 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8025603/webrev.00 > From anthony.petrov at oracle.com Fri Oct 4 01:18:46 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 Oct 2013 12:18:46 +0400 Subject: [8] Review request for 8020688: broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. In-Reply-To: <524D4808.2060901@oracle.com> References: <52433994.1090403@oracle.com> <5243635C.7070007@oracle.com> <52454506.8090500@oracle.com> <52457F15.7090501@oracle.com> <52459263.7040704@oracle.com> <524593EB.2010600@oracle.com> <524596A8.2040700@oracle.com> <5245A508.4040707@oracle.com> <524B12B6.3060803@oracle.com> <524D4808.2060901@oracle.com> Message-ID: <524E79E6.7090701@oracle.com> Hi Mikhail, Yes, the latest version looks good to me. -- best regards, Anthony On 10/03/2013 02:33 PM, mikhail cherkasov wrote: > Hi Anthony, Alexandr, > > Do you approve the latest version? > > Thanks, > Mikhail. > > On 01.10.2013 22:21, Anthony Petrov wrote: >> Hi Mikhail, >> >> This "Advanced JList Programming" article seems to vanish, indeed. >> Although there's a copy at: >> >> http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/tech_topics/jlist_1/jlist.html >> >> >> but generally we shouldn't refer to 3rd-party web-sites from our >> specification. I briefly looked into the copy, and I think that >> referring to the Swing tutorial should be just fine as a replacement >> for this article. >> >> -- >> best regards, >> Anthony >> >> On 09/27/2013 07:32 PM, mikhail cherkasov wrote: >>> Anthony thank you for this link, it's good replacement for removed link. >>> >>> Also I didn't find replacement for : >>> - * Also see the article >> href="http://java.sun.com/products/jfc/tsc/tech_topics/jlist_1/jlist.html">Advanced >>> >>> JList Programming >>> - * in The Swing >>> Connection. >>> >>> Do you have any suggestion about this link? the link to swing tutorial >>> already are there: >>> http://docs.oracle.com/javase/tutorial/uiswing/components/list.html >>> >>> Thanks, >>> Mikhail. >>> >>> On 27.09.2013 18:31, Anthony Petrov wrote: >>>> On 09/27/2013 06:19 PM, mikhail cherkasov wrote: >>>>> Anthony, some links, like this one, we lost for ever. >>>> >>>> How about >>>> http://docs.oracle.com/javase/tutorial/uiswing/events/actionlistener.html >>>> >>>> ? >>>> >>>> >>>>> On 27.09.2013 18:12, Anthony Petrov wrote: >>>>>> Thanks. I skimmed through the changes and they look good generally. A >>>>>> couple of nits: >>>>>> >>>>>> src/share/classes/java/awt/event/ActionListener.java >>>>>>> - * @see >>>>>> href="http://java.sun.com/docs/books/tutorial/post1.0/ui/eventmodel.html">Tutorial: >>>>>>> >>>>>>> >>>>>>> Java 1.1 Event Model >>>>>> >>>>>> You're only removing the link here. You should add a new one, too, I >>>>>> guess. >>>>>> >>>>>> >>>>>> src/share/classes/sun/text/normalizer/UCharacter.java >>>>>>> - * >>>>>> href="http://java.sun.com/j2se/1.5/docs/api/java/lang/Character.html"> >>>>>>> >>>>>>> + * >>>>>> href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Character.html"> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * java.lang.Character class. These extensions provide support >>>>>>> for >>>>>> >>>>>> I believe the here should be replaced with a usual javadoc's >>>>>> {@link ...} kind of thing. >>>>> Agree, and this should be done in all places, but this will be too >>>>> much >>>>> changes for this fix. >>>> >>>> Certainly, we shouldn't change all and every occurrence of this. >>>> However, this line is updated in your fix anyway, so why not apply the >>>> correct pattern just for this particular case now? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 09/27/2013 04:50 PM, mikhail cherkasov wrote: >>>>>>> Hi Anthony, >>>>>>> >>>>>>> Please review a new version: >>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.02/ >>>>>>> >>>>>>> I rely on http redirect, but it doesn't always work correctly. Now I >>>>>>> re-checked all links. >>>>>>> >>>>>>> Thanks, >>>>>>> Mikhail. >>>>>>> >>>>>>> On 27.09.2013 12:42, Anthony Petrov wrote: >>>>>>>> Hi Mikhail, >>>>>>>> >>>>>>>> Please comment on the following: >>>>>>>> >>>>>>>> src/share/classes/java/awt/Component.java: >>>>>>>>> - * >>>>>>>> href="http://java.sun.com/products/jfc/tsc/articles/painting/index.html">Painting >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> in AWT and Swing. >>>>>>>>> + * >>>>>>>> href="http://www.oracle.com/technetwork/java/index.html">Painting >>>>>>>>> in >>>>>>>>> AWT and Swing. >>>>>>>> >>>>>>>> The new link doesn't point to the "Painting..." article (and it >>>>>>>> is a >>>>>>>> very good article, btw). Could you please check all the new >>>>>>>> links and >>>>>>>> update the webrev? >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 09/26/2013 02:27 AM, mikhail cherkasov wrote: >>>>>>>>> a new webrev: >>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.01/ >>>>>>>>> >>>>>>>>> no changes, I've turned off laptop before the webrev upload was >>>>>>>>> complete, so >>>>>>>>> the first could be corrupted. >>>>>>>>> >>>>>>>>> On 25.09.2013 23:29, mikhail cherkasov wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Could you please review the fix for the following bug: >>>>>>>>>> 8020688: broken links in documentation at >>>>>>>>>> http://docs.oracle.com/javase/6/docs/api/index. >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020688 >>>>>>>>>> The webrev: >>>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Mikhail. >>>>>>>>> >>>>>>> >>>>> >>> > From anthony.petrov at oracle.com Fri Oct 4 01:24:53 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 Oct 2013 12:24:53 +0400 Subject: [8] Review request for 7081594 Windows owned by an always-on-top window DO NOT automatically become always-on-top In-Reply-To: <524D6B3E.7030401@oracle.com> References: <524D6B3E.7030401@oracle.com> Message-ID: <524E7B55.9000408@oracle.com> The fix looks good to me. -- best regards, Anthony On 10/03/2013 05:03 PM, Alexander Scherbatiy wrote: > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-7081594 > webrev: http://cr.openjdk.java.net/~alexsch/7081594/webrev.00 > > The fix: > - sets alwaysOnTop field for a new created window from the parent > value > - propagates the alwaysOnTop value in setAlwaysOnTop() method to > the owned windows > > Thanks, > Alexandr. > From anthony.petrov at oracle.com Fri Oct 4 01:26:32 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 Oct 2013 12:26:32 +0400 Subject: [8] Review request for 7068423: Spec for java.awt.GraphicsDevice.getFullScreenWindow() needs clarification In-Reply-To: <524D6E61.80207@oracle.com> References: <524AC214.3000806@oracle.com> <524B15C0.1040402@oracle.com> <524D1D07.3090408@oracle.com> <524D6E61.80207@oracle.com> Message-ID: <524E7BB8.1010106@oracle.com> Still looks fine to me, too. -- best regards, Anthony On 10/03/2013 05:17 PM, Artem Ananiev wrote: > > On 10/3/2013 11:30 AM, Oleg Pekhovskiy wrote: >> Hi All, >> >> please review the second version of fix: >> http://cr.openjdk.java.net/~bagiras/7068423.2/ > > It looks fine to me. > > Thanks, > > Artem > >> Reason: >> Discussed with Artem and Andrew, came to conclusion that there were >> situations when returned object could be also set by the system, and not >> by the client application through setFullScreenWindow(). >> >> Thanks, >> Oleg >> >> On 01.10.2013 22:34, Anthony Petrov wrote: >>> Looks fine. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/01/2013 04:37 PM, Oleg Pekhovskiy wrote: >>>> Hi all, >>>> >>>> please review the fix >>>> http://cr.openjdk.java.net/~bagiras/7068423.1/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-7068423 >>>> >>>> It's just a Javadoc fix. >>>> >>>> Thanks, >>>> Oleg From artem.ananiev at oracle.com Fri Oct 4 01:46:35 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 04 Oct 2013 12:46:35 +0400 Subject: [8] Review request for 7081594 Windows owned by an always-on-top window DO NOT automatically become always-on-top In-Reply-To: <524E7B55.9000408@oracle.com> References: <524D6B3E.7030401@oracle.com> <524E7B55.9000408@oracle.com> Message-ID: <524E806B.6010009@oracle.com> On 10/4/2013 12:24 PM, Anthony Petrov wrote: > The fix looks good to me. +1. I would also add a comment to security exception [empty] handler that we don't really expect exceptions here: either we have the permission, or the owner is not alwaysOnTop. Thanks, Artem > -- > best regards, > Anthony > > On 10/03/2013 05:03 PM, Alexander Scherbatiy wrote: >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-7081594 >> webrev: http://cr.openjdk.java.net/~alexsch/7081594/webrev.00 >> >> The fix: >> - sets alwaysOnTop field for a new created window from the parent >> value >> - propagates the alwaysOnTop value in setAlwaysOnTop() method to >> the owned windows >> >> Thanks, >> Alexandr. >> From anthony.petrov at oracle.com Fri Oct 4 01:49:32 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 Oct 2013 12:49:32 +0400 Subject: [8] Review request for 7081594 Windows owned by an always-on-top window DO NOT automatically become always-on-top In-Reply-To: <524E806B.6010009@oracle.com> References: <524D6B3E.7030401@oracle.com> <524E7B55.9000408@oracle.com> <524E806B.6010009@oracle.com> Message-ID: <524E811C.6020802@oracle.com> On 10/04/2013 12:46 PM, Artem Ananiev wrote: > On 10/4/2013 12:24 PM, Anthony Petrov wrote: >> The fix looks good to me. > > +1. > > I would also add a comment to security exception [empty] handler that we > don't really expect exceptions here: either we have the permission, or > the owner is not alwaysOnTop. setAlwaysOnTop() throws a SecurityException regardless of its argument's value. So the comment is not accurate. I'd leave the code as is - the name "ignore" for the exception tells us all we need to know. -- best regards, Anthony > > Thanks, > > Artem > >> -- >> best regards, >> Anthony >> >> On 10/03/2013 05:03 PM, Alexander Scherbatiy wrote: >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-7081594 >>> webrev: http://cr.openjdk.java.net/~alexsch/7081594/webrev.00 >>> >>> The fix: >>> - sets alwaysOnTop field for a new created window from the parent >>> value >>> - propagates the alwaysOnTop value in setAlwaysOnTop() method to >>> the owned windows >>> >>> Thanks, >>> Alexandr. >>> From artem.ananiev at oracle.com Fri Oct 4 02:06:38 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 04 Oct 2013 13:06:38 +0400 Subject: [8] Review request for 8019623: Lack of synchronization in AppContext.getAppContext() In-Reply-To: References: Message-ID: <524E851E.6020006@oracle.com> Hi, Leonid, the fix looks fine. I believe it is possible to create a regression test for this fix. The test should create several thread groups and call AC.getAC() there, then check that all the returned AC's are equal. Although it won't 100% fail before your fix, it should 100% pass after it. What do you think about it? Thanks, Artem On 10/2/2013 6:22 PM, Leonid Romanov wrote: > Hello, > Please, review a fix for 8019623: Lack of synchronization in AppContext.getAppContext(). I don't think it makes sense to ensure that AppContext.getAppContext()/SunToolkit.createNewAppContext() is thread safe, because in practice we haven't had any problems with this combination. What we have had problems with is the getAppContext()/getAppContext() combination because of the double mainAppContext initialization. Therefore, the fix takes care of this issue. While I could have simply made the whole AppContext.getAppContext() method synchronized, I wanted the most common path through it (returning cached AppContext) to remain lock-free, so I decided to place the lock around the most critical part, where initMainAppContext() gets called. > As for a regression test, I couldn't find a way to detect double initMainAppContext initialization. We put newly created AppContexts into a thread-safe map, so whatever AppContext wins the race remains in the map, and the other is simply lost, without any convenient means to detect its existence. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8019623 > Webrev: http://cr.openjdk.java.net/~leonidr/8019623/webrev.00/ > > Thanks, > Leonid. > From leonid.romanov at oracle.com Fri Oct 4 03:17:59 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 4 Oct 2013 14:17:59 +0400 Subject: [8] Review request for 8019623: Lack of synchronization in AppContext.getAppContext() In-Reply-To: <524E851E.6020006@oracle.com> References: <524E851E.6020006@oracle.com> Message-ID: Hi, Yes, could work, I'll try it. On Oct 4, 2013, at 1:06 PM, Artem Ananiev wrote: > Hi, Leonid, > > the fix looks fine. > > I believe it is possible to create a regression test for this fix. The test should create several thread groups and call AC.getAC() there, then check that all the returned AC's are equal. Although it won't 100% fail before your fix, it should 100% pass after it. What do you think about it? > > Thanks, > > Artem > > On 10/2/2013 6:22 PM, Leonid Romanov wrote: >> Hello, >> Please, review a fix for 8019623: Lack of synchronization in AppContext.getAppContext(). I don't think it makes sense to ensure that AppContext.getAppContext()/SunToolkit.createNewAppContext() is thread safe, because in practice we haven't had any problems with this combination. What we have had problems with is the getAppContext()/getAppContext() combination because of the double mainAppContext initialization. Therefore, the fix takes care of this issue. While I could have simply made the whole AppContext.getAppContext() method synchronized, I wanted the most common path through it (returning cached AppContext) to remain lock-free, so I decided to place the lock around the most critical part, where initMainAppContext() gets called. >> As for a regression test, I couldn't find a way to detect double initMainAppContext initialization. We put newly created AppContexts into a thread-safe map, so whatever AppContext wins the race remains in the map, and the other is simply lost, without any convenient means to detect its existence. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8019623 >> Webrev: http://cr.openjdk.java.net/~leonidr/8019623/webrev.00/ >> >> Thanks, >> Leonid. >> From artem.ananiev at oracle.com Fri Oct 4 03:29:32 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 04 Oct 2013 14:29:32 +0400 Subject: Bug 7107490 affecting JDK7 and JDK8, Bugfix included In-Reply-To: <5242BF1B.3080206@jdownloader.org> References: <5242BF1B.3080206@jdownloader.org> Message-ID: <524E988C.9040202@oracle.com> On 9/25/2013 2:46 PM, Jiaz wrote: > Hi, > could anyone with commit rights please apply the given bugfix in > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7107490 I don't see "the given bugfix", probably it was stripped by OpenJDK mailer... According to the bug report, it's considered to be a duplicate of another one: https://bugs.openjdk.java.net/browse/JDK-7199196 JDK-7199196: Incremental transfer is broken because of a typo Thanks, Artem > Best Regards, > Daniel Wilhelm, JDownloader-Team From anthony.petrov at oracle.com Fri Oct 4 03:45:13 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 Oct 2013 14:45:13 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524C1A79.6030101@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> <524C0411.7060709@oracle.com> <524C110F.6000905@oracle.com> <524C11EF.2040905@oracle.com> <524C13B2.2020700@oracle.com> <524C1A79.6030101@oracle.com> Message-ID: <524E9C39.7090403@oracle.com> On 10/02/2013 05:07 PM, Artem Ananiev wrote: >>> You're right, it's not necessary. However, since we touch this code >>> anyway, I'd be glad to have this redundant code removed. >> >> It's not redundant. Please see my message below in the quote for details. > > Do you mean the following quote: > >>>>>> However, your fix effectively disallows a component to belong to any >>>>>> toolkit other than the default one, because its getToolkit() will >>>>>> never return anything else (unless you extend the component's class >>>>>> and override the method). > > ? Extending the Component class and providing different implementation > for getToolkit() is the way to achieve this functionality. Without this > extension, it doesn't matter if Component.getToolkit() calls to the peer > or directly returns the default toolkit. I can't say I fully agree with that. When using the default toolkit, you don't need to extend public AWT classes. I don't see why you would have to do that when using a custom toolkit. Can we file a separate P4 issue to evaluate this later, and only change the specification with 7081584 ? -- best regards, Anthony > > Thanks, > > Artem > >> -- >> best regards, >> Anthony >> >>> >>> Thanks, >>> >>> Artem >>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>>> >>>>> Thanks, >>>>> SAM >>>>> >>>>> On 01.10.2013 21:47, Anthony Petrov wrote: >>>>>> Hi Sergey, >>>>>> >>>>>> I'm wondering what compatibility impact of this change is. The >>>>>> specification for Component.getToolkit() suggests that in theory >>>>>> several toolkits may co-exist in a single application. And thanks to >>>>>> delegating to the ComponentPeer, the Component.getToolkit() could >>>>>> return the actual toolkit for this component. >>>>>> >>>>>> However, your fix effectively disallows a component to belong to any >>>>>> toolkit other than the default one, because its getToolkit() will >>>>>> never return anything else (unless you extend the component's class >>>>>> and override the method). >>>>>> >>>>>> I really don't know whether this is widely used, but I think this may >>>>>> impact some applications. >>>>>> >>>>>> Also, imagine a window is made to belong to another toolkit somehow, >>>>>> even with your changes. Now, why should its ability to be >>>>>> always-on-top depend on the default toolkit instead of the window's >>>>>> own toolkit? >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 09/27/2013 08:49 PM, sergey malenkov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you please review the following fix: >>>>>>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >>>>>>> >>>>>>> The specification of the Window class waits for CCC approval. This >>>>>>> fix >>>>>>> removes the getTookit method from the ComponentPeer class and its >>>>>>> subclasses. >>>>>>> >>>>>>> Thanks, >>>>>>> SAM >>>>>>> >>>>> From artem.ananiev at oracle.com Fri Oct 4 03:57:28 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 04 Oct 2013 14:57:28 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524E9C39.7090403@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> <524C0411.7060709@oracle.com> <524C110F.6000905@oracle.com> <524C11EF.2040905@oracle.com> <524C13B2.2020700@oracle.com> <524C1A79.6030101@oracle.com> <524E9C39.7090403@oracle.com> Message-ID: <524E9F18.9060003@oracle.com> On 10/4/2013 2:45 PM, Anthony Petrov wrote: > On 10/02/2013 05:07 PM, Artem Ananiev wrote: >>>> You're right, it's not necessary. However, since we touch this code >>>> anyway, I'd be glad to have this redundant code removed. >>> >>> It's not redundant. Please see my message below in the quote for >>> details. >> >> Do you mean the following quote: >> >>>>>>> However, your fix effectively disallows a component to belong to any >>>>>>> toolkit other than the default one, because its getToolkit() will >>>>>>> never return anything else (unless you extend the component's class >>>>>>> and override the method). >> >> ? Extending the Component class and providing different implementation >> for getToolkit() is the way to achieve this functionality. Without this >> extension, it doesn't matter if Component.getToolkit() calls to the peer >> or directly returns the default toolkit. > > I can't say I fully agree with that. When using the default toolkit, you > don't need to extend public AWT classes. I don't see why you would have > to do that when using a custom toolkit. Sorry, I still don't get it... To me it looks like we don't change anything. The current behavior is preserved, Component.getToolkit() returns the default toolkit. Ability to extend the Component class and change getToolkit() is not affected. All the weird cases like co-existence of two different toolkits in the same process, or component peers that are not created by the current toolkit, etc. are not worth thinking about to me. Could you provide a sample, which works with the current implementation and won't work after the proposed fix, please? Thanks, Artem > Can we file a separate P4 issue to evaluate this later, and only change > the specification with 7081584 ? > > -- > best regards, > Anthony > >> >> Thanks, >> >> Artem >> >>> -- >>> best regards, >>> Anthony >>> >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>>> >>>>>> Thanks, >>>>>> SAM >>>>>> >>>>>> On 01.10.2013 21:47, Anthony Petrov wrote: >>>>>>> Hi Sergey, >>>>>>> >>>>>>> I'm wondering what compatibility impact of this change is. The >>>>>>> specification for Component.getToolkit() suggests that in theory >>>>>>> several toolkits may co-exist in a single application. And thanks to >>>>>>> delegating to the ComponentPeer, the Component.getToolkit() could >>>>>>> return the actual toolkit for this component. >>>>>>> >>>>>>> However, your fix effectively disallows a component to belong to any >>>>>>> toolkit other than the default one, because its getToolkit() will >>>>>>> never return anything else (unless you extend the component's class >>>>>>> and override the method). >>>>>>> >>>>>>> I really don't know whether this is widely used, but I think this >>>>>>> may >>>>>>> impact some applications. >>>>>>> >>>>>>> Also, imagine a window is made to belong to another toolkit somehow, >>>>>>> even with your changes. Now, why should its ability to be >>>>>>> always-on-top depend on the default toolkit instead of the window's >>>>>>> own toolkit? >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 09/27/2013 08:49 PM, sergey malenkov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you please review the following fix: >>>>>>>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >>>>>>>> >>>>>>>> The specification of the Window class waits for CCC approval. This >>>>>>>> fix >>>>>>>> removes the getTookit method from the ComponentPeer class and its >>>>>>>> subclasses. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> SAM >>>>>>>> >>>>>> From anthony.petrov at oracle.com Fri Oct 4 04:11:38 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 Oct 2013 15:11:38 +0400 Subject: [8] Review request for 7159266: [macosx] ApplicationDelegate should not be set in the headless mode Message-ID: <524EA26A.20203@oracle.com> Hello, This is another forward-port (a direct one this time) that didn't make it into JDK 8 yet: bug: https://bugs.openjdk.java.net/browse/JDK-2224144 webrev: http://cr.openjdk.java.net/~anthony/8-62-headlessAppDelegate-7159266.0/ Summary of the fix: in headless mode the application delegate is useless because it's GUI-oriented. Hence we don't need to install it. Testing: I'm unable to test this fix because the related functionality in FX is currently broken (which is caused by a different issue). However, this is a direct forward-port of the same fix from 7u4 which has already been tested well in JDK 7, and hence I'm confident in the fix. -- best regards, Anthony From Sergey.Bylokhov at oracle.com Fri Oct 4 04:29:58 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 04 Oct 2013 15:29:58 +0400 Subject: [8] Review request for 7081594 Windows owned by an always-on-top window DO NOT automatically become always-on-top In-Reply-To: <524E806B.6010009@oracle.com> References: <524D6B3E.7030401@oracle.com> <524E7B55.9000408@oracle.com> <524E806B.6010009@oracle.com> Message-ID: <524EA6B6.40903@oracle.com> Hello. It is interesting what should happens if we set saot for the child, then set it to the owner, and then remove this property from the owner. On 04.10.2013 12:46, Artem Ananiev wrote: > > On 10/4/2013 12:24 PM, Anthony Petrov wrote: >> The fix looks good to me. > > +1. > > I would also add a comment to security exception [empty] handler that > we don't really expect exceptions here: either we have the permission, > or the owner is not alwaysOnTop. > > Thanks, > > Artem > >> -- >> best regards, >> Anthony >> >> On 10/03/2013 05:03 PM, Alexander Scherbatiy wrote: >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-7081594 >>> webrev: http://cr.openjdk.java.net/~alexsch/7081594/webrev.00 >>> >>> The fix: >>> - sets alwaysOnTop field for a new created window from the parent >>> value >>> - propagates the alwaysOnTop value in setAlwaysOnTop() method to >>> the owned windows >>> >>> Thanks, >>> Alexandr. >>> -- Best regards, Sergey. From anthony.petrov at oracle.com Fri Oct 4 04:37:58 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 Oct 2013 15:37:58 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524E9F18.9060003@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> <524C0411.7060709@oracle.com> <524C110F.6000905@oracle.com> <524C11EF.2040905@oracle.com> <524C13B2.2020700@oracle.com> <524C1A79.6030101@oracle.com> <524E9C39.7090403@oracle.com> <524E9F18.9060003@oracle.com> Message-ID: <524EA896.8070603@oracle.com> On 10/04/2013 02:57 PM, Artem Ananiev wrote: > On 10/4/2013 2:45 PM, Anthony Petrov wrote: >> On 10/02/2013 05:07 PM, Artem Ananiev wrote: >>>>> You're right, it's not necessary. However, since we touch this code >>>>> anyway, I'd be glad to have this redundant code removed. >>>> >>>> It's not redundant. Please see my message below in the quote for >>>> details. >>> >>> Do you mean the following quote: >>> >>>>>>>> However, your fix effectively disallows a component to belong to >>>>>>>> any >>>>>>>> toolkit other than the default one, because its getToolkit() will >>>>>>>> never return anything else (unless you extend the component's class >>>>>>>> and override the method). >>> >>> ? Extending the Component class and providing different implementation >>> for getToolkit() is the way to achieve this functionality. Without this >>> extension, it doesn't matter if Component.getToolkit() calls to the peer >>> or directly returns the default toolkit. >> >> I can't say I fully agree with that. When using the default toolkit, you >> don't need to extend public AWT classes. I don't see why you would have >> to do that when using a custom toolkit. > > Sorry, I still don't get it... To me it looks like we don't change > anything. The current behavior is preserved, Component.getToolkit() > returns the default toolkit. Ability to extend the Component class and > change getToolkit() is not affected. All the weird cases like > co-existence of two different toolkits in the same process, or component > peers that are not created by the current toolkit, etc. are not worth > thinking about to me. > > Could you provide a sample, which works with the current implementation > and won't work after the proposed fix, please? No, unfortunately I don't have a working sample. I'm only considering a theoretical possibility of several toolkits co-existing in a single VM. I looked over the addNotify() implementation and see that it relies upon the getToolkit() method. So indeed, w/o overriding it you can't construct an AWT widget using a 3rd-party toolkit. OTOH, such a toolkit might provide a factory method for components, and set its peer field before returning the component instance to the app (w/o actually extending the class). This case would break with the current fix. Also, w/o clear understanding of the reason why the ComponentPeer.getToolkit() and the corresponding logic in Component.getToolkit() were introduced in the first place, it looks kind of scary to just drop this method so late in the JDK8 release cycle. Since this part of the fix isn't mandatory for the specification change, I still suggest to file a separate issue and investigate it later because it doesn't seem urgent (as opposed to the spec change itself.) -- best regards, Anthony > > Thanks, > > Artem > >> Can we file a separate P4 issue to evaluate this later, and only change >> the specification with 7081584 ? >> >> -- >> best regards, >> Anthony >> >>> >>> Thanks, >>> >>> Artem >>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> SAM >>>>>>> >>>>>>> On 01.10.2013 21:47, Anthony Petrov wrote: >>>>>>>> Hi Sergey, >>>>>>>> >>>>>>>> I'm wondering what compatibility impact of this change is. The >>>>>>>> specification for Component.getToolkit() suggests that in theory >>>>>>>> several toolkits may co-exist in a single application. And >>>>>>>> thanks to >>>>>>>> delegating to the ComponentPeer, the Component.getToolkit() could >>>>>>>> return the actual toolkit for this component. >>>>>>>> >>>>>>>> However, your fix effectively disallows a component to belong to >>>>>>>> any >>>>>>>> toolkit other than the default one, because its getToolkit() will >>>>>>>> never return anything else (unless you extend the component's class >>>>>>>> and override the method). >>>>>>>> >>>>>>>> I really don't know whether this is widely used, but I think this >>>>>>>> may >>>>>>>> impact some applications. >>>>>>>> >>>>>>>> Also, imagine a window is made to belong to another toolkit >>>>>>>> somehow, >>>>>>>> even with your changes. Now, why should its ability to be >>>>>>>> always-on-top depend on the default toolkit instead of the window's >>>>>>>> own toolkit? >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 09/27/2013 08:49 PM, sergey malenkov wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you please review the following fix: >>>>>>>>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >>>>>>>>> >>>>>>>>> The specification of the Window class waits for CCC approval. This >>>>>>>>> fix >>>>>>>>> removes the getTookit method from the ComponentPeer class and its >>>>>>>>> subclasses. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> SAM >>>>>>>>> >>>>>>> From yuri.nesterenko at oracle.com Fri Oct 4 04:38:44 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 04 Oct 2013 15:38:44 +0400 Subject: [8] Review Request for 8025649: need test to cover JDK-8000423 In-Reply-To: <5249772F.6060503@oracle.com> References: <5249772F.6060503@oracle.com> Message-ID: <524EA8C4.30705@oracle.com> Looks OK, thanks. -yan On 09/30/2013 05:05 PM, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following [TEST] bug: > https://bugs.openjdk.java.net/browse/JDK-8025649 > > Webrev corresponding: > http://cr.openjdk.java.net/~alexsch/alexander-stepanov/8025649/webrev.00/ > > Just a new test added; no other code affected. > The patch contains a simple manual test to make sure if diacritical > marks could be typed for TextArea and TextField (hard to automate; the > test requires some internationalization settings on a machine). > > Thanks, > Alexander. From anthony.petrov at oracle.com Fri Oct 4 04:39:31 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 Oct 2013 15:39:31 +0400 Subject: [8] Review request for 7081594 Windows owned by an always-on-top window DO NOT automatically become always-on-top In-Reply-To: <524EA6B6.40903@oracle.com> References: <524D6B3E.7030401@oracle.com> <524E7B55.9000408@oracle.com> <524E806B.6010009@oracle.com> <524EA6B6.40903@oracle.com> Message-ID: <524EA8F3.9020201@oracle.com> Good point, Sergey. Indeed, it seems that resetting the always on top state to false for an owner window shouldn't affect its owned windows. -- best regards, Anthony On 10/04/2013 03:29 PM, Sergey Bylokhov wrote: > Hello. > It is interesting what should happens if we set saot for the child, then > set it to the owner, and then remove this property from the owner. > > On 04.10.2013 12:46, Artem Ananiev wrote: >> >> On 10/4/2013 12:24 PM, Anthony Petrov wrote: >>> The fix looks good to me. >> >> +1. >> >> I would also add a comment to security exception [empty] handler that >> we don't really expect exceptions here: either we have the permission, >> or the owner is not alwaysOnTop. >> >> Thanks, >> >> Artem >> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/03/2013 05:03 PM, Alexander Scherbatiy wrote: >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-7081594 >>>> webrev: http://cr.openjdk.java.net/~alexsch/7081594/webrev.00 >>>> >>>> The fix: >>>> - sets alwaysOnTop field for a new created window from the parent >>>> value >>>> - propagates the alwaysOnTop value in setAlwaysOnTop() method to >>>> the owned windows >>>> >>>> Thanks, >>>> Alexandr. >>>> > > From Sergey.Bylokhov at oracle.com Fri Oct 4 04:44:47 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 04 Oct 2013 15:44:47 +0400 Subject: [8] Review Request for 8025649: need test to cover JDK-8000423 In-Reply-To: <5249772F.6060503@oracle.com> References: <5249772F.6060503@oracle.com> Message-ID: <524EAA2F.6030704@oracle.com> Hello, Alexander. The fix looks good, But please add copyright to the html file also. On 30.09.2013 17:05, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following [TEST] bug: > https://bugs.openjdk.java.net/browse/JDK-8025649 > > Webrev corresponding: > http://cr.openjdk.java.net/~alexsch/alexander-stepanov/8025649/webrev.00/ > > Just a new test added; no other code affected. > The patch contains a simple manual test to make sure if diacritical > marks could be typed for TextArea and TextField (hard to automate; the > test requires some internationalization settings on a machine). > > Thanks, > Alexander. -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Fri Oct 4 04:45:10 2013 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 04 Oct 2013 15:45:10 +0400 Subject: Bug 7107490 affecting JDK7 and JDK8, Bugfix included In-Reply-To: <524E988C.9040202@oracle.com> References: <5242BF1B.3080206@jdownloader.org> <524E988C.9040202@oracle.com> Message-ID: <524EAA46.2010703@oracle.com> Hi Anthony, I think the given bugfix is: diff -r 0cc00c11e17e src/solaris/classes/sun/awt/X11/XSelection.java --- a/src/solaris/classes/sun/awt/X11/XSelection.java Tue Sep 10 20:42:15 2013 +0400 +++ b/src/solaris/classes/sun/awt/X11/XSelection.java Fri Oct 04 15:32:36 2013 +0400 @@ -375,7 +375,7 @@ XToolkit.awtUnlock(); } - validateDataGetter(dataGetter); + validateDataGetter(incrDataGetter); if (incrDataGetter.getActualFormat() != 8) { throw new IOException("Unsupported data format: " + It looks like we validating a wrong dataGetter. -- Thanks, Alexander. On 10/04/2013 02:29 PM, Artem Ananiev wrote: > > On 9/25/2013 2:46 PM, Jiaz wrote: >> Hi, >> could anyone with commit rights please apply the given bugfix in >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7107490 > > I don't see "the given bugfix", probably it was stripped by OpenJDK > mailer... According to the bug report, it's considered to be a > duplicate of another one: > > https://bugs.openjdk.java.net/browse/JDK-7199196 > > JDK-7199196: Incremental transfer is broken because of a typo > > Thanks, > > Artem > >> Best Regards, >> Daniel Wilhelm, JDownloader-Team From yuri.nesterenko at oracle.com Fri Oct 4 04:52:51 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 04 Oct 2013 15:52:51 +0400 Subject: [8] Review request for 7033533: realSync() doesn't work with Xfce In-Reply-To: <524ABFC6.8000200@oracle.com> References: <5242D93C.4070809@oracle.com> <5242EEF6.2010609@oracle.com> <5243E8C4.7060004@oracle.com> <524AB228.80803@oracle.com> <524AB9A6.8040500@oracle.com> <524ABFC6.8000200@oracle.com> Message-ID: <524EAC13.2060601@oracle.com> So far, I've run some 300+ awt tests with patched build on Solaris 11 sparcv9 and Ubuntu 13.04 Unity. Overall passrate is regular. Most of the failing tests using realSync do fail rather similarly with patched build and b110. However some failures are suspicious. Try on Ubuntu with Unity. test/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java consistently fails some 6 out of 20 runs with patched build but never in the promoted b110. It may be test issue though, somehow. event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in half of the runs with "Incorrect event number" but always pass with b110 (4 or 5 runs). Event number! It may be superficial resemblance but -- Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java -- coincidence here: Oleg, perhaps you should use @library ../../regtesthelpers and @build Util in these regtests: import test.java.awt.regtesthelpers.Util fails. Thanks, -yan On 10/01/2013 04:27 PM, Yuri Nesterenko wrote: > Sure we can say that Xfce is not complying -- it is not officially > supported by JDK -- neither is LXDE etc. -- but saying that gets > us nowhere. > > As to testing, could you suggest a platform selection? I'm afraid > we'll not be able to test Xsun properly but Xorg with Gnome on > Linux and Solaris, Unity and Xfce4 -- > all that we can do by the weekend. > > Thanks, > -yan > > On 10/01/2013 04:01 PM, Leonid Romanov wrote: >> By the way, I was reading Inter-Client Communication Conventions Manual >> so I could better understand the fix, and found the following: >> >> "4.3. Communication with the Window Manager by Means of Selections >> >> For each screen they manage, window managers will acquire ownership of a >> selection named WM_Sn, where n is the screen number, as described in >> section 1.2.6. Window managers should comply with the conventions for >> "Manager Selections" described in section 2.8. The intent is for clients >> to be able to request a variety of information or services by issuing >> conversion requests on this selection." >> >> Considering this, can we say that Xfce is not complying to the spec? >> >> On 10/1/2013 15:29, Anthony Petrov wrote: >>> Hi Oleg, >>> >>> I second to Leonid: you should add a comment and explain why you >>> expect exactly 4 (or more) events to be processed. Preferably, you >>> should list each event to clearly understand this. >>> >>> A minor comment is, lines 2404 - 2407 should be moved to the nearest >>> try{} block at line 2409. >>> >>> A major concern is that I'm not sure the new solution is reliable in >>> all cases. Previously, we expected to get a notification from another >>> process (the WM). Now we process the notification ourselves and are >>> the owners of the selection. I don't know for sure, but suppose some >>> xlib implementations could optimize this scenario and process events >>> locally w/o even sending them to the X server. In which case there >>> wouldn't be any real synchronization of the native event queue. That's >>> why communicating with another process was an important part of this >>> procedure. >>> >>> How about we try the original method first, and only if it fails, then >>> try this workaround solution? >>> >>> Also, this is a very sensitive method because a lot of code relies on >>> it. I suggest running all automatic regression tests for AWT and Swing >>> areas to make sure we don't introduce a regression with this fix. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 09/26/2013 11:56 AM, Oleg Pekhovskiy wrote: >>>> Hi Leonid, >>>> >>>> I did it mostly logically, because my fix added one more service event >>>> (SelectionRequest), that should be excluded from the number of >>>> dispatched native events. >>>> IMHO, the previous number "2" should have been commented, but, that did >>>> not happen. >>>> >>>> Thanks, >>>> Oleg >>>> >>>> On 25.09.2013 18:11, Leonid Romanov wrote: >>>>> Hi, >>>>> I'm not an expert in X11 programming, so I can't comment about the fix >>>>> in general, but I think the line 2436, "return getEventNumber() - >>>>> event_number > 3", really asks for a comment. >>>>> >>>>> On 9/25/2013 16:38, Oleg Pekhovskiy wrote: >>>>>> Hi all, >>>>>> >>>>>> please review the fix >>>>>> http://cr.openjdk.java.net/~bagiras/7033533.1/ >>>>>> for >>>>>> https://bugs.openjdk.java.net/browse/JDK-7033533 >>>>>> >>>>>> Previous implementation of XToolkit.syncNativeQueue() relied upon >>>>>> WM_S0 atom existence and that it was owned by current window manager. >>>>>> But several WMs (like XFCE and LXDE) don't send SelectionNotify event >>>>>> to the client on XConvertSelection() for that atom. That led >>>>>> XToolkit.syncNativeQueue() to hang until TimeOutException. >>>>>> >>>>>> I decided to keep XConvertSelection() usage, but make root toolkit >>>>>> window as an owner for selection atom (with another name), and handle >>>>>> SelectionRequest event from X Server, sending SelectionNotify in >>>>>> response (as window manager is supposed to do). >>>>>> >>>>>> Tested on both XFCE and LXDE. >>>>>> >>>>>> Thanks, >>>>>> Oleg >>>>> >> > From oleg.pekhovskiy at oracle.com Fri Oct 4 05:09:59 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 04 Oct 2013 16:09:59 +0400 Subject: Bug 7107490 affecting JDK7 and JDK8, Bugfix included In-Reply-To: <524EAA46.2010703@oracle.com> References: <5242BF1B.3080206@jdownloader.org> <524E988C.9040202@oracle.com> <524EAA46.2010703@oracle.com> Message-ID: <524EB017.8050407@oracle.com> Hi Alexander, that's right and that proposal was made in issue description. Victor asked to push those changes. I'm doing it right now. Don't you mind? ;) Thanks, Oleg On 04.10.2013 15:45, Alexander Zvegintsev wrote: > Hi Anthony, > I think the given bugfix is: > > diff -r 0cc00c11e17e src/solaris/classes/sun/awt/X11/XSelection.java > --- a/src/solaris/classes/sun/awt/X11/XSelection.java Tue Sep 10 > 20:42:15 2013 +0400 > +++ b/src/solaris/classes/sun/awt/X11/XSelection.java Fri Oct 04 > 15:32:36 2013 +0400 > @@ -375,7 +375,7 @@ > XToolkit.awtUnlock(); > } > > - validateDataGetter(dataGetter); > + validateDataGetter(incrDataGetter); > > if (incrDataGetter.getActualFormat() != 8) { > throw new IOException("Unsupported > data format: " + > > It looks like we validating a wrong dataGetter. > > -- > Thanks, > Alexander. > > On 10/04/2013 02:29 PM, Artem Ananiev wrote: >> >> On 9/25/2013 2:46 PM, Jiaz wrote: >>> Hi, >>> could anyone with commit rights please apply the given bugfix in >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7107490 >> >> I don't see "the given bugfix", probably it was stripped by OpenJDK >> mailer... According to the bug report, it's considered to be a >> duplicate of another one: >> >> https://bugs.openjdk.java.net/browse/JDK-7199196 >> >> JDK-7199196: Incremental transfer is broken because of a typo >> >> Thanks, >> >> Artem >> >>> Best Regards, >>> Daniel Wilhelm, JDownloader-Team > From alexander.zvegintsev at oracle.com Fri Oct 4 05:30:59 2013 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 04 Oct 2013 16:30:59 +0400 Subject: Bug 7107490 affecting JDK7 and JDK8, Bugfix included In-Reply-To: <524EB017.8050407@oracle.com> References: <5242BF1B.3080206@jdownloader.org> <524E988C.9040202@oracle.com> <524EAA46.2010703@oracle.com> <524EB017.8050407@oracle.com> Message-ID: <524EB503.2050504@oracle.com> Hi Oleg, That was just a point to a fix. Of course, I don't mind. -- Thanks, Alexander. On 10/04/2013 04:09 PM, Oleg Pekhovskiy wrote: > Hi Alexander, > > that's right and that proposal was made in issue description. > Victor asked to push those changes. I'm doing it right now. > Don't you mind? ;) > > Thanks, > Oleg > > > > On 04.10.2013 15:45, Alexander Zvegintsev wrote: >> Hi Anthony, >> I think the given bugfix is: >> >> diff -r 0cc00c11e17e src/solaris/classes/sun/awt/X11/XSelection.java >> --- a/src/solaris/classes/sun/awt/X11/XSelection.java Tue Sep 10 >> 20:42:15 2013 +0400 >> +++ b/src/solaris/classes/sun/awt/X11/XSelection.java Fri Oct 04 >> 15:32:36 2013 +0400 >> @@ -375,7 +375,7 @@ >> XToolkit.awtUnlock(); >> } >> >> - validateDataGetter(dataGetter); >> + validateDataGetter(incrDataGetter); >> >> if (incrDataGetter.getActualFormat() != >> 8) { >> throw new IOException("Unsupported >> data format: " + >> >> It looks like we validating a wrong dataGetter. >> >> -- >> Thanks, >> Alexander. >> >> On 10/04/2013 02:29 PM, Artem Ananiev wrote: >>> >>> On 9/25/2013 2:46 PM, Jiaz wrote: >>>> Hi, >>>> could anyone with commit rights please apply the given bugfix in >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7107490 >>> >>> I don't see "the given bugfix", probably it was stripped by OpenJDK >>> mailer... According to the bug report, it's considered to be a >>> duplicate of another one: >>> >>> https://bugs.openjdk.java.net/browse/JDK-7199196 >>> >>> JDK-7199196: Incremental transfer is broken because of a typo >>> >>> Thanks, >>> >>> Artem >>> >>>> Best Regards, >>>> Daniel Wilhelm, JDownloader-Team >> From dmitry.ginzburg at oracle.com Fri Oct 4 06:38:27 2013 From: dmitry.ginzburg at oracle.com (Dmitry Ginzburg) Date: Fri, 04 Oct 2013 17:38:27 +0400 Subject: [8] Review Request: JDK-8025236 [javadoc] fix some errors in AWT In-Reply-To: <524B111D.5000804@oracle.com> References: <52442E3F.6000109@oracle.com> <524442D6.3030007@oracle.com> <52458D96.2090005@oracle.com> <5249821E.2030409@oracle.com> <524B111D.5000804@oracle.com> Message-ID: <524EC4D3.40204@oracle.com> Hi Anthony I renewed this fix against your issues: http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.01/ Thanks, -Dmitry 01.10.2013 22:14, Anthony Petrov wrote: > You should only change the issues in lines that are already > modified in your fix. No massive reformatting please. > > And yes, the rest of the procedure is to publish the second version of > the webrev, and post a link to this mailing list. > > -- > best regards, > Anthony > > On 09/30/2013 05:52 PM, Dmitry Ginzburg wrote: >> So, should I fix all the issues with this ""'s, do webrev again >> and send it to yan, and send it here again? >> >> Thanks, >> >> -Dmitry >> >> 27.09.2013 17:52, Anthony Petrov wrote: >>> The fix looks good to me. Again, if possible, I'd suggest to replace >>> with {@code ..} if you're changing a line anyway. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 09/26/2013 06:21 PM, Dmitry Ginzburg wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the following issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8025236 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.00/ >>>> >>>> This is the fix for javadoc errors, on which doclint was showing some >>>> issues. >>>> >>>> The patch contains only simple markup fixes; no changes/fixes in >>>> documentation text; the specification itself wasn't changed. >>>> >>>> Thanks, >>>> -Dmitry -- Dmitry Ginzburg, FXSQE team member From Sergey.Bylokhov at oracle.com Fri Oct 4 06:43:41 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 04 Oct 2013 17:43:41 +0400 Subject: [8] Review Request: JDK-8025236 [javadoc] fix some errors in AWT In-Reply-To: <524EC4D3.40204@oracle.com> References: <52442E3F.6000109@oracle.com> <524442D6.3030007@oracle.com> <52458D96.2090005@oracle.com> <5249821E.2030409@oracle.com> <524B111D.5000804@oracle.com> <524EC4D3.40204@oracle.com> Message-ID: <524EC60D.2050705@oracle.com> *InputEvent.java: *I suppose it would be better to add code tag instead of changes "&" in the code to &. On 04.10.2013 17:38, Dmitry Ginzburg wrote: > Hi Anthony > > I renewed this fix against your issues: > http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.01/ > > Thanks, > -Dmitry > > 01.10.2013 22:14, Anthony Petrov wrote: >> You should only change the issues in lines that are already >> modified in your fix. No massive reformatting please. >> >> And yes, the rest of the procedure is to publish the second version >> of the webrev, and post a link to this mailing list. >> >> -- >> best regards, >> Anthony >> >> On 09/30/2013 05:52 PM, Dmitry Ginzburg wrote: >>> So, should I fix all the issues with this ""'s, do webrev again >>> and send it to yan, and send it here again? >>> >>> Thanks, >>> >>> -Dmitry >>> >>> 27.09.2013 17:52, Anthony Petrov wrote: >>>> The fix looks good to me. Again, if possible, I'd suggest to replace >>>> with {@code ..} if you're changing a line anyway. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 09/26/2013 06:21 PM, Dmitry Ginzburg wrote: >>>>> Hello, AWT Team. >>>>> >>>>> Please review the fix for the following issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025236 >>>>> The fix is available at: >>>>> http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.00/ >>>>> >>>>> This is the fix for javadoc errors, on which doclint was showing some >>>>> issues. >>>>> >>>>> The patch contains only simple markup fixes; no changes/fixes in >>>>> documentation text; the specification itself wasn't changed. >>>>> >>>>> Thanks, >>>>> -Dmitry > > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131004/b26d345f/attachment.html From Sergey.Bylokhov at oracle.com Fri Oct 4 06:47:06 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 04 Oct 2013 17:47:06 +0400 Subject: [8] Review Request: JDK-8025236 [javadoc] fix some errors in AWT In-Reply-To: <524EC60D.2050705@oracle.com> References: <52442E3F.6000109@oracle.com> <524442D6.3030007@oracle.com> <52458D96.2090005@oracle.com> <5249821E.2030409@oracle.com> <524B111D.5000804@oracle.com> <524EC4D3.40204@oracle.com> <524EC60D.2050705@oracle.com> Message-ID: <524EC6DA.3090207@oracle.com> InputContext.java: If you remove

tag from the end of the list you should remove it from the beginning of the list as well. On 04.10.2013 17:43, Sergey Bylokhov wrote: > *InputEvent.java: *I suppose it would be better to add code tag > instead of changes "&" in the code to &. > > On 04.10.2013 17:38, Dmitry Ginzburg wrote: >> Hi Anthony >> >> I renewed this fix against your issues: >> http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.01/ >> >> Thanks, >> -Dmitry >> >> 01.10.2013 22:14, Anthony Petrov wrote: >>> You should only change the issues in lines that are already >>> modified in your fix. No massive reformatting please. >>> >>> And yes, the rest of the procedure is to publish the second version >>> of the webrev, and post a link to this mailing list. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 09/30/2013 05:52 PM, Dmitry Ginzburg wrote: >>>> So, should I fix all the issues with this ""'s, do webrev again >>>> and send it to yan, and send it here again? >>>> >>>> Thanks, >>>> >>>> -Dmitry >>>> >>>> 27.09.2013 17:52, Anthony Petrov wrote: >>>>> The fix looks good to me. Again, if possible, I'd suggest to replace >>>>> with {@code ..} if you're changing a line anyway. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 09/26/2013 06:21 PM, Dmitry Ginzburg wrote: >>>>>> Hello, AWT Team. >>>>>> >>>>>> Please review the fix for the following issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8025236 >>>>>> The fix is available at: >>>>>> http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.00/ >>>>>> >>>>>> This is the fix for javadoc errors, on which doclint was showing >>>>>> some >>>>>> issues. >>>>>> >>>>>> The patch contains only simple markup fixes; no changes/fixes in >>>>>> documentation text; the specification itself wasn't changed. >>>>>> >>>>>> Thanks, >>>>>> -Dmitry >> >> > > > -- > Best regards, Sergey. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131004/d67f368a/attachment.html From dmitry.ginzburg at oracle.com Fri Oct 4 06:49:39 2013 From: dmitry.ginzburg at oracle.com (Dmitry Ginzburg) Date: Fri, 04 Oct 2013 17:49:39 +0400 Subject: [8] Review Request: JDK-8025236 [javadoc] fix some errors in AWT In-Reply-To: <524EC6DA.3090207@oracle.com> References: <52442E3F.6000109@oracle.com> <524442D6.3030007@oracle.com> <52458D96.2090005@oracle.com> <5249821E.2030409@oracle.com> <524B111D.5000804@oracle.com> <524EC4D3.40204@oracle.com> <524EC60D.2050705@oracle.com> <524EC6DA.3090207@oracle.com> Message-ID: <524EC773.2080405@oracle.com> doclint doesn't show any error on this issue 04.10.2013 17:47, Sergey Bylokhov wrote: > InputContext.java: If you remove

tag from the end of the list you > should remove it from the beginning of the list as well. > > On 04.10.2013 17:43, Sergey Bylokhov wrote: >> *InputEvent.java: *I suppose it would be better to add code tag >> instead of changes "&" in the code to &. >> >> On 04.10.2013 17:38, Dmitry Ginzburg wrote: >>> Hi Anthony >>> >>> I renewed this fix against your issues: >>> http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.01/ >>> >>> Thanks, >>> -Dmitry >>> >>> 01.10.2013 22:14, Anthony Petrov wrote: >>>> You should only change the issues in lines that are already >>>> modified in your fix. No massive reformatting please. >>>> >>>> And yes, the rest of the procedure is to publish the second version >>>> of the webrev, and post a link to this mailing list. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 09/30/2013 05:52 PM, Dmitry Ginzburg wrote: >>>>> So, should I fix all the issues with this ""'s, do webrev again >>>>> and send it to yan, and send it here again? >>>>> >>>>> Thanks, >>>>> >>>>> -Dmitry >>>>> >>>>> 27.09.2013 17:52, Anthony Petrov wrote: >>>>>> The fix looks good to me. Again, if possible, I'd suggest to replace >>>>>> with {@code ..} if you're changing a line anyway. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 09/26/2013 06:21 PM, Dmitry Ginzburg wrote: >>>>>>> Hello, AWT Team. >>>>>>> >>>>>>> Please review the fix for the following issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025236 >>>>>>> The fix is available at: >>>>>>> http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.00/ >>>>>>> >>>>>>> This is the fix for javadoc errors, on which doclint was showing >>>>>>> some >>>>>>> issues. >>>>>>> >>>>>>> The patch contains only simple markup fixes; no changes/fixes in >>>>>>> documentation text; the specification itself wasn't changed. >>>>>>> >>>>>>> Thanks, >>>>>>> -Dmitry >>> >>> >> >> >> -- >> Best regards, Sergey. > > > -- > Best regards, Sergey. -- Dmitry Ginzburg, FXSQE team member -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131004/4f8febe2/attachment.html From Sergey.Bylokhov at oracle.com Fri Oct 4 06:53:48 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 04 Oct 2013 17:53:48 +0400 Subject: [8] Review Request: JDK-8025236 [javadoc] fix some errors in AWT In-Reply-To: <524EC773.2080405@oracle.com> References: <52442E3F.6000109@oracle.com> <524442D6.3030007@oracle.com> <52458D96.2090005@oracle.com> <5249821E.2030409@oracle.com> <524B111D.5000804@oracle.com> <524EC4D3.40204@oracle.com> <524EC60D.2050705@oracle.com> <524EC6DA.3090207@oracle.com> <524EC773.2080405@oracle.com> Message-ID: <524EC86C.3010303@oracle.com> It does not matter, since your change is not symmetric. On 04.10.2013 17:49, Dmitry Ginzburg wrote: > doclint doesn't show any error on this issue > > 04.10.2013 17:47, Sergey Bylokhov wrote: >> InputContext.java: If you remove

tag from the end of the list you >> should remove it from the beginning of the list as well. >> >> On 04.10.2013 17:43, Sergey Bylokhov wrote: >>> *InputEvent.java: *I suppose it would be better to add code tag >>> instead of changes "&" in the code to &. >>> >>> On 04.10.2013 17:38, Dmitry Ginzburg wrote: >>>> Hi Anthony >>>> >>>> I renewed this fix against your issues: >>>> http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.01/ >>>> >>>> Thanks, >>>> -Dmitry >>>> >>>> 01.10.2013 22:14, Anthony Petrov wrote: >>>>> You should only change the issues in lines that are already >>>>> modified in your fix. No massive reformatting please. >>>>> >>>>> And yes, the rest of the procedure is to publish the second >>>>> version of the webrev, and post a link to this mailing list. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 09/30/2013 05:52 PM, Dmitry Ginzburg wrote: >>>>>> So, should I fix all the issues with this ""'s, do webrev >>>>>> again >>>>>> and send it to yan, and send it here again? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> 27.09.2013 17:52, Anthony Petrov wrote: >>>>>>> The fix looks good to me. Again, if possible, I'd suggest to >>>>>>> replace >>>>>>> with {@code ..} if you're changing a line anyway. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 09/26/2013 06:21 PM, Dmitry Ginzburg wrote: >>>>>>>> Hello, AWT Team. >>>>>>>> >>>>>>>> Please review the fix for the following issue: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025236 >>>>>>>> The fix is available at: >>>>>>>> http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.00/ >>>>>>>> >>>>>>>> This is the fix for javadoc errors, on which doclint was >>>>>>>> showing some >>>>>>>> issues. >>>>>>>> >>>>>>>> The patch contains only simple markup fixes; no changes/fixes in >>>>>>>> documentation text; the specification itself wasn't changed. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -Dmitry >>>> >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> >> >> -- >> Best regards, Sergey. > > > -- > Dmitry Ginzburg, FXSQE team member -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131004/66303aac/attachment-0001.html From yuri.nesterenko at oracle.com Fri Oct 4 07:52:32 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 04 Oct 2013 18:52:32 +0400 Subject: [8] Review request for 7033533: realSync() doesn't work with Xfce In-Reply-To: <524EAC13.2060601@oracle.com> References: <5242D93C.4070809@oracle.com> <5242EEF6.2010609@oracle.com> <5243E8C4.7060004@oracle.com> <524AB228.80803@oracle.com> <524AB9A6.8040500@oracle.com> <524ABFC6.8000200@oracle.com> <524EAC13.2060601@oracle.com> Message-ID: <524ED630.8040504@oracle.com> OK, Ubuntu 13.10 (final beta) with Mir instead of X11 looks surprisingly good. It fails in couple of places with exceptions like "sun.awt.X11.XException: Cannot write XdndAware property" bug overall the patched build run the awt regression suite quite OK. Thanks, -yan On 10/04/2013 03:52 PM, Yuri Nesterenko wrote: > So far, I've run some 300+ awt tests with patched build > on Solaris 11 sparcv9 and Ubuntu 13.04 Unity. > > Overall passrate is regular. > Most of the failing tests using realSync do fail rather > similarly with patched build and b110. > > However some failures are suspicious. Try on Ubuntu with Unity. > > test/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java > consistently fails some 6 out of 20 runs with patched build but > never in the promoted b110. It may be test issue though, somehow. > > event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java > fails in half of the runs with "Incorrect event number" but > always pass with b110 (4 or 5 runs). > Event number! It may be superficial resemblance but -- > > Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java -- > coincidence here: Oleg, perhaps you should use > @library ../../regtesthelpers and > @build Util > in these regtests: import test.java.awt.regtesthelpers.Util fails. > > Thanks, > -yan > > On 10/01/2013 04:27 PM, Yuri Nesterenko wrote: >> Sure we can say that Xfce is not complying -- it is not officially >> supported by JDK -- neither is LXDE etc. -- but saying that gets >> us nowhere. >> >> As to testing, could you suggest a platform selection? I'm afraid >> we'll not be able to test Xsun properly but Xorg with Gnome on >> Linux and Solaris, Unity and Xfce4 -- >> all that we can do by the weekend. >> >> Thanks, >> -yan >> >> On 10/01/2013 04:01 PM, Leonid Romanov wrote: >>> By the way, I was reading Inter-Client Communication Conventions Manual >>> so I could better understand the fix, and found the following: >>> >>> "4.3. Communication with the Window Manager by Means of Selections >>> >>> For each screen they manage, window managers will acquire ownership of a >>> selection named WM_Sn, where n is the screen number, as described in >>> section 1.2.6. Window managers should comply with the conventions for >>> "Manager Selections" described in section 2.8. The intent is for clients >>> to be able to request a variety of information or services by issuing >>> conversion requests on this selection." >>> >>> Considering this, can we say that Xfce is not complying to the spec? >>> >>> On 10/1/2013 15:29, Anthony Petrov wrote: >>>> Hi Oleg, >>>> >>>> I second to Leonid: you should add a comment and explain why you >>>> expect exactly 4 (or more) events to be processed. Preferably, you >>>> should list each event to clearly understand this. >>>> >>>> A minor comment is, lines 2404 - 2407 should be moved to the nearest >>>> try{} block at line 2409. >>>> >>>> A major concern is that I'm not sure the new solution is reliable in >>>> all cases. Previously, we expected to get a notification from another >>>> process (the WM). Now we process the notification ourselves and are >>>> the owners of the selection. I don't know for sure, but suppose some >>>> xlib implementations could optimize this scenario and process events >>>> locally w/o even sending them to the X server. In which case there >>>> wouldn't be any real synchronization of the native event queue. That's >>>> why communicating with another process was an important part of this >>>> procedure. >>>> >>>> How about we try the original method first, and only if it fails, then >>>> try this workaround solution? >>>> >>>> Also, this is a very sensitive method because a lot of code relies on >>>> it. I suggest running all automatic regression tests for AWT and Swing >>>> areas to make sure we don't introduce a regression with this fix. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 09/26/2013 11:56 AM, Oleg Pekhovskiy wrote: >>>>> Hi Leonid, >>>>> >>>>> I did it mostly logically, because my fix added one more service event >>>>> (SelectionRequest), that should be excluded from the number of >>>>> dispatched native events. >>>>> IMHO, the previous number "2" should have been commented, but, that >>>>> did >>>>> not happen. >>>>> >>>>> Thanks, >>>>> Oleg >>>>> >>>>> On 25.09.2013 18:11, Leonid Romanov wrote: >>>>>> Hi, >>>>>> I'm not an expert in X11 programming, so I can't comment about the >>>>>> fix >>>>>> in general, but I think the line 2436, "return getEventNumber() - >>>>>> event_number > 3", really asks for a comment. >>>>>> >>>>>> On 9/25/2013 16:38, Oleg Pekhovskiy wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> please review the fix >>>>>>> http://cr.openjdk.java.net/~bagiras/7033533.1/ >>>>>>> for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-7033533 >>>>>>> >>>>>>> Previous implementation of XToolkit.syncNativeQueue() relied upon >>>>>>> WM_S0 atom existence and that it was owned by current window >>>>>>> manager. >>>>>>> But several WMs (like XFCE and LXDE) don't send SelectionNotify >>>>>>> event >>>>>>> to the client on XConvertSelection() for that atom. That led >>>>>>> XToolkit.syncNativeQueue() to hang until TimeOutException. >>>>>>> >>>>>>> I decided to keep XConvertSelection() usage, but make root toolkit >>>>>>> window as an owner for selection atom (with another name), and >>>>>>> handle >>>>>>> SelectionRequest event from X Server, sending SelectionNotify in >>>>>>> response (as window manager is supposed to do). >>>>>>> >>>>>>> Tested on both XFCE and LXDE. >>>>>>> >>>>>>> Thanks, >>>>>>> Oleg >>>>>> >>> >> > From alexandr.scherbatiy at oracle.com Fri Oct 4 09:03:24 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 04 Oct 2013 20:03:24 +0400 Subject: [8] Review request for 8020688: broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. In-Reply-To: <524D4808.2060901@oracle.com> References: <52433994.1090403@oracle.com> <5243635C.7070007@oracle.com> <52454506.8090500@oracle.com> <52457F15.7090501@oracle.com> <52459263.7040704@oracle.com> <524593EB.2010600@oracle.com> <524596A8.2040700@oracle.com> <5245A508.4040707@oracle.com> <524B12B6.3060803@oracle.com> <524D4808.2060901@oracle.com> Message-ID: <524EE6CC.5050701@oracle.com> The fix looks good for me. Thanks, Alexandr. On 10/3/2013 2:33 PM, mikhail cherkasov wrote: > Hi Anthony, Alexandr, > > Do you approve the latest version? > > Thanks, > Mikhail. > > On 01.10.2013 22:21, Anthony Petrov wrote: >> Hi Mikhail, >> >> This "Advanced JList Programming" article seems to vanish, indeed. >> Although there's a copy at: >> >> http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/tech_topics/jlist_1/jlist.html >> >> >> but generally we shouldn't refer to 3rd-party web-sites from our >> specification. I briefly looked into the copy, and I think that >> referring to the Swing tutorial should be just fine as a replacement >> for this article. >> >> -- >> best regards, >> Anthony >> >> On 09/27/2013 07:32 PM, mikhail cherkasov wrote: >>> Anthony thank you for this link, it's good replacement for removed >>> link. >>> >>> Also I didn't find replacement for : >>> - * Also see the article >> href="http://java.sun.com/products/jfc/tsc/tech_topics/jlist_1/jlist.html">Advanced >>> >>> JList Programming >>> - * in The Swing >>> Connection. >>> >>> Do you have any suggestion about this link? the link to swing tutorial >>> already are there: >>> http://docs.oracle.com/javase/tutorial/uiswing/components/list.html >>> >>> Thanks, >>> Mikhail. >>> >>> On 27.09.2013 18:31, Anthony Petrov wrote: >>>> On 09/27/2013 06:19 PM, mikhail cherkasov wrote: >>>>> Anthony, some links, like this one, we lost for ever. >>>> >>>> How about >>>> http://docs.oracle.com/javase/tutorial/uiswing/events/actionlistener.html >>>> >>>> ? >>>> >>>> >>>>> On 27.09.2013 18:12, Anthony Petrov wrote: >>>>>> Thanks. I skimmed through the changes and they look good >>>>>> generally. A >>>>>> couple of nits: >>>>>> >>>>>> src/share/classes/java/awt/event/ActionListener.java >>>>>>> - * @see >>>>>> href="http://java.sun.com/docs/books/tutorial/post1.0/ui/eventmodel.html">Tutorial: >>>>>>> >>>>>>> >>>>>>> Java 1.1 Event Model >>>>>> >>>>>> You're only removing the link here. You should add a new one, too, I >>>>>> guess. >>>>>> >>>>>> >>>>>> src/share/classes/sun/text/normalizer/UCharacter.java >>>>>>> - * >>>>>> href="http://java.sun.com/j2se/1.5/docs/api/java/lang/Character.html"> >>>>>>> >>>>>>> + * >>>>>> href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Character.html"> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * java.lang.Character class. These extensions provide support >>>>>>> for >>>>>> >>>>>> I believe the here should be replaced with a usual javadoc's >>>>>> {@link ...} kind of thing. >>>>> Agree, and this should be done in all places, but this will be too >>>>> much >>>>> changes for this fix. >>>> >>>> Certainly, we shouldn't change all and every occurrence of this. >>>> However, this line is updated in your fix anyway, so why not apply the >>>> correct pattern just for this particular case now? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 09/27/2013 04:50 PM, mikhail cherkasov wrote: >>>>>>> Hi Anthony, >>>>>>> >>>>>>> Please review a new version: >>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.02/ >>>>>>> >>>>>>> I rely on http redirect, but it doesn't always work correctly. >>>>>>> Now I >>>>>>> re-checked all links. >>>>>>> >>>>>>> Thanks, >>>>>>> Mikhail. >>>>>>> >>>>>>> On 27.09.2013 12:42, Anthony Petrov wrote: >>>>>>>> Hi Mikhail, >>>>>>>> >>>>>>>> Please comment on the following: >>>>>>>> >>>>>>>> src/share/classes/java/awt/Component.java: >>>>>>>>> - * >>>>>>>> href="http://java.sun.com/products/jfc/tsc/articles/painting/index.html">Painting >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> in AWT and Swing. >>>>>>>>> + * >>>>>>>> href="http://www.oracle.com/technetwork/java/index.html">Painting >>>>>>>>> in >>>>>>>>> AWT and Swing. >>>>>>>> >>>>>>>> The new link doesn't point to the "Painting..." article (and it >>>>>>>> is a >>>>>>>> very good article, btw). Could you please check all the new >>>>>>>> links and >>>>>>>> update the webrev? >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 09/26/2013 02:27 AM, mikhail cherkasov wrote: >>>>>>>>> a new webrev: >>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.01/ >>>>>>>>> >>>>>>>>> no changes, I've turned off laptop before the webrev upload was >>>>>>>>> complete, so >>>>>>>>> the first could be corrupted. >>>>>>>>> >>>>>>>>> On 25.09.2013 23:29, mikhail cherkasov wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Could you please review the fix for the following bug: >>>>>>>>>> 8020688: broken links in documentation at >>>>>>>>>> http://docs.oracle.com/javase/6/docs/api/index. >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020688 >>>>>>>>>> The webrev: >>>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Mikhail. >>>>>>>>> >>>>>>> >>>>> >>> > From mikhail.cherkasov at oracle.com Fri Oct 4 09:15:38 2013 From: mikhail.cherkasov at oracle.com (mikhail.cherkasov at oracle.com) Date: Fri, 04 Oct 2013 16:15:38 +0000 Subject: hg: jdk8/awt/jdk: 8020688: Broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. Message-ID: <20131004161618.3799C62D7C@hg.openjdk.java.net> Changeset: 6ffe50fe06bd Author: mcherkas Date: 2013-10-04 20:13 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6ffe50fe06bd 8020688: Broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. Reviewed-by: anthony, alexsch ! src/macosx/classes/apple/applescript/AppleScriptEngine.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java ! src/share/classes/java/applet/Applet.java ! src/share/classes/java/applet/AppletStub.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/DefaultFocusTraversalPolicy.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/DisplayMode.java ! src/share/classes/java/awt/FocusTraversalPolicy.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/datatransfer/Transferable.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/ActionListener.java ! src/share/classes/java/awt/event/ComponentAdapter.java ! src/share/classes/java/awt/event/ComponentEvent.java ! src/share/classes/java/awt/event/ComponentListener.java ! src/share/classes/java/awt/event/ContainerAdapter.java ! src/share/classes/java/awt/event/ContainerEvent.java ! src/share/classes/java/awt/event/ContainerListener.java ! src/share/classes/java/awt/event/FocusAdapter.java ! src/share/classes/java/awt/event/FocusEvent.java ! src/share/classes/java/awt/event/FocusListener.java ! src/share/classes/java/awt/event/ItemEvent.java ! src/share/classes/java/awt/event/ItemListener.java ! src/share/classes/java/awt/event/KeyAdapter.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/java/awt/event/MouseAdapter.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/event/MouseListener.java ! src/share/classes/java/awt/event/MouseMotionAdapter.java ! src/share/classes/java/awt/event/MouseMotionListener.java ! src/share/classes/java/awt/event/WindowAdapter.java ! src/share/classes/java/awt/event/WindowEvent.java ! src/share/classes/java/awt/event/WindowFocusListener.java ! src/share/classes/java/awt/event/WindowListener.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/BorderFactory.java ! src/share/classes/javax/swing/BoundedRangeModel.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/DefaultFocusManager.java ! src/share/classes/javax/swing/FocusManager.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JCheckBox.java ! src/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JProgressBar.java ! src/share/classes/javax/swing/JRadioButton.java ! src/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/JToolBar.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/ProgressMonitorInputStream.java ! src/share/classes/javax/swing/Spring.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/WindowConstants.java ! src/share/classes/javax/swing/border/Border.java ! src/share/classes/javax/swing/event/InternalFrameAdapter.java ! src/share/classes/javax/swing/event/InternalFrameEvent.java ! src/share/classes/javax/swing/event/InternalFrameListener.java ! src/share/classes/javax/swing/event/TreeExpansionEvent.java ! src/share/classes/javax/swing/event/TreeExpansionListener.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/event/TreeModelListener.java ! src/share/classes/javax/swing/event/TreeSelectionListener.java ! src/share/classes/javax/swing/event/TreeWillExpandListener.java ! src/share/classes/javax/swing/filechooser/FileFilter.java ! src/share/classes/javax/swing/filechooser/FileView.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/table/TableModel.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/ExpandVetoException.java ! src/share/classes/javax/swing/tree/TreeCellRenderer.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/tree/TreeNode.java ! src/share/classes/javax/swing/tree/TreePath.java ! src/share/classes/javax/swing/tree/TreeSelectionModel.java ! src/share/classes/sun/swing/PrintingStatus.java ! src/share/classes/sun/text/normalizer/UCharacter.java ! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java From oleg.pekhovskiy at oracle.com Fri Oct 4 10:08:51 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 04 Oct 2013 21:08:51 +0400 Subject: [8] Review request for 7199196: Incremental transfer is broken because of a typo Message-ID: <524EF623.7040107@oracle.com> Hi all, please review the fix http://cr.openjdk.java.net/~bagiras/7199196.1/ for https://bugs.openjdk.java.net/browse/JDK-7199196 Just a typo fix. Thanks, Oleg From christine.lu at oracle.com Fri Oct 4 17:08:14 2013 From: christine.lu at oracle.com (christine.lu at oracle.com) Date: Fri, 04 Oct 2013 17:08:14 -0700 Subject: Review request for JDK-8025840: Fix all the doclint warnings about trademark Message-ID: <524F586E.6070401@oracle.com> Hi, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8025840 Fix all the doclint warnings about trademark webrev: http://cr.openjdk.java.net/~cl/8025840/webrev.00/ Thanks Christine From jiaz at jdownloader.org Sat Oct 5 07:42:56 2013 From: jiaz at jdownloader.org (Jiaz) Date: Sat, 05 Oct 2013 16:42:56 +0200 Subject: Bug 7107490 affecting JDK7 and JDK8, Bugfix included In-Reply-To: <524EB503.2050504@oracle.com> References: <5242BF1B.3080206@jdownloader.org> <524E988C.9040202@oracle.com> <524EAA46.2010703@oracle.com> <524EB017.8050407@oracle.com> <524EB503.2050504@oracle.com> Message-ID: <52502570.2030203@jdownloader.org> Hi, thanks for the commit/fix. Any chance we will see a fix for jdk7 as well? Just for your information, I've visited openjdk irc and asked for help how to proceed cause I thought no-one cared about this issue. Together we created a reproducer and a patch. See http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1571 Thanks again for your help! Greetings Daniel (JDownloader) From oleg.pekhovskiy at oracle.com Mon Oct 7 03:17:10 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Mon, 07 Oct 2013 14:17:10 +0400 Subject: [8] Review request for 8016356: Any swing frame resizes ugly. In-Reply-To: <5222DF79.4080007@oracle.com> References: <5219FB56.6070700@oracle.com> <521B5619.7030705@oracle.com> <521D1BAE.2050908@oracle.com> <521F49C3.2040703@oracle.com> <5222DF79.4080007@oracle.com> Message-ID: <52528A26.1050006@oracle.com> Hi All, Please review the second version of fix http://cr.openjdk.java.net/~bagiras/8016356.2/ for http://bugs.sun.com/view_bug.do?bug_id=8016356 I found quite robust way to determine Windows Snap-feature that relies upon the difference between the real (GetWindowRect()) and the normal placement of the window (GetWindowPlacement()). When a window goes snapped the actual and normal rectangles are different. In this case WindowResized() method is called to send ComponentResized event and update window layout. This check was placed in the handler of WM_SYSCOMMAND message right after SIZE-MOVE loop that works inside AwtWindow::DefWindowProc(). Thanks, Oleg On 01.09.2013 10:32, Oleg Pekhovskiy wrote: > Hi Anthony, > > On 29.08.2013 17:16, Anthony Petrov wrote: >> Hi Oleg, >> >> On 08/28/13 01:35, Oleg Pekhovskiy wrote: >>> On 26.08.2013 17:20, Anthony Petrov wrote: >>>> The fix looks somewhat fragile to me. The sequence of events may change >>>> in a future version of Windows, and the fix will fail then. >>> >>> I agree, the fix is not elegant. >>> As for the future: I tested it on Windows 8.1 - it worked. >> >> I didn't mean *the* Win 8.1, I meant *a* future version. I suppose you >> can't test with Win 9 or Win 19 yet, can you? :) >> > > Sure, no guarantee... > >> >>>> Are there any peculiarities for the WM_SIZE messages being posted >>>> when a >>>> window is snapped? I'm referring to [1] for example, and they suggest >>>> that a proper SC_ flag might be specified when snapping occurs. So, if >>>> we could detect that, we might unblock the WindowResized() call at the >>>> end of the WmSize() method in the AwtWindow class, which would fix the >>>> issue. >>> >>> Unfortunately there is not direct way to determine the snapping. >>> My experience says not to play with sending system events manually on >>> Windows. That is much more fragile and nobody knows how DefWindowProc() >>> would behave. >> >> I totally agree. >> >>> I chose WM_SYSCOMMAND handler in AwtWindow::WindowProc() because it's >>> synchronous during window resize (looping in AwtWindow::DefWindowProc()) >>> So WindowResized() would be called only when the user releases mouse >>> button after resizing. But WM_SIZE message is called each time the size >>> of the window is changed while resizing. >> >> Aren't the position/size of a window change noticeably greater from one >> WM_SIZE message to the next one when the snapping occurs, as opposed to >> normal resizing? Could we introduce a threshold and only call >> WindowResized from WmSize() if the size/position change is greater than >> the threshold? > > Unfortunately, that's impossible in, at least, to cases: > 1. The height of window is near the height of desktop, so snapping > increases the height of window just for a few pixels. > 2. The mouse is moved quite fast during the simple resizing (I got >100 > pixel increase for one WM_SIZE message). > >> >> I realize that such a solution is no more elegant than your original >> one, but at least it doesn't rely on a particular sequence of different >> messages, which may change in future versions of Windows. >> >> -- >> best regards, >> Anthony >> >>> >>> You might also want to explore the WM_WINDOWPOSCHANGED and >>>> WM_WINDOWPOSCHANGING events that the window receives during snapping, >>>> perhaps they have some characteristics allowing us to ignore the >>>> IsResizing() and call the WindowResized() nonetheless. >>> >>> These messages are sent "as a result of a call to the SetWindowPos >>> function or another window-management function" and never appears during >>> window resizing with the mouse. >>> >>>> >>>> [1] >>>> http://stackoverflow.com/questions/9321549/handling-aerosnap-message-in-wndproc >>>> >>>> >>>> >>>> >>> >>> This article is an attempt to handle maximize/restore snapping, but this >>> issue deals with vertical snapping, when top or bottom edge of the >>> window moved to the corresponding edge of the screen. >>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 08/25/13 16:40, Oleg Pekhovskiy wrote: >>>>> Hi all, >>>>> >>>>> please review the fix >>>>> http://cr.openjdk.java.net/~bagiras/8016356.1/ >>>>> for >>>>> http://bugs.sun.com/view_bug.do?bug_id=8016356 >>>>> >>>>> Windows 7 has a feature that makes "window being automatically >>>>> arranged >>>>> when moved to the edge of the screen". And there is no specific system >>>>> notification when that happens. From the other side AwtWindow class >>>>> has >>>>> some optimization algorithm for resizing that doesn't take into >>>>> account >>>>> such the arranging. I found indirect way to determine the arranging by >>>>> tracking the sequence of WM_GETMINMAXINFO and WM_SIZE before the >>>>> end of >>>>> resizing routine, and call WindowResized() when needed to update the >>>>> layout. >>>>> >>>>> Thanks, >>>>> Oleg From artem.ananiev at oracle.com Mon Oct 7 04:25:46 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 07 Oct 2013 15:25:46 +0400 Subject: Review request for JDK-8025840: Fix all the doclint warnings about trademark In-Reply-To: <524F586E.6070401@oracle.com> References: <524F586E.6070401@oracle.com> Message-ID: <52529A3A.6080808@oracle.com> Hi, Christine, trademark changes look fine. What's wrong with the table in BoxLayout.java? Were there any warnings reported about it? Thanks, Artem On 10/5/2013 4:08 AM, christine.lu at oracle.com wrote: > Hi, > > Please review a fix for > > https://bugs.openjdk.java.net/browse/JDK-8025840 > Fix all the doclint warnings about trademark > > webrev: http://cr.openjdk.java.net/~cl/8025840/webrev.00/ > > Thanks > Christine > From artem.ananiev at oracle.com Mon Oct 7 05:02:15 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 07 Oct 2013 16:02:15 +0400 Subject: [8] Review request for 8016356: Any swing frame resizes ugly. In-Reply-To: <52528A26.1050006@oracle.com> References: <5219FB56.6070700@oracle.com> <521B5619.7030705@oracle.com> <521D1BAE.2050908@oracle.com> <521F49C3.2040703@oracle.com> <5222DF79.4080007@oracle.com> <52528A26.1050006@oracle.com> Message-ID: <5252A2C7.3080700@oracle.com> Hi, Oleg, could you provide information (here and in bug comments), what are the values returned by GetWindowRect() and getWindowPlacement(), while the window is being snapped and after it has been snapped, please? Thanks, Artem On 10/7/2013 2:17 PM, Oleg Pekhovskiy wrote: > Hi All, > > Please review the second version of fix > http://cr.openjdk.java.net/~bagiras/8016356.2/ > for > http://bugs.sun.com/view_bug.do?bug_id=8016356 > > I found quite robust way to determine Windows Snap-feature that relies > upon the difference between the real (GetWindowRect()) and the normal > placement of the window (GetWindowPlacement()). > When a window goes snapped the actual and normal rectangles are > different. In this case WindowResized() method is called to send > ComponentResized event and update window layout. > > This check was placed in the handler of WM_SYSCOMMAND message right > after SIZE-MOVE loop that works inside AwtWindow::DefWindowProc(). > > Thanks, > Oleg > > > On 01.09.2013 10:32, Oleg Pekhovskiy wrote: >> Hi Anthony, >> >> On 29.08.2013 17:16, Anthony Petrov wrote: >>> Hi Oleg, >>> >>> On 08/28/13 01:35, Oleg Pekhovskiy wrote: >>>> On 26.08.2013 17:20, Anthony Petrov wrote: >>>>> The fix looks somewhat fragile to me. The sequence of events may >>>>> change >>>>> in a future version of Windows, and the fix will fail then. >>>> >>>> I agree, the fix is not elegant. >>>> As for the future: I tested it on Windows 8.1 - it worked. >>> >>> I didn't mean *the* Win 8.1, I meant *a* future version. I suppose you >>> can't test with Win 9 or Win 19 yet, can you? :) >>> >> >> Sure, no guarantee... >> >>> >>>>> Are there any peculiarities for the WM_SIZE messages being posted >>>>> when a >>>>> window is snapped? I'm referring to [1] for example, and they suggest >>>>> that a proper SC_ flag might be specified when snapping occurs. So, if >>>>> we could detect that, we might unblock the WindowResized() call at the >>>>> end of the WmSize() method in the AwtWindow class, which would fix the >>>>> issue. >>>> >>>> Unfortunately there is not direct way to determine the snapping. >>>> My experience says not to play with sending system events manually on >>>> Windows. That is much more fragile and nobody knows how DefWindowProc() >>>> would behave. >>> >>> I totally agree. >>> >>>> I chose WM_SYSCOMMAND handler in AwtWindow::WindowProc() because it's >>>> synchronous during window resize (looping in >>>> AwtWindow::DefWindowProc()) >>>> So WindowResized() would be called only when the user releases mouse >>>> button after resizing. But WM_SIZE message is called each time the size >>>> of the window is changed while resizing. >>> >>> Aren't the position/size of a window change noticeably greater from one >>> WM_SIZE message to the next one when the snapping occurs, as opposed to >>> normal resizing? Could we introduce a threshold and only call >>> WindowResized from WmSize() if the size/position change is greater than >>> the threshold? >> >> Unfortunately, that's impossible in, at least, to cases: >> 1. The height of window is near the height of desktop, so snapping >> increases the height of window just for a few pixels. >> 2. The mouse is moved quite fast during the simple resizing (I got >100 >> pixel increase for one WM_SIZE message). >> >>> >>> I realize that such a solution is no more elegant than your original >>> one, but at least it doesn't rely on a particular sequence of different >>> messages, which may change in future versions of Windows. >>> >>> -- >>> best regards, >>> Anthony >>> >>>> >>>> You might also want to explore the WM_WINDOWPOSCHANGED and >>>>> WM_WINDOWPOSCHANGING events that the window receives during snapping, >>>>> perhaps they have some characteristics allowing us to ignore the >>>>> IsResizing() and call the WindowResized() nonetheless. >>>> >>>> These messages are sent "as a result of a call to the SetWindowPos >>>> function or another window-management function" and never appears >>>> during >>>> window resizing with the mouse. >>>> >>>>> >>>>> [1] >>>>> http://stackoverflow.com/questions/9321549/handling-aerosnap-message-in-wndproc >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> This article is an attempt to handle maximize/restore snapping, but >>>> this >>>> issue deals with vertical snapping, when top or bottom edge of the >>>> window moved to the corresponding edge of the screen. >>>> >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 08/25/13 16:40, Oleg Pekhovskiy wrote: >>>>>> Hi all, >>>>>> >>>>>> please review the fix >>>>>> http://cr.openjdk.java.net/~bagiras/8016356.1/ >>>>>> for >>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016356 >>>>>> >>>>>> Windows 7 has a feature that makes "window being automatically >>>>>> arranged >>>>>> when moved to the edge of the screen". And there is no specific >>>>>> system >>>>>> notification when that happens. From the other side AwtWindow class >>>>>> has >>>>>> some optimization algorithm for resizing that doesn't take into >>>>>> account >>>>>> such the arranging. I found indirect way to determine the >>>>>> arranging by >>>>>> tracking the sequence of WM_GETMINMAXINFO and WM_SIZE before the >>>>>> end of >>>>>> resizing routine, and call WindowResized() when needed to update the >>>>>> layout. >>>>>> >>>>>> Thanks, >>>>>> Oleg From alexandr.scherbatiy at oracle.com Mon Oct 7 05:13:44 2013 From: alexandr.scherbatiy at oracle.com (alexandr.scherbatiy at oracle.com) Date: Mon, 07 Oct 2013 12:13:44 +0000 Subject: hg: jdk8/awt/jdk: 8025438: [macosx] right JNFCall* method should be used in JDK-8008728 fix Message-ID: <20131007121439.9B81262DFC@hg.openjdk.java.net> Changeset: 01b40315f872 Author: alexsch Date: 2013-10-07 16:13 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/01b40315f872 8025438: [macosx] right JNFCall* method should be used in JDK-8008728 fix Reviewed-by: serb, anthony ! src/macosx/native/sun/awt/AWTWindow.m From alexandr.scherbatiy at oracle.com Mon Oct 7 05:45:48 2013 From: alexandr.scherbatiy at oracle.com (alexandr.scherbatiy at oracle.com) Date: Mon, 07 Oct 2013 12:45:48 +0000 Subject: hg: jdk8/awt/jdk: 8007219: [macosx] Frame size reverts meaning of maximized attribute if frame size close to display Message-ID: <20131007124616.E49BA62DFD@hg.openjdk.java.net> Changeset: 72afa269fa3b Author: alexsch Date: 2013-10-07 16:42 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/72afa269fa3b 8007219: [macosx] Frame size reverts meaning of maximized attribute if frame size close to display Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/native/sun/awt/CWrapper.m + test/java/awt/Frame/MaximizedToMaximized/MaximizedToMaximized.java From anthony.petrov at oracle.com Mon Oct 7 06:57:32 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 07 Oct 2013 17:57:32 +0400 Subject: [8] Review request for 7199196: Incremental transfer is broken because of a typo In-Reply-To: <524EF623.7040107@oracle.com> References: <524EF623.7040107@oracle.com> Message-ID: <5252BDCC.2040505@oracle.com> Looks fine. -- best regards, Anthony On 10/04/13 21:08, Oleg Pekhovskiy wrote: > Hi all, > > please review the fix > http://cr.openjdk.java.net/~bagiras/7199196.1/ > for > https://bugs.openjdk.java.net/browse/JDK-7199196 > > Just a typo fix. > > Thanks, > Oleg From artem.ananiev at oracle.com Mon Oct 7 07:03:42 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 07 Oct 2013 18:03:42 +0400 Subject: [8] Request for review: 8025603 Unused methods in the awt text peers should be removed In-Reply-To: <524C682F.3060006@oracle.com> References: <524C682F.3060006@oracle.com> Message-ID: <5252BF3E.8020105@oracle.com> Hi, Sergey, the changes look fine. Could you also remove deprecated methods in WTextArea, e.g. insertText(), since you touch these files anyway, please? Thanks, Artem On 10/2/2013 10:38 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk 8. This is a code cleanup. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8025603 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8025603/webrev.00 > From artem.ananiev at oracle.com Mon Oct 7 07:36:46 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 07 Oct 2013 18:36:46 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524EA896.8070603@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> <524C0411.7060709@oracle.com> <524C110F.6000905@oracle.com> <524C11EF.2040905@oracle.com> <524C13B2.2020700@oracle.com> <524C1A79.6030101@oracle.com> <524E9C39.7090403@oracle.com> <524E9F18.9060003@oracle.com> <524EA896.8070603@oracle.com> Message-ID: <5252C6FE.3050201@oracle.com> On 10/4/2013 3:37 PM, Anthony Petrov wrote: > On 10/04/2013 02:57 PM, Artem Ananiev wrote: >> On 10/4/2013 2:45 PM, Anthony Petrov wrote: >>> On 10/02/2013 05:07 PM, Artem Ananiev wrote: >>>>>> You're right, it's not necessary. However, since we touch this code >>>>>> anyway, I'd be glad to have this redundant code removed. >>>>> >>>>> It's not redundant. Please see my message below in the quote for >>>>> details. >>>> >>>> Do you mean the following quote: >>>> >>>>>>>>> However, your fix effectively disallows a component to belong to >>>>>>>>> any >>>>>>>>> toolkit other than the default one, because its getToolkit() will >>>>>>>>> never return anything else (unless you extend the component's >>>>>>>>> class >>>>>>>>> and override the method). >>>> >>>> ? Extending the Component class and providing different implementation >>>> for getToolkit() is the way to achieve this functionality. Without this >>>> extension, it doesn't matter if Component.getToolkit() calls to the >>>> peer >>>> or directly returns the default toolkit. >>> >>> I can't say I fully agree with that. When using the default toolkit, you >>> don't need to extend public AWT classes. I don't see why you would have >>> to do that when using a custom toolkit. >> >> Sorry, I still don't get it... To me it looks like we don't change >> anything. The current behavior is preserved, Component.getToolkit() >> returns the default toolkit. Ability to extend the Component class and >> change getToolkit() is not affected. All the weird cases like >> co-existence of two different toolkits in the same process, or component >> peers that are not created by the current toolkit, etc. are not worth >> thinking about to me. >> >> Could you provide a sample, which works with the current implementation >> and won't work after the proposed fix, please? > > No, unfortunately I don't have a working sample. I'm only considering a > theoretical possibility of several toolkits co-existing in a single VM. > I looked over the addNotify() implementation and see that it relies upon > the getToolkit() method. So indeed, w/o overriding it you can't > construct an AWT widget using a 3rd-party toolkit. OTOH, such a toolkit > might provide a factory method for components, and set its peer field > before returning the component instance to the app (w/o actually > extending the class). This case would break with the current fix. > > Also, w/o clear understanding of the reason why the > ComponentPeer.getToolkit() and the corresponding logic in > Component.getToolkit() were introduced in the first place, it looks kind > of scary to just drop this method so late in the JDK8 release cycle. > > Since this part of the fix isn't mandatory for the specification change, > I still suggest to file a separate issue and investigate it later > because it doesn't seem urgent (as opposed to the spec change itself.) Based on my past experience, I would bet such a separate issue will never be fixed/implemented. So I still believe this redundant method in the ComponentPeer interface should be removed as a part of this fix. As a summary, what we have now. On one hand, the fix is useful (redundant code is removed) and doesn't change the current behavior. I don't see why it's considered scary... On the other hand, possibility to have multiple AWT toolkits in a single VM is pure theoretical. De-facto it hasn't been supported for years. It is possible to create your own Toolkit, but all the AWT/Swing code will use the default toolkit anyway. Thanks, Artem > -- > best regards, > Anthony > >> >> Thanks, >> >> Artem >> >>> Can we file a separate P4 issue to evaluate this later, and only change >>> the specification with 7081584 ? >>> >>> -- >>> best regards, >>> Anthony >>> >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> SAM >>>>>>>> >>>>>>>> On 01.10.2013 21:47, Anthony Petrov wrote: >>>>>>>>> Hi Sergey, >>>>>>>>> >>>>>>>>> I'm wondering what compatibility impact of this change is. The >>>>>>>>> specification for Component.getToolkit() suggests that in theory >>>>>>>>> several toolkits may co-exist in a single application. And >>>>>>>>> thanks to >>>>>>>>> delegating to the ComponentPeer, the Component.getToolkit() could >>>>>>>>> return the actual toolkit for this component. >>>>>>>>> >>>>>>>>> However, your fix effectively disallows a component to belong to >>>>>>>>> any >>>>>>>>> toolkit other than the default one, because its getToolkit() will >>>>>>>>> never return anything else (unless you extend the component's >>>>>>>>> class >>>>>>>>> and override the method). >>>>>>>>> >>>>>>>>> I really don't know whether this is widely used, but I think this >>>>>>>>> may >>>>>>>>> impact some applications. >>>>>>>>> >>>>>>>>> Also, imagine a window is made to belong to another toolkit >>>>>>>>> somehow, >>>>>>>>> even with your changes. Now, why should its ability to be >>>>>>>>> always-on-top depend on the default toolkit instead of the >>>>>>>>> window's >>>>>>>>> own toolkit? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> best regards, >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>> On 09/27/2013 08:49 PM, sergey malenkov wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you please review the following fix: >>>>>>>>>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >>>>>>>>>> >>>>>>>>>> The specification of the Window class waits for CCC approval. >>>>>>>>>> This >>>>>>>>>> fix >>>>>>>>>> removes the getTookit method from the ComponentPeer class and its >>>>>>>>>> subclasses. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> SAM >>>>>>>>>> >>>>>>>> From Sergey.Bylokhov at oracle.com Mon Oct 7 08:19:49 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 07 Oct 2013 19:19:49 +0400 Subject: [8] Request for review: 8025603 Unused methods in the awt text peers should be removed In-Reply-To: <5252BF3E.8020105@oracle.com> References: <524C682F.3060006@oracle.com> <5252BF3E.8020105@oracle.com> Message-ID: <5252D115.1040109@oracle.com> Hi, Artem. Thanks for review. Updated version: http://cr.openjdk.java.net/~serb/8025603/webrev.01 WComponentPeer.minimumSize also removed, because it is never used in java or in native. On 07.10.2013 18:03, Artem Ananiev wrote: > Hi, Sergey, > > the changes look fine. > > Could you also remove deprecated methods in WTextArea, e.g. > insertText(), since you touch these files anyway, please? > > Thanks, > > Artem > > On 10/2/2013 10:38 PM, Sergey Bylokhov wrote: >> Hello, >> Please review the fix for jdk 8. This is a code cleanup. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8025603 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8025603/webrev.00 >> -- Best regards, Sergey. From artem.ananiev at oracle.com Mon Oct 7 10:06:52 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 07 Oct 2013 21:06:52 +0400 Subject: [8] Request for review: 8025603 Unused methods in the awt text peers should be removed In-Reply-To: <5252D115.1040109@oracle.com> References: <524C682F.3060006@oracle.com> <5252BF3E.8020105@oracle.com> <5252D115.1040109@oracle.com> Message-ID: <5252EA2C.2010702@oracle.com> Nice cleanup, now looks fine. Let us see what will be broken, as it usually happens with most of cleanups :) Thanks, Artem On 10/7/2013 7:19 PM, Sergey Bylokhov wrote: > Hi, Artem. > Thanks for review. > Updated version: > http://cr.openjdk.java.net/~serb/8025603/webrev.01 > > WComponentPeer.minimumSize also removed, because it is never used in > java or in native. > > On 07.10.2013 18:03, Artem Ananiev wrote: >> Hi, Sergey, >> >> the changes look fine. >> >> Could you also remove deprecated methods in WTextArea, e.g. >> insertText(), since you touch these files anyway, please? >> >> Thanks, >> >> Artem >> >> On 10/2/2013 10:38 PM, Sergey Bylokhov wrote: >>> Hello, >>> Please review the fix for jdk 8. This is a code cleanup. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025603 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8025603/webrev.00 >>> > > From Sergey.Bylokhov at oracle.com Mon Oct 7 10:15:04 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 07 Oct 2013 21:15:04 +0400 Subject: [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified In-Reply-To: <524EA896.8070603@oracle.com> References: <5245B70D.4070507@oracle.com> <524B0ACA.2060708@oracle.com> <524C0411.7060709@oracle.com> <524C110F.6000905@oracle.com> <524C11EF.2040905@oracle.com> <524C13B2.2020700@oracle.com> <524C1A79.6030101@oracle.com> <524E9C39.7090403@oracle.com> <524E9F18.9060003@oracle.com> <524EA896.8070603@oracle.com> Message-ID: <5252EC18.5020405@oracle.com> Hello. I agree that it is a good time to make cleanup of all strange code that we have. We will have enough time to catch regression. On 04.10.2013 15:37, Anthony Petrov wrote: > On 10/04/2013 02:57 PM, Artem Ananiev wrote: >> On 10/4/2013 2:45 PM, Anthony Petrov wrote: >>> On 10/02/2013 05:07 PM, Artem Ananiev wrote: >>>>>> You're right, it's not necessary. However, since we touch this code >>>>>> anyway, I'd be glad to have this redundant code removed. >>>>> >>>>> It's not redundant. Please see my message below in the quote for >>>>> details. >>>> >>>> Do you mean the following quote: >>>> >>>>>>>>> However, your fix effectively disallows a component to belong to >>>>>>>>> any >>>>>>>>> toolkit other than the default one, because its getToolkit() will >>>>>>>>> never return anything else (unless you extend the component's >>>>>>>>> class >>>>>>>>> and override the method). >>>> >>>> ? Extending the Component class and providing different implementation >>>> for getToolkit() is the way to achieve this functionality. Without >>>> this >>>> extension, it doesn't matter if Component.getToolkit() calls to the >>>> peer >>>> or directly returns the default toolkit. >>> >>> I can't say I fully agree with that. When using the default toolkit, >>> you >>> don't need to extend public AWT classes. I don't see why you would have >>> to do that when using a custom toolkit. >> >> Sorry, I still don't get it... To me it looks like we don't change >> anything. The current behavior is preserved, Component.getToolkit() >> returns the default toolkit. Ability to extend the Component class and >> change getToolkit() is not affected. All the weird cases like >> co-existence of two different toolkits in the same process, or component >> peers that are not created by the current toolkit, etc. are not worth >> thinking about to me. >> >> Could you provide a sample, which works with the current implementation >> and won't work after the proposed fix, please? > > No, unfortunately I don't have a working sample. I'm only considering > a theoretical possibility of several toolkits co-existing in a single > VM. I looked over the addNotify() implementation and see that it > relies upon the getToolkit() method. So indeed, w/o overriding it you > can't construct an AWT widget using a 3rd-party toolkit. OTOH, such a > toolkit might provide a factory method for components, and set its > peer field before returning the component instance to the app (w/o > actually extending the class). This case would break with the current > fix. > > Also, w/o clear understanding of the reason why the > ComponentPeer.getToolkit() and the corresponding logic in > Component.getToolkit() were introduced in the first place, it looks > kind of scary to just drop this method so late in the JDK8 release cycle. > > Since this part of the fix isn't mandatory for the specification > change, I still suggest to file a separate issue and investigate it > later because it doesn't seem urgent (as opposed to the spec change > itself.) > > -- > best regards, > Anthony > >> >> Thanks, >> >> Artem >> >>> Can we file a separate P4 issue to evaluate this later, and only change >>> the specification with 7081584 ? >>> >>> -- >>> best regards, >>> Anthony >>> >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> SAM >>>>>>>> >>>>>>>> On 01.10.2013 21:47, Anthony Petrov wrote: >>>>>>>>> Hi Sergey, >>>>>>>>> >>>>>>>>> I'm wondering what compatibility impact of this change is. The >>>>>>>>> specification for Component.getToolkit() suggests that in theory >>>>>>>>> several toolkits may co-exist in a single application. And >>>>>>>>> thanks to >>>>>>>>> delegating to the ComponentPeer, the Component.getToolkit() could >>>>>>>>> return the actual toolkit for this component. >>>>>>>>> >>>>>>>>> However, your fix effectively disallows a component to belong to >>>>>>>>> any >>>>>>>>> toolkit other than the default one, because its getToolkit() will >>>>>>>>> never return anything else (unless you extend the component's >>>>>>>>> class >>>>>>>>> and override the method). >>>>>>>>> >>>>>>>>> I really don't know whether this is widely used, but I think this >>>>>>>>> may >>>>>>>>> impact some applications. >>>>>>>>> >>>>>>>>> Also, imagine a window is made to belong to another toolkit >>>>>>>>> somehow, >>>>>>>>> even with your changes. Now, why should its ability to be >>>>>>>>> always-on-top depend on the default toolkit instead of the >>>>>>>>> window's >>>>>>>>> own toolkit? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> best regards, >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>> On 09/27/2013 08:49 PM, sergey malenkov wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you please review the following fix: >>>>>>>>>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/ >>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584 >>>>>>>>>> >>>>>>>>>> The specification of the Window class waits for CCC approval. >>>>>>>>>> This >>>>>>>>>> fix >>>>>>>>>> removes the getTookit method from the ComponentPeer class and >>>>>>>>>> its >>>>>>>>>> subclasses. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> SAM >>>>>>>>>> >>>>>>>> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Oct 7 10:16:40 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 07 Oct 2013 21:16:40 +0400 Subject: [8] Review Request: 8022119 test api/javax_sound/sampled/spi/MixerProvider/indexTGF_MixerProviderTests fails Message-ID: <5252EC78.5010009@oracle.com> Hello. Please review the fix for jdk 8. ServiceLoader usage was changed according to the change in JDK-8019622 Bug: https://bugs.openjdk.java.net/browse/JDK-8022119 Webrev can be found at: http://cr.openjdk.java.net/~serb/8022119/webrev.00 -- Best regards, Sergey. From sergey.malenkov at oracle.com Mon Oct 7 10:39:47 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Mon, 07 Oct 2013 21:39:47 +0400 Subject: [8] Review request for 7172597: java.awt.KeyboardFocusManager.clearFocusOwner() missed javadoc tag @since 1.8 Message-ID: <5252F1E3.5040605@oracle.com> Hello, Could you please review the following fix: fix:http://cr.openjdk.java.net/~malenkov/7172597.8.0/ bug:https://bugs.openjdk.java.net/browse/JDK-7172597 Added missed tag @since 1.8 Thanks, SAM From christine.lu at oracle.com Mon Oct 7 11:10:06 2013 From: christine.lu at oracle.com (christine.lu at oracle.com) Date: Mon, 07 Oct 2013 11:10:06 -0700 Subject: Review request for JDK-8025840: Fix all the doclint warnings about trademark In-Reply-To: <52529A3A.6080808@oracle.com> References: <524F586E.6070401@oracle.com> <52529A3A.6080808@oracle.com> Message-ID: <5252F8FE.4050106@oracle.com> Artem, Yes, there are warnings about it, in the same report as those trademark warnings in http://rehudson.us.oracle.com:8080/hudson/job/christine/lastSuccessfulBuild/artifact/client-doclint-html/javax_swing-accessibility.txt /tmp/workspace/christine-2-solaris-i586/jdk8-awt/382/jdk/src/share/classes/javax/swing/BoxLayout.java:39: warning: attribute obsolete, use CSS instead: ALIGN * ^ /tmp/workspace/christine-2-solaris-i586/jdk8-awt/382/jdk/src/share/classes/javax/swing/BoxLayout.java:42: warning: attribute obsolete, use CSS instead: ALIGN *

Hi, Christine, > > trademark changes look fine. > > What's wrong with the table in BoxLayout.java? Were there any warnings > reported about it? > > Thanks, > > Artem > > On 10/5/2013 4:08 AM, christine.lu at oracle.com wrote: >> Hi, >> >> Please review a fix for >> >> https://bugs.openjdk.java.net/browse/JDK-8025840 >> Fix all the doclint warnings about trademark >> >> webrev: http://cr.openjdk.java.net/~cl/8025840/webrev.00/ >> >> Thanks >> Christine >> From christine.lu at oracle.com Mon Oct 7 11:35:53 2013 From: christine.lu at oracle.com (christine.lu at oracle.com) Date: Mon, 07 Oct 2013 18:35:53 +0000 Subject: hg: jdk8/awt/jdk: 8025840: Fix all the doclint warnings about trademark Message-ID: <20131007183626.00CDE62E0C@hg.openjdk.java.net> Changeset: 546c0ebfbf56 Author: cl Date: 2013-10-07 11:34 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/546c0ebfbf56 8025840: Fix all the doclint warnings about trademark Reviewed-by: art ! src/share/classes/javax/swing/AbstractAction.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/AbstractCellEditor.java ! src/share/classes/javax/swing/AbstractListModel.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/CellRendererPane.java ! src/share/classes/javax/swing/DefaultBoundedRangeModel.java ! src/share/classes/javax/swing/DefaultButtonModel.java ! src/share/classes/javax/swing/DefaultCellEditor.java ! src/share/classes/javax/swing/DefaultListCellRenderer.java ! src/share/classes/javax/swing/DefaultListModel.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/DefaultSingleSelectionModel.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JCheckBox.java ! src/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JFormattedTextField.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JProgressBar.java ! src/share/classes/javax/swing/JRadioButton.java ! src/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JScrollBar.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/JToolBar.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/KeyStroke.java ! src/share/classes/javax/swing/OverlayLayout.java ! src/share/classes/javax/swing/ScrollPaneLayout.java ! src/share/classes/javax/swing/SizeRequirements.java ! src/share/classes/javax/swing/Spring.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/UnsupportedLookAndFeelException.java ! src/share/classes/javax/swing/ViewportLayout.java ! src/share/classes/javax/swing/border/AbstractBorder.java ! src/share/classes/javax/swing/border/BevelBorder.java ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/border/EmptyBorder.java ! src/share/classes/javax/swing/border/EtchedBorder.java ! src/share/classes/javax/swing/border/LineBorder.java ! src/share/classes/javax/swing/border/MatteBorder.java ! src/share/classes/javax/swing/border/SoftBevelBorder.java ! src/share/classes/javax/swing/border/TitledBorder.java ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorChooserComponentFactory.java ! src/share/classes/javax/swing/colorchooser/DefaultPreviewPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java ! src/share/classes/javax/swing/event/AncestorEvent.java ! src/share/classes/javax/swing/event/CaretEvent.java ! src/share/classes/javax/swing/event/ChangeEvent.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/javax/swing/event/HyperlinkEvent.java ! src/share/classes/javax/swing/event/InternalFrameEvent.java ! src/share/classes/javax/swing/event/ListDataEvent.java ! src/share/classes/javax/swing/event/ListSelectionEvent.java ! src/share/classes/javax/swing/event/MenuDragMouseEvent.java ! src/share/classes/javax/swing/event/MenuEvent.java ! src/share/classes/javax/swing/event/MenuKeyEvent.java ! src/share/classes/javax/swing/event/PopupMenuEvent.java ! src/share/classes/javax/swing/event/TableColumnModelEvent.java ! src/share/classes/javax/swing/event/TableModelEvent.java ! src/share/classes/javax/swing/event/TreeExpansionEvent.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/event/TreeSelectionEvent.java ! src/share/classes/javax/swing/event/UndoableEditEvent.java ! src/share/classes/javax/swing/plaf/BorderUIResource.java ! src/share/classes/javax/swing/plaf/ColorUIResource.java ! src/share/classes/javax/swing/plaf/DimensionUIResource.java ! src/share/classes/javax/swing/plaf/FontUIResource.java ! src/share/classes/javax/swing/plaf/IconUIResource.java ! src/share/classes/javax/swing/plaf/InsetsUIResource.java ! src/share/classes/javax/swing/plaf/basic/BasicArrowButton.java ! src/share/classes/javax/swing/plaf/basic/BasicCheckBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxRenderer.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/basic/BasicEditorPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java ! src/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextFieldUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/ComboPopup.java ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/share/classes/javax/swing/plaf/metal/MetalButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxIcon.java ! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxButton.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxEditor.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalProgressBarUI.java ! src/share/classes/javax/swing/plaf/metal/MetalRadioButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollButton.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneDivider.java ! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTextFieldUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToggleButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java ! src/share/classes/javax/swing/plaf/multi/MultiLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java ! src/share/classes/javax/swing/table/AbstractTableModel.java ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java ! src/share/classes/javax/swing/table/DefaultTableColumnModel.java ! src/share/classes/javax/swing/table/DefaultTableModel.java ! src/share/classes/javax/swing/table/JTableHeader.java ! src/share/classes/javax/swing/table/TableColumn.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/BadLocationException.java ! src/share/classes/javax/swing/text/DateFormatter.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultEditorKit.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultFormatterFactory.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/SimpleAttributeSet.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/StyledEditorKit.java ! src/share/classes/javax/swing/text/TabSet.java ! src/share/classes/javax/swing/text/TabStop.java ! src/share/classes/javax/swing/text/TextAction.java ! src/share/classes/javax/swing/text/html/Option.java ! src/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/TreePath.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/swing/undo/CannotRedoException.java ! src/share/classes/javax/swing/undo/CannotUndoException.java ! src/share/classes/javax/swing/undo/UndoManager.java From christine.lu at oracle.com Mon Oct 7 18:59:50 2013 From: christine.lu at oracle.com (christine.lu at oracle.com) Date: Mon, 07 Oct 2013 18:59:50 -0700 Subject: Review request for JDK-8026021: more fix of javadoc errors and warnings reported by doclint Message-ID: <52536716.20908@oracle.com> Hi, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8026021 more fix of javadoc errors and warnings reported by doclint, see the description webrev: http://cr.openjdk.java.net/~cl/8026021/webrev.00/ Thanks Christine From Sergey.Bylokhov at oracle.com Tue Oct 8 00:01:23 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 08 Oct 2013 11:01:23 +0400 Subject: [8] Review request for 7199196: Incremental transfer is broken because of a typo In-Reply-To: <524EF623.7040107@oracle.com> References: <524EF623.7040107@oracle.com> Message-ID: <5253ADC3.9070106@oracle.com> Hi, Oleg. The fix looks good. On 04.10.2013 21:08, Oleg Pekhovskiy wrote: > Hi all, > > please review the fix > http://cr.openjdk.java.net/~bagiras/7199196.1/ > for > https://bugs.openjdk.java.net/browse/JDK-7199196 > > Just a typo fix. > > Thanks, > Oleg -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Oct 8 00:13:20 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 08 Oct 2013 11:13:20 +0400 Subject: [8] Review Request: JDK-8025236 [javadoc] fix some errors in AWT In-Reply-To: <524EC4D3.40204@oracle.com> References: <52442E3F.6000109@oracle.com> <524442D6.3030007@oracle.com> <52458D96.2090005@oracle.com> <5249821E.2030409@oracle.com> <524B111D.5000804@oracle.com> <524EC4D3.40204@oracle.com> Message-ID: <5253B090.6010901@oracle.com> Hi Dmitry, The fix looks good to me. Thanks. -- best regards, Anthony On 10/04/2013 05:38 PM, Dmitry Ginzburg wrote: > Hi Anthony > > I renewed this fix against your issues: > http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.01/ > > Thanks, > -Dmitry > > 01.10.2013 22:14, Anthony Petrov wrote: >> You should only change the issues in lines that are already >> modified in your fix. No massive reformatting please. >> >> And yes, the rest of the procedure is to publish the second version of >> the webrev, and post a link to this mailing list. >> >> -- >> best regards, >> Anthony >> >> On 09/30/2013 05:52 PM, Dmitry Ginzburg wrote: >>> So, should I fix all the issues with this ""'s, do webrev again >>> and send it to yan, and send it here again? >>> >>> Thanks, >>> >>> -Dmitry >>> >>> 27.09.2013 17:52, Anthony Petrov wrote: >>>> The fix looks good to me. Again, if possible, I'd suggest to replace >>>> with {@code ..} if you're changing a line anyway. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 09/26/2013 06:21 PM, Dmitry Ginzburg wrote: >>>>> Hello, AWT Team. >>>>> >>>>> Please review the fix for the following issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025236 >>>>> The fix is available at: >>>>> http://cr.openjdk.java.net/~yan/jdk-8025236/webrev.00/ >>>>> >>>>> This is the fix for javadoc errors, on which doclint was showing some >>>>> issues. >>>>> >>>>> The patch contains only simple markup fixes; no changes/fixes in >>>>> documentation text; the specification itself wasn't changed. >>>>> >>>>> Thanks, >>>>> -Dmitry > > From anthony.petrov at oracle.com Tue Oct 8 00:54:09 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 08 Oct 2013 11:54:09 +0400 Subject: [8] Review request for 8016356: Any swing frame resizes ugly. In-Reply-To: <52528A26.1050006@oracle.com> References: <5219FB56.6070700@oracle.com> <521B5619.7030705@oracle.com> <521D1BAE.2050908@oracle.com> <521F49C3.2040703@oracle.com> <5222DF79.4080007@oracle.com> <52528A26.1050006@oracle.com> Message-ID: <5253BA21.90107@oracle.com> Hi Oleg, Thanks for investigating this deeper and finding a better solution. This version of the fix looks fine to me. Only a minor formatting issue: please put the "else {" on the previous line (right after "} ".) No need for a new webrev with this change. And I second to Artem, please add more information to the bug report with some examples of values reported by those two WinAPI functions. -- best regards, Anthony On 10/07/2013 02:17 PM, Oleg Pekhovskiy wrote: > Hi All, > > Please review the second version of fix > http://cr.openjdk.java.net/~bagiras/8016356.2/ > for > http://bugs.sun.com/view_bug.do?bug_id=8016356 > > I found quite robust way to determine Windows Snap-feature that relies > upon the difference between the real (GetWindowRect()) and the normal > placement of the window (GetWindowPlacement()). > When a window goes snapped the actual and normal rectangles are > different. In this case WindowResized() method is called to send > ComponentResized event and update window layout. > > This check was placed in the handler of WM_SYSCOMMAND message right > after SIZE-MOVE loop that works inside AwtWindow::DefWindowProc(). > > Thanks, > Oleg > > > On 01.09.2013 10:32, Oleg Pekhovskiy wrote: >> Hi Anthony, >> >> On 29.08.2013 17:16, Anthony Petrov wrote: >>> Hi Oleg, >>> >>> On 08/28/13 01:35, Oleg Pekhovskiy wrote: >>>> On 26.08.2013 17:20, Anthony Petrov wrote: >>>>> The fix looks somewhat fragile to me. The sequence of events may >>>>> change >>>>> in a future version of Windows, and the fix will fail then. >>>> >>>> I agree, the fix is not elegant. >>>> As for the future: I tested it on Windows 8.1 - it worked. >>> >>> I didn't mean *the* Win 8.1, I meant *a* future version. I suppose you >>> can't test with Win 9 or Win 19 yet, can you? :) >>> >> >> Sure, no guarantee... >> >>> >>>>> Are there any peculiarities for the WM_SIZE messages being posted >>>>> when a >>>>> window is snapped? I'm referring to [1] for example, and they suggest >>>>> that a proper SC_ flag might be specified when snapping occurs. So, if >>>>> we could detect that, we might unblock the WindowResized() call at the >>>>> end of the WmSize() method in the AwtWindow class, which would fix the >>>>> issue. >>>> >>>> Unfortunately there is not direct way to determine the snapping. >>>> My experience says not to play with sending system events manually on >>>> Windows. That is much more fragile and nobody knows how DefWindowProc() >>>> would behave. >>> >>> I totally agree. >>> >>>> I chose WM_SYSCOMMAND handler in AwtWindow::WindowProc() because it's >>>> synchronous during window resize (looping in >>>> AwtWindow::DefWindowProc()) >>>> So WindowResized() would be called only when the user releases mouse >>>> button after resizing. But WM_SIZE message is called each time the size >>>> of the window is changed while resizing. >>> >>> Aren't the position/size of a window change noticeably greater from one >>> WM_SIZE message to the next one when the snapping occurs, as opposed to >>> normal resizing? Could we introduce a threshold and only call >>> WindowResized from WmSize() if the size/position change is greater than >>> the threshold? >> >> Unfortunately, that's impossible in, at least, to cases: >> 1. The height of window is near the height of desktop, so snapping >> increases the height of window just for a few pixels. >> 2. The mouse is moved quite fast during the simple resizing (I got >100 >> pixel increase for one WM_SIZE message). >> >>> >>> I realize that such a solution is no more elegant than your original >>> one, but at least it doesn't rely on a particular sequence of different >>> messages, which may change in future versions of Windows. >>> >>> -- >>> best regards, >>> Anthony >>> >>>> >>>> You might also want to explore the WM_WINDOWPOSCHANGED and >>>>> WM_WINDOWPOSCHANGING events that the window receives during snapping, >>>>> perhaps they have some characteristics allowing us to ignore the >>>>> IsResizing() and call the WindowResized() nonetheless. >>>> >>>> These messages are sent "as a result of a call to the SetWindowPos >>>> function or another window-management function" and never appears >>>> during >>>> window resizing with the mouse. >>>> >>>>> >>>>> [1] >>>>> http://stackoverflow.com/questions/9321549/handling-aerosnap-message-in-wndproc >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> This article is an attempt to handle maximize/restore snapping, but >>>> this >>>> issue deals with vertical snapping, when top or bottom edge of the >>>> window moved to the corresponding edge of the screen. >>>> >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 08/25/13 16:40, Oleg Pekhovskiy wrote: >>>>>> Hi all, >>>>>> >>>>>> please review the fix >>>>>> http://cr.openjdk.java.net/~bagiras/8016356.1/ >>>>>> for >>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016356 >>>>>> >>>>>> Windows 7 has a feature that makes "window being automatically >>>>>> arranged >>>>>> when moved to the edge of the screen". And there is no specific >>>>>> system >>>>>> notification when that happens. From the other side AwtWindow class >>>>>> has >>>>>> some optimization algorithm for resizing that doesn't take into >>>>>> account >>>>>> such the arranging. I found indirect way to determine the >>>>>> arranging by >>>>>> tracking the sequence of WM_GETMINMAXINFO and WM_SIZE before the >>>>>> end of >>>>>> resizing routine, and call WindowResized() when needed to update the >>>>>> layout. >>>>>> >>>>>> Thanks, >>>>>> Oleg From anthony.petrov at oracle.com Tue Oct 8 01:38:37 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 08 Oct 2013 12:38:37 +0400 Subject: [8] Review request for 7172597: java.awt.KeyboardFocusManager.clearFocusOwner() missed javadoc tag @since 1.8 In-Reply-To: <5252F1E3.5040605@oracle.com> References: <5252F1E3.5040605@oracle.com> Message-ID: <5253C48D.4000806@oracle.com> Looks fine. -- best regards, Anthony On 10/07/2013 09:39 PM, sergey malenkov wrote: > > Hello, > > Could you please review the following fix: > fix:http://cr.openjdk.java.net/~malenkov/7172597.8.0/ > bug:https://bugs.openjdk.java.net/browse/JDK-7172597 > > Added missed tag @since 1.8 > > Thanks, > SAM > From anthony.petrov at oracle.com Tue Oct 8 01:51:46 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 08 Oct 2013 12:51:46 +0400 Subject: Review request for JDK-8026021: more fix of javadoc errors and warnings reported by doclint In-Reply-To: <52536716.20908@oracle.com> References: <52536716.20908@oracle.com> Message-ID: <5253C7A2.9040604@oracle.com> Hi Christine, src/share/classes/java/awt/event/InputEvent.java > - *

> +     * 
{@code

The {@code} is redundant here because the 
 tag forces the text to 
use a fixed-size font already. Same comment for 
src/share/classes/java/awt/font/LineBreakMeasurer.java.


src/share/classes/java/awt/event/MouseEvent.java
> - * Component).  Due to platform-dependent Drag&Drop implementations,
> + * Component).  Due to platform-dependent Drag&Drop implementations,

Since you change this line anyway, I also suggest to replace  with 
{@code} here. Same comment for 
src/share/classes/java/awt/font/NumericShaper.java.


src/share/classes/java/awt/font/OpenType.java
> - * ( http://www.microsoft.com/typography/otspec/l ).
> + * ( http://www.microsoft.com/typography/otspec/l ).

There's an extra 'l' character right before the closing , which 
needs to be removed.

--
best regards,
Anthony

On 10/08/2013 05:59 AM, christine.lu at oracle.com wrote:
> Hi,
>
> Please review a fix for
>
> https://bugs.openjdk.java.net/browse/JDK-8026021
> more fix of javadoc errors and warnings reported by doclint, see the
> description
>
> webrev: http://cr.openjdk.java.net/~cl/8026021/webrev.00/
>
> Thanks
> Christine
>
>

From alexandr.scherbatiy at oracle.com  Tue Oct  8 02:05:52 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 08 Oct 2013 13:05:52 +0400
Subject:  [8] Review request for 7081594 Windows owned by an
 always-on-top window DO NOT automatically become always-on-top
In-Reply-To: <524EA8F3.9020201@oracle.com>
References: <524D6B3E.7030401@oracle.com> <524E7B55.9000408@oracle.com>
	<524E806B.6010009@oracle.com> <524EA6B6.40903@oracle.com>
	<524EA8F3.9020201@oracle.com>
Message-ID: <5253CAF0.1000609@oracle.com>

On 10/4/2013 3:39 PM, Anthony Petrov wrote:
> Good point, Sergey. Indeed, it seems that resetting the always on top 
> state to false for an owner window shouldn't affect its owned windows.

    I do not agree with this. According to the javadoc: 
http://docs.oracle.com/javase/7/docs/api/java/awt/Window.html#setAlwaysOnTop%28boolean%29
     ------------------------------
     All windows owned by an always-on-top window inherit this state and 
automatically become always-on-top.
     If a window ceases to be always-on-top, the windows that it owns 
will no longer be always-on-top.
    ------------------------------

   It clearly says that resetting the window always on top state to 
false should also reset the always on top state for its owned windows.

   Thanks,
   Alexandr.

>
> -- 
> best regards,
> Anthony
>
> On 10/04/2013 03:29 PM, Sergey Bylokhov wrote:
>> Hello.
>> It is interesting what should happens if we set saot for the child, then
>> set it to the owner, and then remove this property from the owner.
>>
>> On 04.10.2013 12:46, Artem Ananiev wrote:
>>>
>>> On 10/4/2013 12:24 PM, Anthony Petrov wrote:
>>>> The fix looks good to me.
>>>
>>> +1.
>>>
>>> I would also add a comment to security exception [empty] handler that
>>> we don't really expect exceptions here: either we have the permission,
>>> or the owner is not alwaysOnTop.
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 10/03/2013 05:03 PM, Alexander Scherbatiy wrote:
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-7081594
>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/7081594/webrev.00
>>>>>
>>>>>    The fix:
>>>>>      - sets alwaysOnTop field for a new created window from the 
>>>>> parent
>>>>> value
>>>>>      - propagates the alwaysOnTop value in setAlwaysOnTop() method to
>>>>> the owned windows
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>
>>


From Sergey.Bylokhov at oracle.com  Tue Oct  8 02:25:14 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 08 Oct 2013 13:25:14 +0400
Subject:  [8] Review request for 7081594 Windows owned by an
 always-on-top window DO NOT automatically become always-on-top
In-Reply-To: <5253CAF0.1000609@oracle.com>
References: <524D6B3E.7030401@oracle.com> <524E7B55.9000408@oracle.com>
	<524E806B.6010009@oracle.com> <524EA6B6.40903@oracle.com>
	<524EA8F3.9020201@oracle.com> <5253CAF0.1000609@oracle.com>
Message-ID: <5253CF7A.1080007@oracle.com>

On 10/8/13 1:05 PM, Alexander Scherbatiy wrote:
> On 10/4/2013 3:39 PM, Anthony Petrov wrote:
>> Good point, Sergey. Indeed, it seems that resetting the always on top 
>> state to false for an owner window shouldn't affect its owned windows.
>
>    I do not agree with this. According to the javadoc: 
> http://docs.oracle.com/javase/7/docs/api/java/awt/Window.html#setAlwaysOnTop%28boolean%29
>     ------------------------------
>     All windows owned by an always-on-top window inherit this state 
> and automatically become always-on-top.
>     If a window ceases to be always-on-top, the windows that it owns 
> will no longer be always-on-top.
>    ------------------------------
>
>   It clearly says that resetting the window always on top state to 
> false should also reset the always on top state for its owned windows.
Then I am fine with the fix.
>
>   Thanks,
>   Alexandr.
>
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 10/04/2013 03:29 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> It is interesting what should happens if we set saot for the child, 
>>> then
>>> set it to the owner, and then remove this property from the owner.
>>>
>>> On 04.10.2013 12:46, Artem Ananiev wrote:
>>>>
>>>> On 10/4/2013 12:24 PM, Anthony Petrov wrote:
>>>>> The fix looks good to me.
>>>>
>>>> +1.
>>>>
>>>> I would also add a comment to security exception [empty] handler that
>>>> we don't really expect exceptions here: either we have the permission,
>>>> or the owner is not alwaysOnTop.
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 10/03/2013 05:03 PM, Alexander Scherbatiy wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the fix:
>>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-7081594
>>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/7081594/webrev.00
>>>>>>
>>>>>>    The fix:
>>>>>>      - sets alwaysOnTop field for a new created window from the 
>>>>>> parent
>>>>>> value
>>>>>>      - propagates the alwaysOnTop value in setAlwaysOnTop() 
>>>>>> method to
>>>>>> the owned windows
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>
>>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Oct  8 02:42:41 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 08 Oct 2013 13:42:41 +0400
Subject:  Review request for JDK-8026021: more fix of javadoc
 errors and warnings reported by doclint
In-Reply-To: <5253C7A2.9040604@oracle.com>
References: <52536716.20908@oracle.com> <5253C7A2.9040604@oracle.com>
Message-ID: <5253D391.4010701@oracle.com>

Hi Christine,
Also looks like you fix include the fix for
http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005699.html
InputContext.java:
If you look to the generated javadoc you'll see that now the space 
before list is not the same to the space after the list. So 

from the beggining should be removed as well. On 10/8/13 12:51 PM, Anthony Petrov wrote: > Hi Christine, > > src/share/classes/java/awt/event/InputEvent.java >> - *

>> +     * 
{@code
I think not in this case. Since pre tag does not work with & correctly. 
Probably pre can be removed here?
I n the NumericShaper.java I see that & was changed to the &  inside 
. I suppose it is not necessary and  can be changed to {@code}
Same question about JTextComponent.java can we use {@code} tag for the 
code instead of ≥

>
> The {@code} is redundant here because the 
 tag forces the text to 
> use a fixed-size font already. Same comment for 
> src/share/classes/java/awt/font/LineBreakMeasurer.java.
>
>
> src/share/classes/java/awt/event/MouseEvent.java
>> - * Component). Due to platform-dependent Drag&Drop 
>> implementations,
>> + * Component).  Due to platform-dependent Drag&Drop 
>> implementations,
>
> Since you change this line anyway, I also suggest to replace  
> with {@code} here. Same comment for 
> src/share/classes/java/awt/font/NumericShaper.java.
>
>
> src/share/classes/java/awt/font/OpenType.java
>> - * ( > href=http://www.microsoft.com/typography/otspec/">http://www.microsoft.com/typography/otspec/l 
>> ).
>> + * ( > href="http://www.microsoft.com/typography/otspec/">http://www.microsoft.com/typography/otspec/l 
>> ).
>
> There's an extra 'l' character right before the closing , which 
> needs to be removed.
>
> -- 
> best regards,
> Anthony
>
> On 10/08/2013 05:59 AM, christine.lu at oracle.com wrote:
>> Hi,
>>
>> Please review a fix for
>>
>> https://bugs.openjdk.java.net/browse/JDK-8026021
>> more fix of javadoc errors and warnings reported by doclint, see the
>> description
>>
>> webrev: http://cr.openjdk.java.net/~cl/8026021/webrev.00/
>>
>> Thanks
>> Christine
>>
>>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131008/9614bb86/attachment.html 

From artem.ananiev at oracle.com  Tue Oct  8 02:45:56 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Tue, 08 Oct 2013 13:45:56 +0400
Subject:  [8] Review request for 7172597:
 java.awt.KeyboardFocusManager.clearFocusOwner() missed javadoc tag @since
 1.8
In-Reply-To: <5253C48D.4000806@oracle.com>
References: <5252F1E3.5040605@oracle.com> <5253C48D.4000806@oracle.com>
Message-ID: <5253D454.7000209@oracle.com>


+1.

Thanks,

Artem

On 10/8/2013 12:38 PM, Anthony Petrov wrote:
> Looks fine.
>
> --
> best regards,
> Anthony
>
> On 10/07/2013 09:39 PM, sergey malenkov wrote:
>>
>> Hello,
>>
>> Could you please review the following fix:
>> fix:http://cr.openjdk.java.net/~malenkov/7172597.8.0/
>> bug:https://bugs.openjdk.java.net/browse/JDK-7172597
>>
>> Added missed tag @since 1.8
>>
>> Thanks,
>> SAM
>>

From Sergey.Bylokhov at oracle.com  Tue Oct  8 02:54:47 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 08 Oct 2013 13:54:47 +0400
Subject:  [8] Review request for 7158311
 GraphicsDevice.setDisplayMode(...) leads to hang when DISPLAY variable
 points to Oracle Linux
In-Reply-To: <524B389C.7090601@oracle.com>
References: <524ADDC9.8060103@oracle.com> <524B389C.7090601@oracle.com>
Message-ID: <5253D667.7090500@oracle.com>

Hi, Alexander.
The fix looks good to me as well.

On 10/2/13 1:03 AM, Anthony Petrov wrote:
> The fix looks fine to me.
>
> -- 
> best regards,
> Anthony
>
> On 10/01/2013 06:35 PM, Alexander Zvegintsev wrote:
>> Hello,
>>
>> Could you please review a fix for following issues:
>> https://bugs.openjdk.java.net/browse/JDK-7158311
>> https://bugs.openjdk.java.net/browse/JDK-8001463
>>
>> webrev:
>> http://cr.openjdk.java.net/~serb/alexz/7158311/webrev.00/
>>
>> All X11 implementations of DisplayChangedListener does not call any X11
>> routines, hence
>> SunGraphicsEnvironment.displayChanged() callback does not require an
>> AWTLock and we
>> can temporarily release it to avoid deadlock.
>>


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Tue Oct  8 03:01:56 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 8 Oct 2013 14:01:56 +0400
Subject:  [8] Review Request: JDK-8025585 Win: Popups in
	JFXPanel do not receive MouseWheel events
In-Reply-To: <524C4CBD.8060908@oracle.com>
References: <5CBB81CC-BC3C-41A9-89C5-C1952582477A@oracle.com>
	<524B0395.7060803@oracle.com> <524B0C3B.8080702@oracle.com>
	
	<524C4CBD.8060908@oracle.com>
Message-ID: <2F223B02-81E5-4736-8AB2-893B45DB73AC@oracle.com>

Hello, Anthony.

Sorry for the delay, I've got distracted by other fixes. Here's an updated version of the fix:
http://cr.openjdk.java.net/~pchelko/8025585/webrev.01/

> So I think we should ignore the SendMessage's return value and always return TRUE here because the message has already been processed by the target toolkit. What do you think?
Indeed in case an other toolkit would return false here we would get quite inconsistent behaviour. So I've updated the fix to always return TRUE.

With best regards, Petr.

On 02.10.2013, at 20:41, Anthony Petrov  wrote:

> Hi Petr,
> 
> The new version looks better. However, there's still one minor issue:
> 
>> 1528                     return ::SendMessage(hWndForWheel, msg.message, mouseWParam, mouseLParam);
> 
> The PreProcessMouseMsg() function to which this line belongs should return a boolean value indicating whether the event must be processed (FALSE) or silently consumed (TRUE). The ::SendMessage() returns the result of calling a WndProc() for the target window when it processes the message, which we really don't care about here. And regardless of the result, I don't think that AWT should process the message any further after it's been redirected to the target toolkit.
> 
> So I think we should ignore the SendMessage's return value and always return TRUE here because the message has already been processed by the target toolkit. What do you think?
> 
> --
> best regards,
> Anthony
> 
> On 10/02/2013 05:33 PM, Petr Pchelko wrote:
>> Hello, Thank you for the review.
>> 
>>> It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't.
>> That was indeed an issue. I've got used to Mac behaviour and did not notice the problem.
>> 
>> The new version of the fix is available here:
>> http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/
>> 
>> Now we redispatch the wheel event only if the window is in the same process.
>> 
>> With best regards. Petr.
>> 
>> On Oct 1, 2013, at 9:54 PM, Artem Ananiev  wrote:
>> 
>>> 
>>> On 10/1/2013 9:17 PM, Anthony Petrov wrote:
>>>> Hi Petr,
>>>> 
>>>> MS Windows always sends WHEEL events to the focused window. And my
>>>> testing shows that when you scroll the wheel outside of an AWT window,
>>>> the scroll events are consumed (by AWT, supposedly).
>>>> 
>>>> With your fix you seem to always redirect the events to the window under
>>>> the mouse. Now suppose you have a 3rd-party window with a scroll bar in
>>>> background (e.g. Windows Explorer). If an AWT window is currently
>>>> focused, but you move the mouse pointer outside of it and above the
>>>> Explorer window, and start scrolling, will the Explorer window scroll
>>>> its contents? Currently it doesn't. What about if we apply your fix?
>>> 
>>> It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't.
>>> 
>>> Thanks,
>>> 
>>> Artem
>>> 
>>>> --
>>>> best regards,
>>>> Anthony
>>>> 
>>>> On 09/27/2013 07:24 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>> 
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8025585
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/
>>>>> 
>>>>> The fix is needed for JFXPanel support. We need to redispatch
>>>>> MOUSEWHEEL messages to the window under mouse. In case of Popups in a
>>>>> JFXPanel the HWND belongs to a different tollkit, so we need to use
>>>>> ::SendMessage to redispatch the message.
>>>>> 
>>>>> With best regards. Petr.
>>>>> 
>> 


From yuri.nesterenko at oracle.com  Tue Oct  8 02:59:08 2013
From: yuri.nesterenko at oracle.com (yuri.nesterenko at oracle.com)
Date: Tue, 08 Oct 2013 09:59:08 +0000
Subject:  hg: jdk8/awt/jdk: 8025236: [javadoc] fix some errors in
	AWT
Message-ID: <20131008100035.1F05862E26@hg.openjdk.java.net>

Changeset: bdc8abbce9c1
Author:    yan
Date:      2013-10-08 13:57 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bdc8abbce9c1

8025236: [javadoc] fix some errors in AWT
Reviewed-by: yan, anthony
Contributed-by: Dmitry Ginzburg 

! src/share/classes/java/awt/event/InputEvent.java
! src/share/classes/java/awt/event/MouseEvent.java
! src/share/classes/java/awt/im/InputContext.java
! src/share/classes/java/awt/im/InputMethodHighlight.java


From anthony.petrov at oracle.com  Tue Oct  8 03:13:24 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 08 Oct 2013 14:13:24 +0400
Subject:  [8] Review Request: JDK-8025585 Win: Popups in
 JFXPanel do not receive MouseWheel events
In-Reply-To: <2F223B02-81E5-4736-8AB2-893B45DB73AC@oracle.com>
References: <5CBB81CC-BC3C-41A9-89C5-C1952582477A@oracle.com>
	<524B0395.7060803@oracle.com> <524B0C3B.8080702@oracle.com>
	
	<524C4CBD.8060908@oracle.com>
	<2F223B02-81E5-4736-8AB2-893B45DB73AC@oracle.com>
Message-ID: <5253DAC4.9090605@oracle.com>

Thanks for the update, Petr. The latest fix looks fine to me.

--
best regards,
Anthony

On 10/08/2013 02:01 PM, Petr Pchelko wrote:
> Hello, Anthony.
>
> Sorry for the delay, I've got distracted by other fixes. Here's an updated version of the fix:
> http://cr.openjdk.java.net/~pchelko/8025585/webrev.01/
>
>> So I think we should ignore the SendMessage's return value and always return TRUE here because the message has already been processed by the target toolkit. What do you think?
> Indeed in case an other toolkit would return false here we would get quite inconsistent behaviour. So I've updated the fix to always return TRUE.
>
> With best regards, Petr.
>
> On 02.10.2013, at 20:41, Anthony Petrov  wrote:
>
>> Hi Petr,
>>
>> The new version looks better. However, there's still one minor issue:
>>
>>> 1528                     return ::SendMessage(hWndForWheel, msg.message, mouseWParam, mouseLParam);
>>
>> The PreProcessMouseMsg() function to which this line belongs should return a boolean value indicating whether the event must be processed (FALSE) or silently consumed (TRUE). The ::SendMessage() returns the result of calling a WndProc() for the target window when it processes the message, which we really don't care about here. And regardless of the result, I don't think that AWT should process the message any further after it's been redirected to the target toolkit.
>>
>> So I think we should ignore the SendMessage's return value and always return TRUE here because the message has already been processed by the target toolkit. What do you think?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 10/02/2013 05:33 PM, Petr Pchelko wrote:
>>> Hello, Thank you for the review.
>>>
>>>> It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't.
>>> That was indeed an issue. I've got used to Mac behaviour and did not notice the problem.
>>>
>>> The new version of the fix is available here:
>>> http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/
>>>
>>> Now we redispatch the wheel event only if the window is in the same process.
>>>
>>> With best regards. Petr.
>>>
>>> On Oct 1, 2013, at 9:54 PM, Artem Ananiev  wrote:
>>>
>>>>
>>>> On 10/1/2013 9:17 PM, Anthony Petrov wrote:
>>>>> Hi Petr,
>>>>>
>>>>> MS Windows always sends WHEEL events to the focused window. And my
>>>>> testing shows that when you scroll the wheel outside of an AWT window,
>>>>> the scroll events are consumed (by AWT, supposedly).
>>>>>
>>>>> With your fix you seem to always redirect the events to the window under
>>>>> the mouse. Now suppose you have a 3rd-party window with a scroll bar in
>>>>> background (e.g. Windows Explorer). If an AWT window is currently
>>>>> focused, but you move the mouse pointer outside of it and above the
>>>>> Explorer window, and start scrolling, will the Explorer window scroll
>>>>> its contents? Currently it doesn't. What about if we apply your fix?
>>>>
>>>> It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't.
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 09/27/2013 07:24 PM, Petr Pchelko wrote:
>>>>>> Hello, AWT Team.
>>>>>>
>>>>>> Please review the fix for the issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025585
>>>>>> The fix is available at:
>>>>>> http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/
>>>>>>
>>>>>> The fix is needed for JFXPanel support. We need to redispatch
>>>>>> MOUSEWHEEL messages to the window under mouse. In case of Popups in a
>>>>>> JFXPanel the HWND belongs to a different tollkit, so we need to use
>>>>>> ::SendMessage to redispatch the message.
>>>>>>
>>>>>> With best regards. Petr.
>>>>>>
>>>
>

From artem.ananiev at oracle.com  Tue Oct  8 03:24:28 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Tue, 08 Oct 2013 14:24:28 +0400
Subject:  [8] Review request for 7081594 Windows owned by an
 always-on-top window DO NOT automatically become always-on-top
In-Reply-To: <5253CAF0.1000609@oracle.com>
References: <524D6B3E.7030401@oracle.com> <524E7B55.9000408@oracle.com>
	<524E806B.6010009@oracle.com> <524EA6B6.40903@oracle.com>
	<524EA8F3.9020201@oracle.com> <5253CAF0.1000609@oracle.com>
Message-ID: <5253DD5C.9050602@oracle.com>


On 10/8/2013 1:05 PM, Alexander Scherbatiy wrote:
> On 10/4/2013 3:39 PM, Anthony Petrov wrote:
>> Good point, Sergey. Indeed, it seems that resetting the always on top
>> state to false for an owner window shouldn't affect its owned windows.
>
>     I do not agree with this. According to the javadoc:
> http://docs.oracle.com/javase/7/docs/api/java/awt/Window.html#setAlwaysOnTop%28boolean%29
>
>      ------------------------------
>      All windows owned by an always-on-top window inherit this state and
> automatically become always-on-top.
>      If a window ceases to be always-on-top, the windows that it owns
> will no longer be always-on-top.
>     ------------------------------
>
>    It clearly says that resetting the window always on top state to
> false should also reset the always on top state for its owned windows.

Thanks for this JavaDoc excerpt. It seems the fix is correct now.

Thanks,

Artem

>    Thanks,
>    Alexandr.
>
>>
>> --
>> best regards,
>> Anthony
>>
>> On 10/04/2013 03:29 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> It is interesting what should happens if we set saot for the child, then
>>> set it to the owner, and then remove this property from the owner.
>>>
>>> On 04.10.2013 12:46, Artem Ananiev wrote:
>>>>
>>>> On 10/4/2013 12:24 PM, Anthony Petrov wrote:
>>>>> The fix looks good to me.
>>>>
>>>> +1.
>>>>
>>>> I would also add a comment to security exception [empty] handler that
>>>> we don't really expect exceptions here: either we have the permission,
>>>> or the owner is not alwaysOnTop.
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 10/03/2013 05:03 PM, Alexander Scherbatiy wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the fix:
>>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-7081594
>>>>>>    webrev: http://cr.openjdk.java.net/~alexsch/7081594/webrev.00
>>>>>>
>>>>>>    The fix:
>>>>>>      - sets alwaysOnTop field for a new created window from the
>>>>>> parent
>>>>>> value
>>>>>>      - propagates the alwaysOnTop value in setAlwaysOnTop() method to
>>>>>> the owned windows
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>
>>>
>

From alexander.v.stepanov at oracle.com  Tue Oct  8 03:29:00 2013
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 08 Oct 2013 14:29:00 +0400
Subject:  [8] Review Request for 8025649: need test to cover
 JDK-8000423
In-Reply-To: <524EAA2F.6030704@oracle.com>
References: <5249772F.6060503@oracle.com> <524EAA2F.6030704@oracle.com>
Message-ID: <5253DE6C.4080307@oracle.com>

Hello Sergey,

Thanks, added:
http://cr.openjdk.java.net/~alexsch/alexander-stepanov/8025649/webrev.01/

Regards,
Alexander

On 04.10.2013 15:44, Sergey Bylokhov wrote:
> Hello, Alexander.
> The fix looks good, But please add copyright to the html file also.
>
> On 30.09.2013 17:05, alexander stepanov wrote:
>> Hello,
>>
>> Could you please review the fix for the following [TEST] bug:
>> https://bugs.openjdk.java.net/browse/JDK-8025649
>>
>> Webrev corresponding:
>> http://cr.openjdk.java.net/~alexsch/alexander-stepanov/8025649/webrev.00/ 
>>
>>
>> Just a new test added; no other code affected.
>> The patch contains a simple manual test to make sure if diacritical 
>> marks could be typed for TextArea and TextField (hard to automate; 
>> the test requires some internationalization settings on a machine).
>>
>> Thanks,
>> Alexander.
>
>


From Sergey.Bylokhov at oracle.com  Tue Oct  8 04:10:18 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 08 Oct 2013 15:10:18 +0400
Subject:  [8] Review Request for 8025649: need test to cover
 JDK-8000423
In-Reply-To: <5253DE6C.4080307@oracle.com>
References: <5249772F.6060503@oracle.com> <524EAA2F.6030704@oracle.com>
	<5253DE6C.4080307@oracle.com>
Message-ID: <5253E81A.1000409@oracle.com>

Hi, Alexander.
The fix looks good.

On 10/8/13 2:29 PM, alexander stepanov wrote:
> Hello Sergey,
>
> Thanks, added:
> http://cr.openjdk.java.net/~alexsch/alexander-stepanov/8025649/webrev.01/
>
> Regards,
> Alexander
>
> On 04.10.2013 15:44, Sergey Bylokhov wrote:
>> Hello, Alexander.
>> The fix looks good, But please add copyright to the html file also.
>>
>> On 30.09.2013 17:05, alexander stepanov wrote:
>>> Hello,
>>>
>>> Could you please review the fix for the following [TEST] bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8025649
>>>
>>> Webrev corresponding:
>>> http://cr.openjdk.java.net/~alexsch/alexander-stepanov/8025649/webrev.00/ 
>>>
>>>
>>> Just a new test added; no other code affected.
>>> The patch contains a simple manual test to make sure if diacritical 
>>> marks could be typed for TextArea and TextField (hard to automate; 
>>> the test requires some internationalization settings on a machine).
>>>
>>> Thanks,
>>> Alexander.
>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Oct  8 04:13:09 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 08 Oct 2013 15:13:09 +0400
Subject:  [JBS] (JDK-8025236) [javadoc] fix some errors in AWT
In-Reply-To: 
References: 
	
Message-ID: <5253E8C5.3030905@oracle.com>

Hi, Yuri.
If I am not missing something review was not complete, why it was pushed?

On 10/8/13 2:02 PM, HG Updates (JBS) wrote:
>       [ https://bugs.openjdk.java.net/browse/JDK-8025236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> HG Updates resolved JDK-8025236.
> --------------------------------
>
>      Resolved In Build: team
>          Fix Version/s: 8
>             Resolution: Fixed
>
> URL:   http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bdc8abbce9c1
> User:  yan
> Date:  2013-10-08 10:00:35 +0000
>
>                  
>> [javadoc] fix some errors in AWT
>> --------------------------------
>>
>>                  Key: JDK-8025236
>>                  URL: https://bugs.openjdk.java.net/browse/JDK-8025236
>>              Project: JDK
>>           Issue Type: Bug
>>           Components: client-libs
>>             Reporter: Dmitry Ginzburg
>>             Assignee: Dmitry Ginzburg
>>             Priority: P5
>>               Labels: awt, javadoc
>>              Fix For: 8
>>
>>
>> Errors:
>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/event/InputEvent.java:448: error: bad HTML entity
>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/event/MouseEvent.java:152: error: semicolon missing
>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/event/MouseEvent.java:154: error: semicolon missing
>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/event/MouseEvent.java:330: error: ')' missing in reference
>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/im/InputContext.java:121: error: tag not allowed here: 

>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/im/InputMethodHighlight.java:54: error: bad use of '>' >> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/im/InputMethodHighlight.java:55: error: bad use of '>' > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA administrators: https://bugs.openjdk.java.net/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira -- Best regards, Sergey. From petr.pchelko at oracle.com Tue Oct 8 04:16:04 2013 From: petr.pchelko at oracle.com (petr.pchelko at oracle.com) Date: Tue, 08 Oct 2013 11:16:04 +0000 Subject: hg: jdk8/awt/jdk: 7158311: GraphicsDevice.setDisplayMode(...) leads to hang when DISPLAY variable points to Oracle Linux; ... Message-ID: <20131008111635.B8D9162E2F@hg.openjdk.java.net> Changeset: 01022f461570 Author: pchelko Date: 2013-10-08 15:17 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/01022f461570 7158311: GraphicsDevice.setDisplayMode(...) leads to hang when DISPLAY variable points to Oracle Linux 8001463: Regression : Deadlock between AWT-XAWT thread and AWT-EventQueue-0 Thread when screen resolution changes Reviewed-by: art, serb Contributed-by: alexander.zvegintsev at oracle.com ! src/solaris/classes/sun/awt/X11/XToolkit.java From yuri.nesterenko at oracle.com Tue Oct 8 04:24:32 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Tue, 08 Oct 2013 15:24:32 +0400 Subject: [JBS] (JDK-8025236) [javadoc] fix some errors in AWT In-Reply-To: <5253E8C5.3030905@oracle.com> References: <5253E8C5.3030905@oracle.com> Message-ID: <5253EB70.6010900@oracle.com> Oops, what's wrong? What have I missed? There were two reviews, so I decided it's ok to push. Thanks, -yan On 10/08/2013 03:13 PM, Sergey Bylokhov wrote: > Hi, Yuri. > If I am not missing something review was not complete, why it was pushed? > > On 10/8/13 2:02 PM, HG Updates (JBS) wrote: >> [ >> https://bugs.openjdk.java.net/browse/JDK-8025236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> HG Updates resolved JDK-8025236. >> -------------------------------- >> >> Resolved In Build: team >> Fix Version/s: 8 >> Resolution: Fixed >> >> URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bdc8abbce9c1 >> User: yan >> Date: 2013-10-08 10:00:35 +0000 >> >>> [javadoc] fix some errors in AWT >>> -------------------------------- >>> >>> Key: JDK-8025236 >>> URL: https://bugs.openjdk.java.net/browse/JDK-8025236 >>> Project: JDK >>> Issue Type: Bug >>> Components: client-libs >>> Reporter: Dmitry Ginzburg >>> Assignee: Dmitry Ginzburg >>> Priority: P5 >>> Labels: awt, javadoc >>> Fix For: 8 >>> >>> >>> Errors: >>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/event/InputEvent.java:448: >>> error: bad HTML entity >>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/event/MouseEvent.java:152: >>> error: semicolon missing >>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/event/MouseEvent.java:154: >>> error: semicolon missing >>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/event/MouseEvent.java:330: >>> error: ')' missing in reference >>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/im/InputContext.java:121: >>> error: tag not allowed here:

>>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/im/InputMethodHighlight.java:54: >>> error: bad use of '>' >>> /local/work/jdk8/jdk8/jdk/src/share/classes/java/awt/im/InputMethodHighlight.java:55: >>> error: bad use of '>' >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA >> administrators: >> https://bugs.openjdk.java.net/secure/ContactAdministrators!default.jspa >> For more information on JIRA, see: http://www.atlassian.com/software/jira > > From petr.pchelko at oracle.com Tue Oct 8 04:53:12 2013 From: petr.pchelko at oracle.com (petr.pchelko at oracle.com) Date: Tue, 08 Oct 2013 11:53:12 +0000 Subject: hg: jdk8/awt/jdk: 8025585: Win: Popups in JFXPanel do not receive MouseWheel events Message-ID: <20131008115344.2495762E33@hg.openjdk.java.net> Changeset: a5d0730342a5 Author: pchelko Date: 2013-10-08 15:54 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a5d0730342a5 8025585: Win: Popups in JFXPanel do not receive MouseWheel events Reviewed-by: anthony, art ! src/windows/native/sun/windows/awt_Toolkit.cpp From oleg.pekhovskiy at oracle.com Tue Oct 8 05:07:21 2013 From: oleg.pekhovskiy at oracle.com (oleg.pekhovskiy at oracle.com) Date: Tue, 08 Oct 2013 12:07:21 +0000 Subject: hg: jdk8/awt/jdk: 8000425: FileDialog documentation should be enhanced Message-ID: <20131008120736.AB0DE62E34@hg.openjdk.java.net> Changeset: 85a72bb00d74 Author: bagiras Date: 2013-10-08 16:04 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/85a72bb00d74 8000425: FileDialog documentation should be enhanced Reviewed-by: serb, anthony ! src/share/classes/java/awt/FileDialog.java From artem.ananiev at oracle.com Tue Oct 8 05:30:01 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 08 Oct 2013 16:30:01 +0400 Subject: [8] Review Request: JDK-8025585 Win: Popups in JFXPanel do not receive MouseWheel events In-Reply-To: <2F223B02-81E5-4736-8AB2-893B45DB73AC@oracle.com> References: <5CBB81CC-BC3C-41A9-89C5-C1952582477A@oracle.com> <524B0395.7060803@oracle.com> <524B0C3B.8080702@oracle.com> <524C4CBD.8060908@oracle.com> <2F223B02-81E5-4736-8AB2-893B45DB73AC@oracle.com> Message-ID: <5253FAC9.7000400@oracle.com> On 10/8/2013 2:01 PM, Petr Pchelko wrote: > Hello, Anthony. > > Sorry for the delay, I've got distracted by other fixes. Here's an updated version of the fix: > http://cr.openjdk.java.net/~pchelko/8025585/webrev.01/ Looks fine. Thanks, Artem >> So I think we should ignore the SendMessage's return value and always return TRUE here because the message has already been processed by the target toolkit. What do you think? > Indeed in case an other toolkit would return false here we would get quite inconsistent behaviour. So I've updated the fix to always return TRUE. > > With best regards, Petr. > > On 02.10.2013, at 20:41, Anthony Petrov wrote: > >> Hi Petr, >> >> The new version looks better. However, there's still one minor issue: >> >>> 1528 return ::SendMessage(hWndForWheel, msg.message, mouseWParam, mouseLParam); >> >> The PreProcessMouseMsg() function to which this line belongs should return a boolean value indicating whether the event must be processed (FALSE) or silently consumed (TRUE). The ::SendMessage() returns the result of calling a WndProc() for the target window when it processes the message, which we really don't care about here. And regardless of the result, I don't think that AWT should process the message any further after it's been redirected to the target toolkit. >> >> So I think we should ignore the SendMessage's return value and always return TRUE here because the message has already been processed by the target toolkit. What do you think? >> >> -- >> best regards, >> Anthony >> >> On 10/02/2013 05:33 PM, Petr Pchelko wrote: >>> Hello, Thank you for the review. >>> >>>> It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't. >>> That was indeed an issue. I've got used to Mac behaviour and did not notice the problem. >>> >>> The new version of the fix is available here: >>> http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/ >>> >>> Now we redispatch the wheel event only if the window is in the same process. >>> >>> With best regards. Petr. >>> >>> On Oct 1, 2013, at 9:54 PM, Artem Ananiev wrote: >>> >>>> >>>> On 10/1/2013 9:17 PM, Anthony Petrov wrote: >>>>> Hi Petr, >>>>> >>>>> MS Windows always sends WHEEL events to the focused window. And my >>>>> testing shows that when you scroll the wheel outside of an AWT window, >>>>> the scroll events are consumed (by AWT, supposedly). >>>>> >>>>> With your fix you seem to always redirect the events to the window under >>>>> the mouse. Now suppose you have a 3rd-party window with a scroll bar in >>>>> background (e.g. Windows Explorer). If an AWT window is currently >>>>> focused, but you move the mouse pointer outside of it and above the >>>>> Explorer window, and start scrolling, will the Explorer window scroll >>>>> its contents? Currently it doesn't. What about if we apply your fix? >>>> >>>> It really seems to be an issue. We need another check that hWndForWheel belongs to the current process, and doesn't sent the event to this window, if it doesn't. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 09/27/2013 07:24 PM, Petr Pchelko wrote: >>>>>> Hello, AWT Team. >>>>>> >>>>>> Please review the fix for the issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8025585 >>>>>> The fix is available at: >>>>>> http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/ >>>>>> >>>>>> The fix is needed for JFXPanel support. We need to redispatch >>>>>> MOUSEWHEEL messages to the window under mouse. In case of Popups in a >>>>>> JFXPanel the HWND belongs to a different tollkit, so we need to use >>>>>> ::SendMessage to redispatch the message. >>>>>> >>>>>> With best regards. Petr. >>>>>> >>> > From anthony.petrov at oracle.com Tue Oct 8 05:33:13 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 08 Oct 2013 16:33:13 +0400 Subject: [8] Review Request: 8022119 test api/javax_sound/sampled/spi/MixerProvider/indexTGF_MixerProviderTests fails In-Reply-To: <5252EC78.5010009@oracle.com> References: <5252EC78.5010009@oracle.com> Message-ID: <5253FB89.9060705@oracle.com> Hi Sergey, The fix looks fine to me. A minor typo in the comment: > 192 // creates the ServiceLoader instance, so it require do be called from Should read "requires to". No need for a new webrev with this change. -- best regards, Anthony On 10/07/2013 09:16 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 8. > ServiceLoader usage was changed according to the change in JDK-8019622 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8022119 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8022119/webrev.00 > From anthony.petrov at oracle.com Tue Oct 8 05:37:19 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 08 Oct 2013 16:37:19 +0400 Subject: [8] Review request for 7081594 Windows owned by an always-on-top window DO NOT automatically become always-on-top In-Reply-To: <5253CF7A.1080007@oracle.com> References: <524D6B3E.7030401@oracle.com> <524E7B55.9000408@oracle.com> <524E806B.6010009@oracle.com> <524EA6B6.40903@oracle.com> <524EA8F3.9020201@oracle.com> <5253CAF0.1000609@oracle.com> <5253CF7A.1080007@oracle.com> Message-ID: <5253FC7F.2010409@oracle.com> +1. Ship it. -- best regards, Anthony On 10/08/2013 01:25 PM, Sergey Bylokhov wrote: > On 10/8/13 1:05 PM, Alexander Scherbatiy wrote: >> On 10/4/2013 3:39 PM, Anthony Petrov wrote: >>> Good point, Sergey. Indeed, it seems that resetting the always on top >>> state to false for an owner window shouldn't affect its owned windows. >> >> I do not agree with this. According to the javadoc: >> http://docs.oracle.com/javase/7/docs/api/java/awt/Window.html#setAlwaysOnTop%28boolean%29 >> >> ------------------------------ >> All windows owned by an always-on-top window inherit this state >> and automatically become always-on-top. >> If a window ceases to be always-on-top, the windows that it owns >> will no longer be always-on-top. >> ------------------------------ >> >> It clearly says that resetting the window always on top state to >> false should also reset the always on top state for its owned windows. > Then I am fine with the fix. >> >> Thanks, >> Alexandr. >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/04/2013 03:29 PM, Sergey Bylokhov wrote: >>>> Hello. >>>> It is interesting what should happens if we set saot for the child, >>>> then >>>> set it to the owner, and then remove this property from the owner. >>>> >>>> On 04.10.2013 12:46, Artem Ananiev wrote: >>>>> >>>>> On 10/4/2013 12:24 PM, Anthony Petrov wrote: >>>>>> The fix looks good to me. >>>>> >>>>> +1. >>>>> >>>>> I would also add a comment to security exception [empty] handler that >>>>> we don't really expect exceptions here: either we have the permission, >>>>> or the owner is not alwaysOnTop. >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 10/03/2013 05:03 PM, Alexander Scherbatiy wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the fix: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-7081594 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7081594/webrev.00 >>>>>>> >>>>>>> The fix: >>>>>>> - sets alwaysOnTop field for a new created window from the >>>>>>> parent >>>>>>> value >>>>>>> - propagates the alwaysOnTop value in setAlwaysOnTop() >>>>>>> method to >>>>>>> the owned windows >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>> >>>> >> > > From anthony.petrov at oracle.com Tue Oct 8 05:38:51 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 08 Oct 2013 16:38:51 +0400 Subject: [8] Review Request for 8025649: need test to cover JDK-8000423 In-Reply-To: <5253E81A.1000409@oracle.com> References: <5249772F.6060503@oracle.com> <524EAA2F.6030704@oracle.com> <5253DE6C.4080307@oracle.com> <5253E81A.1000409@oracle.com> Message-ID: <5253FCDB.20006@oracle.com> The fix looks fine to me, too. -- best regards, Anthony On 10/08/2013 03:10 PM, Sergey Bylokhov wrote: > Hi, Alexander. > The fix looks good. > > On 10/8/13 2:29 PM, alexander stepanov wrote: >> Hello Sergey, >> >> Thanks, added: >> http://cr.openjdk.java.net/~alexsch/alexander-stepanov/8025649/webrev.01/ >> >> Regards, >> Alexander >> >> On 04.10.2013 15:44, Sergey Bylokhov wrote: >>> Hello, Alexander. >>> The fix looks good, But please add copyright to the html file also. >>> >>> On 30.09.2013 17:05, alexander stepanov wrote: >>>> Hello, >>>> >>>> Could you please review the fix for the following [TEST] bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8025649 >>>> >>>> Webrev corresponding: >>>> http://cr.openjdk.java.net/~alexsch/alexander-stepanov/8025649/webrev.00/ >>>> >>>> >>>> Just a new test added; no other code affected. >>>> The patch contains a simple manual test to make sure if diacritical >>>> marks could be typed for TextArea and TextField (hard to automate; >>>> the test requires some internationalization settings on a machine). >>>> >>>> Thanks, >>>> Alexander. >>> >>> >> > > From oleg.pekhovskiy at oracle.com Tue Oct 8 05:57:32 2013 From: oleg.pekhovskiy at oracle.com (oleg.pekhovskiy at oracle.com) Date: Tue, 08 Oct 2013 12:57:32 +0000 Subject: hg: jdk8/awt/jdk: 7068423: Spec for java.awt.GraphicsDevice.getFullScreenWindow() needs clarification Message-ID: <20131008125815.D238162E38@hg.openjdk.java.net> Changeset: 01607de6265d Author: bagiras Date: 2013-10-08 16:56 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/01607de6265d 7068423: Spec for java.awt.GraphicsDevice.getFullScreenWindow() needs clarification Reviewed-by: art, anthony ! src/share/classes/java/awt/GraphicsDevice.java From oleg.pekhovskiy at oracle.com Tue Oct 8 06:14:03 2013 From: oleg.pekhovskiy at oracle.com (oleg.pekhovskiy at oracle.com) Date: Tue, 08 Oct 2013 13:14:03 +0000 Subject: hg: jdk8/awt/jdk: 7199196: Incremental transfer is broken because of a typo Message-ID: <20131008131419.DF36F62E3A@hg.openjdk.java.net> Changeset: 184b16f4e61f Author: bagiras Date: 2013-10-08 17:00 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/184b16f4e61f 7199196: Incremental transfer is broken because of a typo Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XSelection.java From sergey.malenkov at oracle.com Tue Oct 8 07:11:16 2013 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Tue, 08 Oct 2013 14:11:16 +0000 Subject: hg: jdk8/awt/jdk: 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified Message-ID: <20131008141224.139F962E3D@hg.openjdk.java.net> Changeset: 42d3ea1c35b4 Author: malenkov Date: 2013-10-08 18:10 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/42d3ea1c35b4 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java From sergey.malenkov at oracle.com Tue Oct 8 07:21:51 2013 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Tue, 08 Oct 2013 14:21:51 +0000 Subject: hg: jdk8/awt/jdk: 7172597: java.awt.KeyboardFocusManager.clearFocusOwner() missed javadoc tag @since 1.8 Message-ID: <20131008142240.8F77262E3F@hg.openjdk.java.net> Changeset: 6914b883c3bb Author: malenkov Date: 2013-10-08 18:19 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6914b883c3bb 7172597: java.awt.KeyboardFocusManager.clearFocusOwner() missed javadoc tag @since 1.8 Reviewed-by: art, anthony ! src/share/classes/java/awt/KeyboardFocusManager.java From alexandr.scherbatiy at oracle.com Tue Oct 8 07:46:40 2013 From: alexandr.scherbatiy at oracle.com (alexandr.scherbatiy at oracle.com) Date: Tue, 08 Oct 2013 14:46:40 +0000 Subject: hg: jdk8/awt/jdk: 7081594: Windows owned by an always-on-top window DO NOT automatically become always-on-top Message-ID: <20131008144706.D257062E42@hg.openjdk.java.net> Changeset: a2dd2b411723 Author: alexsch Date: 2013-10-08 18:45 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a2dd2b411723 7081594: Windows owned by an always-on-top window DO NOT automatically become always-on-top Reviewed-by: art, anthony, serb ! src/share/classes/java/awt/Window.java + test/java/awt/Window/AlwaysOnTop/AlwaysOnTopFieldTest.java From leonid.romanov at oracle.com Tue Oct 8 07:54:50 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 8 Oct 2013 18:54:50 +0400 Subject: [8] Review request for 8019623: Lack of synchronization in AppContext.getAppContext() In-Reply-To: <524E851E.6020006@oracle.com> References: <524E851E.6020006@oracle.com> Message-ID: <3D74E49D-1423-4955-9D55-3204F475124D@oracle.com> Hi, I tried different variations of your suggestion and none of them worked. The reason is timing: suppose two threads, A and B, entered AppContetx.getAppContext() and then AppContext.initMainAppContext() at the same time. We need thread A to be able to initialize mainAppContext, return from initMainAppContext() and then initialize local variable with AppContext to be returned without thread B intervening in between. This just doesn't happen. On Oct 4, 2013, at 1:06 PM, Artem Ananiev wrote: > Hi, Leonid, > > the fix looks fine. > > I believe it is possible to create a regression test for this fix. The test should create several thread groups and call AC.getAC() there, then check that all the returned AC's are equal. Although it won't 100% fail before your fix, it should 100% pass after it. What do you think about it? > > Thanks, > > Artem > > On 10/2/2013 6:22 PM, Leonid Romanov wrote: >> Hello, >> Please, review a fix for 8019623: Lack of synchronization in AppContext.getAppContext(). I don't think it makes sense to ensure that AppContext.getAppContext()/SunToolkit.createNewAppContext() is thread safe, because in practice we haven't had any problems with this combination. What we have had problems with is the getAppContext()/getAppContext() combination because of the double mainAppContext initialization. Therefore, the fix takes care of this issue. While I could have simply made the whole AppContext.getAppContext() method synchronized, I wanted the most common path through it (returning cached AppContext) to remain lock-free, so I decided to place the lock around the most critical part, where initMainAppContext() gets called. >> As for a regression test, I couldn't find a way to detect double initMainAppContext initialization. We put newly created AppContexts into a thread-safe map, so whatever AppContext wins the race remains in the map, and the other is simply lost, without any convenient means to detect its existence. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8019623 >> Webrev: http://cr.openjdk.java.net/~leonidr/8019623/webrev.00/ >> >> Thanks, >> Leonid. >> From artem.ananiev at oracle.com Tue Oct 8 08:43:23 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 08 Oct 2013 19:43:23 +0400 Subject: [8] Review request for 8019623: Lack of synchronization in AppContext.getAppContext() In-Reply-To: <3D74E49D-1423-4955-9D55-3204F475124D@oracle.com> References: <524E851E.6020006@oracle.com> <3D74E49D-1423-4955-9D55-3204F475124D@oracle.com> Message-ID: <5254281B.4040203@oracle.com> On 10/8/2013 6:54 PM, Leonid Romanov wrote: > Hi, > I tried different variations of your suggestion and none of them worked. The reason is timing: suppose two threads, A and B, entered AppContetx.getAppContext() and then AppContext.initMainAppContext() at the same time. We need thread A to be able to initialize mainAppContext, return from initMainAppContext() and then initialize local variable with AppContext to be returned without thread B intervening in between. This just doesn't happen. This is perfectly expected, that the created regression test won't fail without your fix. It will still be useful to prevent regression in the future. Thanks, Artem > On Oct 4, 2013, at 1:06 PM, Artem Ananiev wrote: > >> Hi, Leonid, >> >> the fix looks fine. >> >> I believe it is possible to create a regression test for this fix. The test should create several thread groups and call AC.getAC() there, then check that all the returned AC's are equal. Although it won't 100% fail before your fix, it should 100% pass after it. What do you think about it? >> >> Thanks, >> >> Artem >> >> On 10/2/2013 6:22 PM, Leonid Romanov wrote: >>> Hello, >>> Please, review a fix for 8019623: Lack of synchronization in AppContext.getAppContext(). I don't think it makes sense to ensure that AppContext.getAppContext()/SunToolkit.createNewAppContext() is thread safe, because in practice we haven't had any problems with this combination. What we have had problems with is the getAppContext()/getAppContext() combination because of the double mainAppContext initialization. Therefore, the fix takes care of this issue. While I could have simply made the whole AppContext.getAppContext() method synchronized, I wanted the most common path through it (returning cached AppContext) to remain lock-free, so I decided to place the lock around the most critical part, where initMainAppContext() gets called. >>> As for a regression test, I couldn't find a way to detect double initMainAppContext initialization. We put newly created AppContexts into a thread-safe map, so whatever AppContext wins the race remains in the map, and the other is simply lost, without any convenient means to detect its existence. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8019623 >>> Webrev: http://cr.openjdk.java.net/~leonidr/8019623/webrev.00/ >>> >>> Thanks, >>> Leonid. >>> > From oleg.pekhovskiy at oracle.com Tue Oct 8 10:14:20 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Tue, 08 Oct 2013 21:14:20 +0400 Subject: [8] Review request for 8016356: Any swing frame resizes ugly. In-Reply-To: <5252A2C7.3080700@oracle.com> References: <5219FB56.6070700@oracle.com> <521B5619.7030705@oracle.com> <521D1BAE.2050908@oracle.com> <521F49C3.2040703@oracle.com> <5222DF79.4080007@oracle.com> <52528A26.1050006@oracle.com> <5252A2C7.3080700@oracle.com> Message-ID: <52543D6C.3010501@oracle.com> Hi Artem, Anthony, thank you for the review... I've added more details in the source code comments and bug comments, plus changed "else" location. Please review the next version of fix: http://cr.openjdk.java.net/~bagiras/8016356.3/ Thanks, Oleg On 07.10.2013 16:02, Artem Ananiev wrote: > Hi, Oleg, > > could you provide information (here and in bug comments), what are the > values returned by GetWindowRect() and getWindowPlacement(), while the > window is being snapped and after it has been snapped, please? > > Thanks, > > Artem > > On 10/7/2013 2:17 PM, Oleg Pekhovskiy wrote: >> Hi All, >> >> Please review the second version of fix >> http://cr.openjdk.java.net/~bagiras/8016356.2/ >> for >> http://bugs.sun.com/view_bug.do?bug_id=8016356 >> >> I found quite robust way to determine Windows Snap-feature that relies >> upon the difference between the real (GetWindowRect()) and the normal >> placement of the window (GetWindowPlacement()). >> When a window goes snapped the actual and normal rectangles are >> different. In this case WindowResized() method is called to send >> ComponentResized event and update window layout. >> >> This check was placed in the handler of WM_SYSCOMMAND message right >> after SIZE-MOVE loop that works inside AwtWindow::DefWindowProc(). >> >> Thanks, >> Oleg >> >> >> On 01.09.2013 10:32, Oleg Pekhovskiy wrote: >>> Hi Anthony, >>> >>> On 29.08.2013 17:16, Anthony Petrov wrote: >>>> Hi Oleg, >>>> >>>> On 08/28/13 01:35, Oleg Pekhovskiy wrote: >>>>> On 26.08.2013 17:20, Anthony Petrov wrote: >>>>>> The fix looks somewhat fragile to me. The sequence of events may >>>>>> change >>>>>> in a future version of Windows, and the fix will fail then. >>>>> >>>>> I agree, the fix is not elegant. >>>>> As for the future: I tested it on Windows 8.1 - it worked. >>>> >>>> I didn't mean *the* Win 8.1, I meant *a* future version. I suppose you >>>> can't test with Win 9 or Win 19 yet, can you? :) >>>> >>> >>> Sure, no guarantee... >>> >>>> >>>>>> Are there any peculiarities for the WM_SIZE messages being posted >>>>>> when a >>>>>> window is snapped? I'm referring to [1] for example, and they suggest >>>>>> that a proper SC_ flag might be specified when snapping occurs. >>>>>> So, if >>>>>> we could detect that, we might unblock the WindowResized() call at >>>>>> the >>>>>> end of the WmSize() method in the AwtWindow class, which would fix >>>>>> the >>>>>> issue. >>>>> >>>>> Unfortunately there is not direct way to determine the snapping. >>>>> My experience says not to play with sending system events manually on >>>>> Windows. That is much more fragile and nobody knows how >>>>> DefWindowProc() >>>>> would behave. >>>> >>>> I totally agree. >>>> >>>>> I chose WM_SYSCOMMAND handler in AwtWindow::WindowProc() because it's >>>>> synchronous during window resize (looping in >>>>> AwtWindow::DefWindowProc()) >>>>> So WindowResized() would be called only when the user releases mouse >>>>> button after resizing. But WM_SIZE message is called each time the >>>>> size >>>>> of the window is changed while resizing. >>>> >>>> Aren't the position/size of a window change noticeably greater from one >>>> WM_SIZE message to the next one when the snapping occurs, as opposed to >>>> normal resizing? Could we introduce a threshold and only call >>>> WindowResized from WmSize() if the size/position change is greater than >>>> the threshold? >>> >>> Unfortunately, that's impossible in, at least, to cases: >>> 1. The height of window is near the height of desktop, so snapping >>> increases the height of window just for a few pixels. >>> 2. The mouse is moved quite fast during the simple resizing (I got >100 >>> pixel increase for one WM_SIZE message). >>> >>>> >>>> I realize that such a solution is no more elegant than your original >>>> one, but at least it doesn't rely on a particular sequence of different >>>> messages, which may change in future versions of Windows. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>>> >>>>> You might also want to explore the WM_WINDOWPOSCHANGED and >>>>>> WM_WINDOWPOSCHANGING events that the window receives during snapping, >>>>>> perhaps they have some characteristics allowing us to ignore the >>>>>> IsResizing() and call the WindowResized() nonetheless. >>>>> >>>>> These messages are sent "as a result of a call to the SetWindowPos >>>>> function or another window-management function" and never appears >>>>> during >>>>> window resizing with the mouse. >>>>> >>>>>> >>>>>> [1] >>>>>> http://stackoverflow.com/questions/9321549/handling-aerosnap-message-in-wndproc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> This article is an attempt to handle maximize/restore snapping, but >>>>> this >>>>> issue deals with vertical snapping, when top or bottom edge of the >>>>> window moved to the corresponding edge of the screen. >>>>> >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 08/25/13 16:40, Oleg Pekhovskiy wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> please review the fix >>>>>>> http://cr.openjdk.java.net/~bagiras/8016356.1/ >>>>>>> for >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016356 >>>>>>> >>>>>>> Windows 7 has a feature that makes "window being automatically >>>>>>> arranged >>>>>>> when moved to the edge of the screen". And there is no specific >>>>>>> system >>>>>>> notification when that happens. From the other side AwtWindow class >>>>>>> has >>>>>>> some optimization algorithm for resizing that doesn't take into >>>>>>> account >>>>>>> such the arranging. I found indirect way to determine the >>>>>>> arranging by >>>>>>> tracking the sequence of WM_GETMINMAXINFO and WM_SIZE before the >>>>>>> end of >>>>>>> resizing routine, and call WindowResized() when needed to update the >>>>>>> layout. >>>>>>> >>>>>>> Thanks, >>>>>>> Oleg From anthony.petrov at oracle.com Tue Oct 8 10:30:35 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 08 Oct 2013 21:30:35 +0400 Subject: [8] Review request for 8016356: Any swing frame resizes ugly. In-Reply-To: <52543D6C.3010501@oracle.com> References: <5219FB56.6070700@oracle.com> <521B5619.7030705@oracle.com> <521D1BAE.2050908@oracle.com> <521F49C3.2040703@oracle.com> <5222DF79.4080007@oracle.com> <52528A26.1050006@oracle.com> <5252A2C7.3080700@oracle.com> <52543D6C.3010501@oracle.com> Message-ID: <5254413B.3050004@oracle.com> Looks fine to me. -- best regards, Anthony On 10/08/2013 09:14 PM, Oleg Pekhovskiy wrote: > Hi Artem, Anthony, > > thank you for the review... > > I've added more details in the source code comments and bug comments, > plus changed "else" location. > > Please review the next version of fix: > http://cr.openjdk.java.net/~bagiras/8016356.3/ > > Thanks, > Oleg > > On 07.10.2013 16:02, Artem Ananiev wrote: >> Hi, Oleg, >> >> could you provide information (here and in bug comments), what are the >> values returned by GetWindowRect() and getWindowPlacement(), while the >> window is being snapped and after it has been snapped, please? >> >> Thanks, >> >> Artem >> >> On 10/7/2013 2:17 PM, Oleg Pekhovskiy wrote: >>> Hi All, >>> >>> Please review the second version of fix >>> http://cr.openjdk.java.net/~bagiras/8016356.2/ >>> for >>> http://bugs.sun.com/view_bug.do?bug_id=8016356 >>> >>> I found quite robust way to determine Windows Snap-feature that relies >>> upon the difference between the real (GetWindowRect()) and the normal >>> placement of the window (GetWindowPlacement()). >>> When a window goes snapped the actual and normal rectangles are >>> different. In this case WindowResized() method is called to send >>> ComponentResized event and update window layout. >>> >>> This check was placed in the handler of WM_SYSCOMMAND message right >>> after SIZE-MOVE loop that works inside AwtWindow::DefWindowProc(). >>> >>> Thanks, >>> Oleg >>> >>> >>> On 01.09.2013 10:32, Oleg Pekhovskiy wrote: >>>> Hi Anthony, >>>> >>>> On 29.08.2013 17:16, Anthony Petrov wrote: >>>>> Hi Oleg, >>>>> >>>>> On 08/28/13 01:35, Oleg Pekhovskiy wrote: >>>>>> On 26.08.2013 17:20, Anthony Petrov wrote: >>>>>>> The fix looks somewhat fragile to me. The sequence of events may >>>>>>> change >>>>>>> in a future version of Windows, and the fix will fail then. >>>>>> >>>>>> I agree, the fix is not elegant. >>>>>> As for the future: I tested it on Windows 8.1 - it worked. >>>>> >>>>> I didn't mean *the* Win 8.1, I meant *a* future version. I suppose you >>>>> can't test with Win 9 or Win 19 yet, can you? :) >>>>> >>>> >>>> Sure, no guarantee... >>>> >>>>> >>>>>>> Are there any peculiarities for the WM_SIZE messages being posted >>>>>>> when a >>>>>>> window is snapped? I'm referring to [1] for example, and they >>>>>>> suggest >>>>>>> that a proper SC_ flag might be specified when snapping occurs. >>>>>>> So, if >>>>>>> we could detect that, we might unblock the WindowResized() call at >>>>>>> the >>>>>>> end of the WmSize() method in the AwtWindow class, which would fix >>>>>>> the >>>>>>> issue. >>>>>> >>>>>> Unfortunately there is not direct way to determine the snapping. >>>>>> My experience says not to play with sending system events manually on >>>>>> Windows. That is much more fragile and nobody knows how >>>>>> DefWindowProc() >>>>>> would behave. >>>>> >>>>> I totally agree. >>>>> >>>>>> I chose WM_SYSCOMMAND handler in AwtWindow::WindowProc() because it's >>>>>> synchronous during window resize (looping in >>>>>> AwtWindow::DefWindowProc()) >>>>>> So WindowResized() would be called only when the user releases mouse >>>>>> button after resizing. But WM_SIZE message is called each time the >>>>>> size >>>>>> of the window is changed while resizing. >>>>> >>>>> Aren't the position/size of a window change noticeably greater from >>>>> one >>>>> WM_SIZE message to the next one when the snapping occurs, as >>>>> opposed to >>>>> normal resizing? Could we introduce a threshold and only call >>>>> WindowResized from WmSize() if the size/position change is greater >>>>> than >>>>> the threshold? >>>> >>>> Unfortunately, that's impossible in, at least, to cases: >>>> 1. The height of window is near the height of desktop, so snapping >>>> increases the height of window just for a few pixels. >>>> 2. The mouse is moved quite fast during the simple resizing (I got >100 >>>> pixel increase for one WM_SIZE message). >>>> >>>>> >>>>> I realize that such a solution is no more elegant than your original >>>>> one, but at least it doesn't rely on a particular sequence of >>>>> different >>>>> messages, which may change in future versions of Windows. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>>> >>>>>> You might also want to explore the WM_WINDOWPOSCHANGED and >>>>>>> WM_WINDOWPOSCHANGING events that the window receives during >>>>>>> snapping, >>>>>>> perhaps they have some characteristics allowing us to ignore the >>>>>>> IsResizing() and call the WindowResized() nonetheless. >>>>>> >>>>>> These messages are sent "as a result of a call to the SetWindowPos >>>>>> function or another window-management function" and never appears >>>>>> during >>>>>> window resizing with the mouse. >>>>>> >>>>>>> >>>>>>> [1] >>>>>>> http://stackoverflow.com/questions/9321549/handling-aerosnap-message-in-wndproc >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> This article is an attempt to handle maximize/restore snapping, but >>>>>> this >>>>>> issue deals with vertical snapping, when top or bottom edge of the >>>>>> window moved to the corresponding edge of the screen. >>>>>> >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 08/25/13 16:40, Oleg Pekhovskiy wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> please review the fix >>>>>>>> http://cr.openjdk.java.net/~bagiras/8016356.1/ >>>>>>>> for >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016356 >>>>>>>> >>>>>>>> Windows 7 has a feature that makes "window being automatically >>>>>>>> arranged >>>>>>>> when moved to the edge of the screen". And there is no specific >>>>>>>> system >>>>>>>> notification when that happens. From the other side AwtWindow class >>>>>>>> has >>>>>>>> some optimization algorithm for resizing that doesn't take into >>>>>>>> account >>>>>>>> such the arranging. I found indirect way to determine the >>>>>>>> arranging by >>>>>>>> tracking the sequence of WM_GETMINMAXINFO and WM_SIZE before the >>>>>>>> end of >>>>>>>> resizing routine, and call WindowResized() when needed to update >>>>>>>> the >>>>>>>> layout. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Oleg From sergey.bylokhov at oracle.com Tue Oct 8 10:26:08 2013 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Tue, 08 Oct 2013 17:26:08 +0000 Subject: hg: jdk8/awt/jdk: 8022119: test api/javax_sound/sampled/spi/MixerProvider/indexTGF_MixerProviderTests fails Message-ID: <20131008172634.443F062E4B@hg.openjdk.java.net> Changeset: 0c06c38dfc3e Author: serb Date: 2013-10-08 21:24 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0c06c38dfc3e 8022119: test api/javax_sound/sampled/spi/MixerProvider/indexTGF_MixerProviderTests fails Reviewed-by: art, anthony ! src/share/classes/com/sun/media/sound/JSSecurityManager.java From sergey.bylokhov at oracle.com Tue Oct 8 12:36:53 2013 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Tue, 08 Oct 2013 19:36:53 +0000 Subject: hg: jdk8/awt/jdk: 8025603: Unused methods in the awt text peers should be removed Message-ID: <20131008193827.701DD62E54@hg.openjdk.java.net> Changeset: b218a14bdc8a Author: serb Date: 2013-10-08 23:34 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b218a14bdc8a 8025603: Unused methods in the awt text peers should be removed Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java ! src/windows/classes/sun/awt/windows/WButtonPeer.java ! src/windows/classes/sun/awt/windows/WCheckboxPeer.java ! src/windows/classes/sun/awt/windows/WChoicePeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WLabelPeer.java ! src/windows/classes/sun/awt/windows/WListPeer.java ! src/windows/classes/sun/awt/windows/WScrollbarPeer.java ! src/windows/classes/sun/awt/windows/WTextAreaPeer.java ! src/windows/classes/sun/awt/windows/WTextComponentPeer.java ! src/windows/classes/sun/awt/windows/WTextFieldPeer.java ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextField.cpp From christine.lu at oracle.com Tue Oct 8 13:33:05 2013 From: christine.lu at oracle.com (christine.lu at oracle.com) Date: Tue, 08 Oct 2013 13:33:05 -0700 Subject: Review request for JDK-8026021: more fix of javadoc errors and warnings reported by doclint In-Reply-To: <5253C7A2.9040604@oracle.com> References: <52536716.20908@oracle.com> <5253C7A2.9040604@oracle.com> Message-ID: <52546C01.9030901@oracle.com> Please see my comment inline. Anthony Petrov wrote: > Hi Christine, > > src/share/classes/java/awt/event/InputEvent.java >> - *

>> +     * 
{@code
>
> The {@code} is redundant here because the 
 tag forces the text to 
> use a fixed-size font already. Same comment for 
> src/share/classes/java/awt/font/LineBreakMeasurer.java.
>
Without {@code}, I will need to change & to &  because it is an 
error. I can simply change & to & then I don't need {@code

/hudson/jobs/jdk8-jdk-build-all/workspace/jdk/src/share/classes/java/awt/event/InputEvent.java:448: 
error: bad HTML entity
     *    if ((event.getModifiersEx() & (onmask | offmask)) == onmask) {
                                      ^
In my Crucible code review, Joe suggested to use {@code} so we can leave 
 >, <, & unchanged.
>
> src/share/classes/java/awt/event/MouseEvent.java
>> - * Component).  Due to platform-dependent Drag&Drop 
>> implementations,
>> + * Component).  Due to platform-dependent Drag&Drop 
>> implementations,
>
> Since you change this line anyway, I also suggest to replace  
> with {@code} here. Same comment for 
> src/share/classes/java/awt/font/NumericShaper.java.
For NumericShaper.java, if I change ...  to {@code ... }, 
it introduces 2 errors. If I only change & to & then it is fine.

NumericShaper.java:1215: error: unterminated inline tag
     *   {@code if ((shaper.getRanges() & shaper.ARABIC) != 0) { ... }
         ^
NumericShaper.java:1214: error: element not closed: blockquote
     * 
^ Thanks Christine > > > src/share/classes/java/awt/font/OpenType.java >> - * ( > href=http://www.microsoft.com/typography/otspec/">http://www.microsoft.com/typography/otspec/l >> ). >> + * ( > href="http://www.microsoft.com/typography/otspec/">http://www.microsoft.com/typography/otspec/l >> ). > > There's an extra 'l' character right before the closing , which > needs to be removed. > > -- > best regards, > Anthony > > On 10/08/2013 05:59 AM, christine.lu at oracle.com wrote: >> Hi, >> >> Please review a fix for >> >> https://bugs.openjdk.java.net/browse/JDK-8026021 >> more fix of javadoc errors and warnings reported by doclint, see the >> description >> >> webrev: http://cr.openjdk.java.net/~cl/8026021/webrev.00/ >> >> Thanks >> Christine >> >> From christine.lu at oracle.com Tue Oct 8 13:57:32 2013 From: christine.lu at oracle.com (christine.lu at oracle.com) Date: Tue, 08 Oct 2013 13:57:32 -0700 Subject: Review request for JDK-8026021: more fix of javadoc errors and warnings reported by doclint In-Reply-To: <5253D391.4010701@oracle.com> References: <52536716.20908@oracle.com> <5253C7A2.9040604@oracle.com> <5253D391.4010701@oracle.com> Message-ID: <525471BC.3000909@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131008/2106b15f/attachment.html From leonid.romanov at oracle.com Tue Oct 8 14:04:18 2013 From: leonid.romanov at oracle.com (leonid.romanov at oracle.com) Date: Tue, 08 Oct 2013 21:04:18 +0000 Subject: hg: jdk8/awt/jdk: 8004050: [macosx] The 'ESC' key does not work with jdk8 Message-ID: <20131008210448.1790462E62@hg.openjdk.java.net> Changeset: e591ac19174f Author: leonidr Date: 2013-10-09 01:03 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e591ac19174f 8004050: [macosx] The 'ESC' key does not work with jdk8 Reviewed-by: alexsch, serb ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java ! src/macosx/classes/com/apple/laf/AquaKeyBindings.java From anthony.petrov at oracle.com Wed Oct 9 01:24:48 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 09 Oct 2013 12:24:48 +0400 Subject: Review request for JDK-8026021: more fix of javadoc errors and warnings reported by doclint In-Reply-To: <525471BC.3000909@oracle.com> References: <52536716.20908@oracle.com> <5253C7A2.9040604@oracle.com> <5253D391.4010701@oracle.com> <525471BC.3000909@oracle.com> Message-ID: <525512D0.80808@oracle.com> Thanks for the comments and the corrections, Christine. The updated webrev looks fine to me. -- best regards, Anthony On 10/09/2013 12:57 AM, christine.lu at oracle.com wrote: > Thank you all for reviewing. I have posted a new webrev at > http://cr.openjdk.java.net/~cl/8026021/webrev.01 > > > Thanks > Christine > > > Sergey Bylokhov wrote: >> Hi Christine, >> Also looks like you fix include the fix for >> http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005699.html >> InputContext.java: >> If you look to the generated javadoc you'll see that now the space >> before list is not the same to the space after the list. So

from >> the beggining should be removed as well. >> >> On 10/8/13 12:51 PM, Anthony Petrov wrote: >>> Hi Christine, >>> >>> src/share/classes/java/awt/event/InputEvent.java >>>> - *

>>>> +     * 
{@code
>> I think not in this case. Since pre tag does not work with &
>> correctly. Probably pre can be removed here?
>> I n the NumericShaper.java I see that & was changed to the &
>> inside . I suppose it is not necessary and  can be changed
>> to {@code}
>> Same question about JTextComponent.java can we use {@code} tag for the
>> code instead of ≥
>>
>>>
>>> The {@code} is redundant here because the 
 tag forces the text
>>> to use a fixed-size font already. Same comment for
>>> src/share/classes/java/awt/font/LineBreakMeasurer.java.
>>>
>>>
>>> src/share/classes/java/awt/event/MouseEvent.java
>>>> - * Component). Due to platform-dependent Drag&Drop
>>>> implementations,
>>>> + * Component).  Due to platform-dependent
>>>> Drag&Drop implementations,
>>>
>>> Since you change this line anyway, I also suggest to replace 
>>> with {@code} here. Same comment for
>>> src/share/classes/java/awt/font/NumericShaper.java.
>>>
>>>
>>> src/share/classes/java/awt/font/OpenType.java
>>>> - * ( >>> href=http://www.microsoft.com/typography/otspec/">http://www.microsoft.com/typography/otspec/l
>>>> ).
>>>> + * ( >>> >http://www.microsoft.com/typography/otspec/l
>>>> ).
>>>
>>> There's an extra 'l' character right before the closing , which
>>> needs to be removed.
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 10/08/2013 05:59 AM, christine.lu at oracle.com
>>>  wrote:
>>>> Hi,
>>>>
>>>> Please review a fix for
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8026021
>>>> more fix of javadoc errors and warnings reported by doclint, see the
>>>> description
>>>>
>>>> webrev: http://cr.openjdk.java.net/~cl/8026021/webrev.00/
>>>> 
>>>>
>>>> Thanks
>>>> Christine
>>>>
>>>>
>>
>>
>> --
>> Best regards, Sergey.
>

From anthony.petrov at oracle.com  Wed Oct  9 01:50:04 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 09 Oct 2013 12:50:04 +0400
Subject:  [8] Review request for 7159266: [macosx]
 ApplicationDelegate should not be set in the headless mode
In-Reply-To: <524EA26A.20203@oracle.com>
References: <524EA26A.20203@oracle.com>
Message-ID: <525518BC.70005@oracle.com>

Hello,

This is a reminder.

--
best regards,
Anthony

On 10/04/2013 03:11 PM, Anthony Petrov wrote:
> Hello,
>
> This is another forward-port (a direct one this time) that didn't make
> it into JDK 8 yet:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-2224144
> webrev:
> http://cr.openjdk.java.net/~anthony/8-62-headlessAppDelegate-7159266.0/
>
> Summary of the fix: in headless mode the application delegate is useless
> because it's GUI-oriented. Hence we don't need to install it.
>
> Testing: I'm unable to test this fix because the related functionality
> in FX is currently broken (which is caused by a different issue).
> However, this is a direct forward-port of the same fix from 7u4 which
> has already been tested well in JDK 7, and hence I'm confident in the fix.
>
> --
> best regards,
> Anthony

From petr.pchelko at oracle.com  Wed Oct  9 01:54:17 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 9 Oct 2013 12:54:17 +0400
Subject:  [8] Review Request: JDK-8025588 [macosx] Frozen AppKit
	thread in 7u40
Message-ID: <7E2D8DE1-AF29-4C57-9D1D-154BD0E1B4B0@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8025588
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8025588/webrev.00/
The CCC request for public API changes was approved:
http://ccc.us.oracle.com/8025588

The problem:
Is some cases InvocationEvent was deleted from the EventQueue when it's source was disposed. If this InvocationEvent was created by the LWCToolkit.invokeAnWait, it never exited from the nested event loop, so the application frizzed. 

The solution:
Now when the InvocationEvent is removed it's disposed and the invokeAndWait mechanism gets notified and exits the nested event loop.

It's impossible to create a regression test here as the issue is very hard to reproduce.

With best regards. Petr.



From alexandr.scherbatiy at oracle.com  Wed Oct  9 02:42:02 2013
From: alexandr.scherbatiy at oracle.com (alexandr.scherbatiy at oracle.com)
Date: Wed, 09 Oct 2013 09:42:02 +0000
Subject:  hg: jdk8/awt/jdk: 8025649: need test to cover JDK-8000423
Message-ID: <20131009094239.2518B62E78@hg.openjdk.java.net>

Changeset: 2e59014ef38f
Author:    alexsch
Date:      2013-10-09 13:40 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2e59014ef38f

8025649: need test to cover JDK-8000423
Reviewed-by: anthony, serb
Contributed-by: Alexander Stepanov 

+ test/java/awt/InputMethods/DiacriticsTest/DiacriticsTest.html
+ test/java/awt/InputMethods/DiacriticsTest/DiacriticsTest.java


From artem.ananiev at oracle.com  Wed Oct  9 02:45:06 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Wed, 09 Oct 2013 13:45:06 +0400
Subject:  [8] Review request for 8016356: Any swing frame
 resizes ugly.
In-Reply-To: <52543D6C.3010501@oracle.com>
References: <5219FB56.6070700@oracle.com> <521B5619.7030705@oracle.com>
	<521D1BAE.2050908@oracle.com> <521F49C3.2040703@oracle.com>
	<5222DF79.4080007@oracle.com> <52528A26.1050006@oracle.com>
	<5252A2C7.3080700@oracle.com> <52543D6C.3010501@oracle.com>
Message-ID: <525525A2.9070804@oracle.com>


Looks fine.

Thanks,

Artem

On 10/8/2013 9:14 PM, Oleg Pekhovskiy wrote:
> Hi Artem, Anthony,
>
> thank you for the review...
>
> I've added more details in the source code comments and bug comments,
> plus changed "else" location.
>
> Please review the next version of fix:
> http://cr.openjdk.java.net/~bagiras/8016356.3/
>
> Thanks,
> Oleg
>
> On 07.10.2013 16:02, Artem Ananiev wrote:
>> Hi, Oleg,
>>
>> could you provide information (here and in bug comments), what are the
>> values returned by GetWindowRect() and getWindowPlacement(), while the
>> window is being snapped and after it has been snapped, please?
>>
>> Thanks,
>>
>> Artem
>>
>> On 10/7/2013 2:17 PM, Oleg Pekhovskiy wrote:
>>> Hi All,
>>>
>>> Please review the second version of fix
>>> http://cr.openjdk.java.net/~bagiras/8016356.2/
>>> for
>>> http://bugs.sun.com/view_bug.do?bug_id=8016356
>>>
>>> I found quite robust way to determine Windows Snap-feature that relies
>>> upon the difference between the real (GetWindowRect()) and the normal
>>> placement of the window (GetWindowPlacement()).
>>> When a window goes snapped the actual and normal rectangles are
>>> different. In this case WindowResized() method is called to send
>>> ComponentResized event and update window layout.
>>>
>>> This check was placed in the handler of WM_SYSCOMMAND message right
>>> after SIZE-MOVE loop that works inside AwtWindow::DefWindowProc().
>>>
>>> Thanks,
>>> Oleg
>>>
>>>
>>> On 01.09.2013 10:32, Oleg Pekhovskiy wrote:
>>>> Hi Anthony,
>>>>
>>>> On 29.08.2013 17:16, Anthony Petrov wrote:
>>>>> Hi Oleg,
>>>>>
>>>>> On 08/28/13 01:35, Oleg Pekhovskiy wrote:
>>>>>> On 26.08.2013 17:20, Anthony Petrov wrote:
>>>>>>> The fix looks somewhat fragile to me. The sequence of events may
>>>>>>> change
>>>>>>> in a future version of Windows, and the fix will fail then.
>>>>>>
>>>>>> I agree, the fix is not elegant.
>>>>>> As for the future: I tested it on Windows 8.1 - it worked.
>>>>>
>>>>> I didn't mean *the* Win 8.1, I meant *a* future version. I suppose you
>>>>> can't test with Win 9 or Win 19 yet, can you? :)
>>>>>
>>>>
>>>> Sure, no guarantee...
>>>>
>>>>>
>>>>>>> Are there any peculiarities for the WM_SIZE messages being posted
>>>>>>> when a
>>>>>>> window is snapped? I'm referring to [1] for example, and they
>>>>>>> suggest
>>>>>>> that a proper SC_ flag might be specified when snapping occurs.
>>>>>>> So, if
>>>>>>> we could detect that, we might unblock the WindowResized() call at
>>>>>>> the
>>>>>>> end of the WmSize() method in the AwtWindow class, which would fix
>>>>>>> the
>>>>>>> issue.
>>>>>>
>>>>>> Unfortunately there is not direct way to determine the snapping.
>>>>>> My experience says not to play with sending system events manually on
>>>>>> Windows. That is much more fragile and nobody knows how
>>>>>> DefWindowProc()
>>>>>> would behave.
>>>>>
>>>>> I totally agree.
>>>>>
>>>>>> I chose WM_SYSCOMMAND handler in AwtWindow::WindowProc() because it's
>>>>>> synchronous during window resize (looping in
>>>>>> AwtWindow::DefWindowProc())
>>>>>> So WindowResized() would be called only when the user releases mouse
>>>>>> button after resizing. But WM_SIZE message is called each time the
>>>>>> size
>>>>>> of the window is changed while resizing.
>>>>>
>>>>> Aren't the position/size of a window change noticeably greater from
>>>>> one
>>>>> WM_SIZE message to the next one when the snapping occurs, as
>>>>> opposed to
>>>>> normal resizing? Could we introduce a threshold and only call
>>>>> WindowResized from WmSize() if the size/position change is greater
>>>>> than
>>>>> the threshold?
>>>>
>>>> Unfortunately, that's impossible in, at least, to cases:
>>>> 1. The height of window is near the height of desktop, so snapping
>>>> increases the height of window just for a few pixels.
>>>> 2. The mouse is moved quite fast during the simple resizing (I got >100
>>>> pixel increase for one WM_SIZE message).
>>>>
>>>>>
>>>>> I realize that such a solution is no more elegant than your original
>>>>> one, but at least it doesn't rely on a particular sequence of
>>>>> different
>>>>> messages, which may change in future versions of Windows.
>>>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>>>
>>>>>> You might also want to explore the WM_WINDOWPOSCHANGED and
>>>>>>> WM_WINDOWPOSCHANGING events that the window receives during
>>>>>>> snapping,
>>>>>>> perhaps they have some characteristics allowing us to ignore the
>>>>>>> IsResizing() and call the WindowResized() nonetheless.
>>>>>>
>>>>>> These messages are sent "as a result of a call to the SetWindowPos
>>>>>> function or another window-management function" and never appears
>>>>>> during
>>>>>> window resizing with the mouse.
>>>>>>
>>>>>>>
>>>>>>> [1]
>>>>>>> http://stackoverflow.com/questions/9321549/handling-aerosnap-message-in-wndproc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> This article is an attempt to handle maximize/restore snapping, but
>>>>>> this
>>>>>> issue deals with vertical snapping, when top or bottom edge of the
>>>>>> window moved to the corresponding edge of the screen.
>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 08/25/13 16:40, Oleg Pekhovskiy wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> please review the fix
>>>>>>>> http://cr.openjdk.java.net/~bagiras/8016356.1/
>>>>>>>> for
>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016356
>>>>>>>>
>>>>>>>> Windows 7 has a feature that makes "window being automatically
>>>>>>>> arranged
>>>>>>>> when moved to the edge of the screen". And there is no specific
>>>>>>>> system
>>>>>>>> notification when that happens. From the other side AwtWindow class
>>>>>>>> has
>>>>>>>> some optimization algorithm for resizing that doesn't take into
>>>>>>>> account
>>>>>>>> such the arranging. I found indirect way to determine the
>>>>>>>> arranging by
>>>>>>>> tracking the sequence of WM_GETMINMAXINFO and WM_SIZE before the
>>>>>>>> end of
>>>>>>>> resizing routine, and call WindowResized() when needed to update
>>>>>>>> the
>>>>>>>> layout.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Oleg

From artem.ananiev at oracle.com  Wed Oct  9 03:12:14 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Wed, 09 Oct 2013 14:12:14 +0400
Subject:  [8] Review request for JDK-8022185 - JDK8 Fix Raw and
 unchecked warnings in classes belonging to java.awt.datatransfer
In-Reply-To: <52448F66.9050702@oracle.com>
References: <52377DC1.1090504@oracle.com> <524489C2.8040706@oracle.com>
	<1B1150E9-F9D4-4EC4-98F7-633389784CA2@oracle.com>
	<52448F66.9050702@oracle.com>
Message-ID: <52552BFE.5000601@oracle.com>


I put the updated webrev here:

http://cr.openjdk.java.net/~art/srikalyc/8022185.01/

A few comments:

1. DataFlavor.java: some of the lines got too long after the fix. 
Please, reformat or add import statements.

2. DataFlavor.java: there are some redundant class casts left, e.g. at 
line #334.

3. MimeTypeParameterList.java: after the fix, some of the class casts 
are redundant, e.g. (String)enum_.nextElement() or 
(String)parameters.get(key)

Thanks,

Artem

On 9/26/2013 11:47 PM, srikalyan chandrashekar wrote:
> Thanks Petr, I just made the fix and the webrev has been updated, please
> re download to see the changes.
>
> ---
> Thanks
> kalyan
>
> On 9/26/2013 12:36 PM, Petr Pchelko wrote:
>> Hello, Srikalyan.
>>
>> The SystemFlavorMap class was recently fixed by the following changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7cad8ef127a9
>> There was a severe bug which was fixed, and by the way the generics were added.
>>
>> So could you please remove your changes to this class from the webrev?
>>
>> With best regards. Petr.
>>
>> On Sep 26, 2013, at 11:23 PM, srikalyan chandrashekar  wrote:
>>
>>> Hi folks , a gentle reminder for review.
>>>
>>> ---
>>> Thanks
>>> kalyan
>>>
>>> On 9/16/2013 2:53 PM, srikalyan chandrashekar wrote:
>>>> Hi team ,  could someone review the fix
>>>>     Bug      : https://jbs.oracle.com/bugs/browse/JDK-8022185
>>>>     Webrev :
>>>> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.datatransfer.raw_unchecked_webrevwebrev.zip
>>>>
>>>>     Fix       :  raw and unchecked type warnings fix for
>>>> java.awt.datatransfer classes
>>>>
>

From oleg.pekhovskiy at oracle.com  Wed Oct  9 03:13:38 2013
From: oleg.pekhovskiy at oracle.com (oleg.pekhovskiy at oracle.com)
Date: Wed, 09 Oct 2013 10:13:38 +0000
Subject:  hg: jdk8/awt/jdk: 8016356: Any swing frame resizes ugly.
Message-ID: <20131009101355.4561662E7D@hg.openjdk.java.net>

Changeset: 84c766f6796b
Author:    bagiras
Date:      2013-10-09 14:12 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/84c766f6796b

8016356: Any swing frame resizes ugly.
Reviewed-by: art, anthony

! src/windows/native/sun/windows/awt_Window.cpp


From artem.ananiev at oracle.com  Wed Oct  9 03:19:33 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Wed, 09 Oct 2013 14:19:33 +0400
Subject:  [8] Review request for 7159266: [macosx]
 ApplicationDelegate should not be set in the headless mode
In-Reply-To: <525518BC.70005@oracle.com>
References: <524EA26A.20203@oracle.com> <525518BC.70005@oracle.com>
Message-ID: <52552DB5.8050106@oracle.com>


Looks fine.

Thanks,

Artem

On 10/9/2013 12:50 PM, Anthony Petrov wrote:
> Hello,
>
> This is a reminder.
>
> --
> best regards,
> Anthony
>
> On 10/04/2013 03:11 PM, Anthony Petrov wrote:
>> Hello,
>>
>> This is another forward-port (a direct one this time) that didn't make
>> it into JDK 8 yet:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-2224144
>> webrev:
>> http://cr.openjdk.java.net/~anthony/8-62-headlessAppDelegate-7159266.0/
>>
>> Summary of the fix: in headless mode the application delegate is useless
>> because it's GUI-oriented. Hence we don't need to install it.
>>
>> Testing: I'm unable to test this fix because the related functionality
>> in FX is currently broken (which is caused by a different issue).
>> However, this is a direct forward-port of the same fix from 7u4 which
>> has already been tested well in JDK 7, and hence I'm confident in the
>> fix.
>>
>> --
>> best regards,
>> Anthony

From artem.ananiev at oracle.com  Wed Oct  9 03:31:24 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Wed, 09 Oct 2013 14:31:24 +0400
Subject:  [8] Review Request: JDK-8025588 [macosx] Frozen
 AppKit thread in 7u40
In-Reply-To: <7E2D8DE1-AF29-4C57-9D1D-154BD0E1B4B0@oracle.com>
References: <7E2D8DE1-AF29-4C57-9D1D-154BD0E1B4B0@oracle.com>
Message-ID: <5255307C.9050707@oracle.com>

Hi, Petr,

a few comments:

1. Can InvocationEvent.notifier be final instead of volatile?

2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the 
public ctors call the private one directly? Right now there is an extra 
call from one public ctor to another, which then call the private one.

3. LWCToolkit.java: for backwards compatibility I suggest to replace 
"true" with "false" at line 562, so all the uncaught exceptions are 
thrown to the calling code, as it was before the fix.

Thanks,

Artem

On 10/9/2013 12:54 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8025588
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/8025588/webrev.00/
> The CCC request for public API changes was approved:
> http://ccc.us.oracle.com/8025588
>
> The problem:
> Is some cases InvocationEvent was deleted from the EventQueue when it's source was disposed. If this InvocationEvent was created by the LWCToolkit.invokeAnWait, it never exited from the nested event loop, so the application frizzed.
>
> The solution:
> Now when the InvocationEvent is removed it's disposed and the invokeAndWait mechanism gets notified and exits the nested event loop.
>
> It's impossible to create a regression test here as the issue is very hard to reproduce.
>
> With best regards. Petr.
>
>

From petr.pchelko at oracle.com  Wed Oct  9 03:48:49 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 9 Oct 2013 14:48:49 +0400
Subject:  [8] Review Request: JDK-8025588 [macosx] Frozen
	AppKit thread in 7u40
In-Reply-To: <5255307C.9050707@oracle.com>
References: <7E2D8DE1-AF29-4C57-9D1D-154BD0E1B4B0@oracle.com>
	<5255307C.9050707@oracle.com>
Message-ID: 

Hello, Anthony.

> 1. Can InvocationEvent.notifier be final instead of volatile?
It's protected, so it's a part of the public API. It is extremely unlikely someone would be broken by making this field final, but who knows..

> 2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the public ctors call the private one directly? Right now there is an extra call from one public ctor to another, which then call the private one.
I've update the fix.

> 3. LWCToolkit.java: for backwards compatibility I suggest to replace "true" with "false" at line 562, so all the uncaught exceptions are thrown to the calling code, as it was before the fix.
Actually I think the behaviour before the fix was a bug. If you look to the end of the invokeAndWait method (LWCToolkit:577-583) we are taking the exceptions from the InvocationEvent and rethrowing them as the IvocationTargetException. 
So originally the code was written with the intention to catch exceptions, but this was lost during the refactorings of this code (by me in JDK-8006634)

The updated fix is available here:
http://cr.openjdk.java.net/~pchelko/8025588/webrev.01/

With best regards. Petr.

On 09.10.2013, at 14:31, Artem Ananiev  wrote:

> Hi, Petr,
> 
> a few comments:
> 
> 1. Can InvocationEvent.notifier be final instead of volatile?
> 
> 2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the public ctors call the private one directly? Right now there is an extra call from one public ctor to another, which then call the private one.
> 
> 3. LWCToolkit.java: for backwards compatibility I suggest to replace "true" with "false" at line 562, so all the uncaught exceptions are thrown to the calling code, as it was before the fix.
> 
> Thanks,
> 
> Artem
> 
> On 10/9/2013 12:54 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8025588
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/8025588/webrev.00/
>> The CCC request for public API changes was approved:
>> http://ccc.us.oracle.com/8025588
>> 
>> The problem:
>> Is some cases InvocationEvent was deleted from the EventQueue when it's source was disposed. If this InvocationEvent was created by the LWCToolkit.invokeAnWait, it never exited from the nested event loop, so the application frizzed.
>> 
>> The solution:
>> Now when the InvocationEvent is removed it's disposed and the invokeAndWait mechanism gets notified and exits the nested event loop.
>> 
>> It's impossible to create a regression test here as the issue is very hard to reproduce.
>> 
>> With best regards. Petr.
>> 
>> 


From Sergey.Bylokhov at oracle.com  Wed Oct  9 04:17:44 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 09 Oct 2013 15:17:44 +0400
Subject:  [8] Review Request: JDK-8025588 [macosx] Frozen
 AppKit thread in 7u40
In-Reply-To: 
References: <7E2D8DE1-AF29-4C57-9D1D-154BD0E1B4B0@oracle.com>	<5255307C.9050707@oracle.com>
	
Message-ID: <52553B58.4070704@oracle.com>

Hi, Petr.
The fix looks good.

On 09.10.2013 14:48, Petr Pchelko wrote:
> Hello, Anthony.
>
>> 1. Can InvocationEvent.notifier be final instead of volatile?
> It's protected, so it's a part of the public API. It is extremely unlikely someone would be broken by making this field final, but who knows..
>
>> 2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the public ctors call the private one directly? Right now there is an extra call from one public ctor to another, which then call the private one.
> I've update the fix.
>
>> 3. LWCToolkit.java: for backwards compatibility I suggest to replace "true" with "false" at line 562, so all the uncaught exceptions are thrown to the calling code, as it was before the fix.
> Actually I think the behaviour before the fix was a bug. If you look to the end of the invokeAndWait method (LWCToolkit:577-583) we are taking the exceptions from the InvocationEvent and rethrowing them as the IvocationTargetException.
> So originally the code was written with the intention to catch exceptions, but this was lost during the refactorings of this code (by me in JDK-8006634)
>
> The updated fix is available here:
> http://cr.openjdk.java.net/~pchelko/8025588/webrev.01/
>
> With best regards. Petr.
>
> On 09.10.2013, at 14:31, Artem Ananiev  wrote:
>
>> Hi, Petr,
>>
>> a few comments:
>>
>> 1. Can InvocationEvent.notifier be final instead of volatile?
>>
>> 2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the public ctors call the private one directly? Right now there is an extra call from one public ctor to another, which then call the private one.
>>
>> 3. LWCToolkit.java: for backwards compatibility I suggest to replace "true" with "false" at line 562, so all the uncaught exceptions are thrown to the calling code, as it was before the fix.
>>
>> Thanks,
>>
>> Artem
>>
>> On 10/9/2013 12:54 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8025588
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/8025588/webrev.00/
>>> The CCC request for public API changes was approved:
>>> http://ccc.us.oracle.com/8025588
>>>
>>> The problem:
>>> Is some cases InvocationEvent was deleted from the EventQueue when it's source was disposed. If this InvocationEvent was created by the LWCToolkit.invokeAnWait, it never exited from the nested event loop, so the application frizzed.
>>>
>>> The solution:
>>> Now when the InvocationEvent is removed it's disposed and the invokeAndWait mechanism gets notified and exits the nested event loop.
>>>
>>> It's impossible to create a regression test here as the issue is very hard to reproduce.
>>>
>>> With best regards. Petr.
>>>
>>>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Oct  9 04:20:15 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 09 Oct 2013 15:20:15 +0400
Subject:  [8] Review request for 7159266: [macosx]
 ApplicationDelegate should not be set in the headless mode
In-Reply-To: <525518BC.70005@oracle.com>
References: <524EA26A.20203@oracle.com> <525518BC.70005@oracle.com>
Message-ID: <52553BEF.3080201@oracle.com>

Hi, Anthony.
The fix looks good.

On 09.10.2013 12:50, Anthony Petrov wrote:
> Hello,
>
> This is a reminder.
>
> -- 
> best regards,
> Anthony
>
> On 10/04/2013 03:11 PM, Anthony Petrov wrote:
>> Hello,
>>
>> This is another forward-port (a direct one this time) that didn't make
>> it into JDK 8 yet:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-2224144
>> webrev:
>> http://cr.openjdk.java.net/~anthony/8-62-headlessAppDelegate-7159266.0/
>>
>> Summary of the fix: in headless mode the application delegate is useless
>> because it's GUI-oriented. Hence we don't need to install it.
>>
>> Testing: I'm unable to test this fix because the related functionality
>> in FX is currently broken (which is caused by a different issue).
>> However, this is a direct forward-port of the same fix from 7u4 which
>> has already been tested well in JDK 7, and hence I'm confident in the 
>> fix.
>>
>> -- 
>> best regards,
>> Anthony


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Wed Oct  9 04:31:16 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 9 Oct 2013 15:31:16 +0400
Subject:  [8] Review Request: JDK-8025588 [macosx] Frozen
	AppKit thread in 7u40
In-Reply-To: <52553B58.4070704@oracle.com>
References: <7E2D8DE1-AF29-4C57-9D1D-154BD0E1B4B0@oracle.com>	<5255307C.9050707@oracle.com>
	
	<52553B58.4070704@oracle.com>
Message-ID: <91F422E5-F5B9-4F2D-9D1E-612A5FE6EA05@oracle.com>

Hello.

Thank you for the review, but I have a new version.
http://cr.openjdk.java.net/~pchelko/8025588/webrev.02/

In LWCToolkit we never throw an InterruptedException, so I've removed it from the method signature. But I forgot to remove it from the catch clauses in the places where the method is used.
This version fixes the problem.

With best regards. Petr.

On 09.10.2013, at 15:17, Sergey Bylokhov  wrote:

> Hi, Petr.
> The fix looks good.
> 
> On 09.10.2013 14:48, Petr Pchelko wrote:
>> Hello, Anthony.
>> 
>>> 1. Can InvocationEvent.notifier be final instead of volatile?
>> It's protected, so it's a part of the public API. It is extremely unlikely someone would be broken by making this field final, but who knows..
>> 
>>> 2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the public ctors call the private one directly? Right now there is an extra call from one public ctor to another, which then call the private one.
>> I've update the fix.
>> 
>>> 3. LWCToolkit.java: for backwards compatibility I suggest to replace "true" with "false" at line 562, so all the uncaught exceptions are thrown to the calling code, as it was before the fix.
>> Actually I think the behaviour before the fix was a bug. If you look to the end of the invokeAndWait method (LWCToolkit:577-583) we are taking the exceptions from the InvocationEvent and rethrowing them as the IvocationTargetException.
>> So originally the code was written with the intention to catch exceptions, but this was lost during the refactorings of this code (by me in JDK-8006634)
>> 
>> The updated fix is available here:
>> http://cr.openjdk.java.net/~pchelko/8025588/webrev.01/
>> 
>> With best regards. Petr.
>> 
>> On 09.10.2013, at 14:31, Artem Ananiev  wrote:
>> 
>>> Hi, Petr,
>>> 
>>> a few comments:
>>> 
>>> 1. Can InvocationEvent.notifier be final instead of volatile?
>>> 
>>> 2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the public ctors call the private one directly? Right now there is an extra call from one public ctor to another, which then call the private one.
>>> 
>>> 3. LWCToolkit.java: for backwards compatibility I suggest to replace "true" with "false" at line 562, so all the uncaught exceptions are thrown to the calling code, as it was before the fix.
>>> 
>>> Thanks,
>>> 
>>> Artem
>>> 
>>> On 10/9/2013 12:54 PM, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>> 
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8025588
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/8025588/webrev.00/
>>>> The CCC request for public API changes was approved:
>>>> http://ccc.us.oracle.com/8025588
>>>> 
>>>> The problem:
>>>> Is some cases InvocationEvent was deleted from the EventQueue when it's source was disposed. If this InvocationEvent was created by the LWCToolkit.invokeAnWait, it never exited from the nested event loop, so the application frizzed.
>>>> 
>>>> The solution:
>>>> Now when the InvocationEvent is removed it's disposed and the invokeAndWait mechanism gets notified and exits the nested event loop.
>>>> 
>>>> It's impossible to create a regression test here as the issue is very hard to reproduce.
>>>> 
>>>> With best regards. Petr.
>>>> 
>>>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From artem.ananiev at oracle.com  Wed Oct  9 04:35:57 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Wed, 09 Oct 2013 15:35:57 +0400
Subject:   javax.swing.RepaintManager volatileMap
In-Reply-To: <521E00B0.5080205@oracle.com>
References: 
	<521E00B0.5080205@oracle.com>
Message-ID: <52553F9D.6010400@oracle.com>

Hi, Vladimir,

have you received this reply, or it was lost for some reason?

Thanks,

Artem

On 8/28/2013 5:52 PM, Artem Ananiev wrote:
> Hi, Vladimir,
>
> I agree that using a class with no equals/hashCode overridden as a key
> for HashMap is not the best thing to do. However, in this case the
> problem seems to be caused by something else.
>
> I'm not an expert in RepaintManager, but here is what I observe:
>
> 1. When graphics environment changes, we get displayChanged()
> notification (it's not a public API yet, unfortunately).
>
> 2. RepaintManager.displayChanged() clears all the volatile images, as
> they depend on the GraphicsConfiguration objects and may be invalid
>
> 3. In clearImages(), we iterate through volatileMap and remove the
> images. Note that despite GraphicsConfiguration doesn't override
> equals/hashCode, iteration should still work.
>
> Anyway, it indeed looks like a bug, no matter of what it's caused by. Do
> you have a test case that can be used to reproduce it, other than to run
> JDeveloper?
>
> Thanks,
>
> Artem
>
> On 8/28/2013 3:00 PM, Vladimir Sitnikov wrote:
>> Hi,
>>
>> In the heapdump of SQL Developer 4.0 I found that RepaintManager holds
>> 23 items of sun.awt.image.BufImgVolatileSurfaceManager 5-10MiB each.
>>
>> All the images are contained in "volatileMap" HashMap.
>>
>> I identified that the key of the map is sun.awt.Win32GraphicsConfig and
>> that class does not override equals/hashCode.
>>
>> Can you please tell me if "using GraphicsConfig as a key knowing the
>> fact this key does not ovveride equals/hashCode" is intentional or not?
>>
>> I have checked several keys of the map (Win32GraphicsConfig) and they
>> have identical value (even screen and sTypeOrig references point to the
>> same objects), however as the Win32GraphicsConfig objects itself are
>> different java objects they occupy different entries in valueMap.
>>
>> --
>> Regards,
>> Vladimir Sitnikov

From Sergey.Bylokhov at oracle.com  Wed Oct  9 04:44:58 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 09 Oct 2013 15:44:58 +0400
Subject:  [8] Review Request: JDK-8025588 [macosx] Frozen
 AppKit thread in 7u40
In-Reply-To: <91F422E5-F5B9-4F2D-9D1E-612A5FE6EA05@oracle.com>
References: <7E2D8DE1-AF29-4C57-9D1D-154BD0E1B4B0@oracle.com>	<5255307C.9050707@oracle.com>
	
	<52553B58.4070704@oracle.com>
	<91F422E5-F5B9-4F2D-9D1E-612A5FE6EA05@oracle.com>
Message-ID: <525541BA.6080100@oracle.com>

Hi, Petr.
New version looks good as well.

On 09.10.2013 15:31, Petr Pchelko wrote:
> Hello.
>
> Thank you for the review, but I have a new version.
> http://cr.openjdk.java.net/~pchelko/8025588/webrev.02/
>
> In LWCToolkit we never throw an InterruptedException, so I've removed it from the method signature. But I forgot to remove it from the catch clauses in the places where the method is used.
> This version fixes the problem.
>
> With best regards. Petr.
>
> On 09.10.2013, at 15:17, Sergey Bylokhov  wrote:
>
>> Hi, Petr.
>> The fix looks good.
>>
>> On 09.10.2013 14:48, Petr Pchelko wrote:
>>> Hello, Anthony.
>>>
>>>> 1. Can InvocationEvent.notifier be final instead of volatile?
>>> It's protected, so it's a part of the public API. It is extremely unlikely someone would be broken by making this field final, but who knows..
>>>
>>>> 2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the public ctors call the private one directly? Right now there is an extra call from one public ctor to another, which then call the private one.
>>> I've update the fix.
>>>
>>>> 3. LWCToolkit.java: for backwards compatibility I suggest to replace "true" with "false" at line 562, so all the uncaught exceptions are thrown to the calling code, as it was before the fix.
>>> Actually I think the behaviour before the fix was a bug. If you look to the end of the invokeAndWait method (LWCToolkit:577-583) we are taking the exceptions from the InvocationEvent and rethrowing them as the IvocationTargetException.
>>> So originally the code was written with the intention to catch exceptions, but this was lost during the refactorings of this code (by me in JDK-8006634)
>>>
>>> The updated fix is available here:
>>> http://cr.openjdk.java.net/~pchelko/8025588/webrev.01/
>>>
>>> With best regards. Petr.
>>>
>>> On 09.10.2013, at 14:31, Artem Ananiev  wrote:
>>>
>>>> Hi, Petr,
>>>>
>>>> a few comments:
>>>>
>>>> 1. Can InvocationEvent.notifier be final instead of volatile?
>>>>
>>>> 2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the public ctors call the private one directly? Right now there is an extra call from one public ctor to another, which then call the private one.
>>>>
>>>> 3. LWCToolkit.java: for backwards compatibility I suggest to replace "true" with "false" at line 562, so all the uncaught exceptions are thrown to the calling code, as it was before the fix.
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> On 10/9/2013 12:54 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8025588
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/8025588/webrev.00/
>>>>> The CCC request for public API changes was approved:
>>>>> http://ccc.us.oracle.com/8025588
>>>>>
>>>>> The problem:
>>>>> Is some cases InvocationEvent was deleted from the EventQueue when it's source was disposed. If this InvocationEvent was created by the LWCToolkit.invokeAnWait, it never exited from the nested event loop, so the application frizzed.
>>>>>
>>>>> The solution:
>>>>> Now when the InvocationEvent is removed it's disposed and the invokeAndWait mechanism gets notified and exits the nested event loop.
>>>>>
>>>>> It's impossible to create a regression test here as the issue is very hard to reproduce.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>>
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Wed Oct  9 05:06:14 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 09 Oct 2013 16:06:14 +0400
Subject:  [8] Review Request: JDK-8025588 [macosx] Frozen
 AppKit thread in 7u40
In-Reply-To: <91F422E5-F5B9-4F2D-9D1E-612A5FE6EA05@oracle.com>
References: <7E2D8DE1-AF29-4C57-9D1D-154BD0E1B4B0@oracle.com>	<5255307C.9050707@oracle.com>
	
	<52553B58.4070704@oracle.com>
	<91F422E5-F5B9-4F2D-9D1E-612A5FE6EA05@oracle.com>
Message-ID: <525546B6.1060508@oracle.com>

Hi Petr,

The fix looks fine to me.

--
best regards,
Anthony

On 10/09/2013 03:31 PM, Petr Pchelko wrote:
> Hello.
>
> Thank you for the review, but I have a new version.
> http://cr.openjdk.java.net/~pchelko/8025588/webrev.02/
>
> In LWCToolkit we never throw an InterruptedException, so I've removed it from the method signature. But I forgot to remove it from the catch clauses in the places where the method is used.
> This version fixes the problem.
>
> With best regards. Petr.
>
> On 09.10.2013, at 15:17, Sergey Bylokhov  wrote:
>
>> Hi, Petr.
>> The fix looks good.
>>
>> On 09.10.2013 14:48, Petr Pchelko wrote:
>>> Hello, Anthony.
>>>
>>>> 1. Can InvocationEvent.notifier be final instead of volatile?
>>> It's protected, so it's a part of the public API. It is extremely unlikely someone would be broken by making this field final, but who knows..
>>>
>>>> 2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the public ctors call the private one directly? Right now there is an extra call from one public ctor to another, which then call the private one.
>>> I've update the fix.
>>>
>>>> 3. LWCToolkit.java: for backwards compatibility I suggest to replace "true" with "false" at line 562, so all the uncaught exceptions are thrown to the calling code, as it was before the fix.
>>> Actually I think the behaviour before the fix was a bug. If you look to the end of the invokeAndWait method (LWCToolkit:577-583) we are taking the exceptions from the InvocationEvent and rethrowing them as the IvocationTargetException.
>>> So originally the code was written with the intention to catch exceptions, but this was lost during the refactorings of this code (by me in JDK-8006634)
>>>
>>> The updated fix is available here:
>>> http://cr.openjdk.java.net/~pchelko/8025588/webrev.01/
>>>
>>> With best regards. Petr.
>>>
>>> On 09.10.2013, at 14:31, Artem Ananiev  wrote:
>>>
>>>> Hi, Petr,
>>>>
>>>> a few comments:
>>>>
>>>> 1. Can InvocationEvent.notifier be final instead of volatile?
>>>>
>>>> 2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the public ctors call the private one directly? Right now there is an extra call from one public ctor to another, which then call the private one.
>>>>
>>>> 3. LWCToolkit.java: for backwards compatibility I suggest to replace "true" with "false" at line 562, so all the uncaught exceptions are thrown to the calling code, as it was before the fix.
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> On 10/9/2013 12:54 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8025588
>>>>> The fix is available at:
>>>>> http://cr.openjdk.java.net/~pchelko/8025588/webrev.00/
>>>>> The CCC request for public API changes was approved:
>>>>> http://ccc.us.oracle.com/8025588
>>>>>
>>>>> The problem:
>>>>> Is some cases InvocationEvent was deleted from the EventQueue when it's source was disposed. If this InvocationEvent was created by the LWCToolkit.invokeAnWait, it never exited from the nested event loop, so the application frizzed.
>>>>>
>>>>> The solution:
>>>>> Now when the InvocationEvent is removed it's disposed and the invokeAndWait mechanism gets notified and exits the nested event loop.
>>>>>
>>>>> It's impossible to create a regression test here as the issue is very hard to reproduce.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>>>
>>
>>
>> --
>> Best regards, Sergey.
>>
>

From anthony.petrov at oracle.com  Wed Oct  9 04:35:46 2013
From: anthony.petrov at oracle.com (anthony.petrov at oracle.com)
Date: Wed, 09 Oct 2013 11:35:46 +0000
Subject:  hg: jdk8/awt/jdk: 7159266: [macosx] ApplicationDelegate
	should not be	set in the headless mode
Message-ID: <20131009113614.7913862E83@hg.openjdk.java.net>

Changeset: 929dc0915f8c
Author:    anthony
Date:      2013-10-09 15:34 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/929dc0915f8c

7159266: [macosx] ApplicationDelegate should not be set in the headless mode
Summary: Don't install ApplicationDelegate in headless mode
Reviewed-by: art, serb

! src/macosx/native/sun/awt/awt.m


From leonid.romanov at oracle.com  Wed Oct  9 05:32:59 2013
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Wed, 9 Oct 2013 16:32:59 +0400
Subject:  [8] Review request for 8019623: Lack of
	synchronization in AppContext.getAppContext()
In-Reply-To: <5254281B.4040203@oracle.com>
References: 
	<524E851E.6020006@oracle.com>
	<3D74E49D-1423-4955-9D55-3204F475124D@oracle.com>
	<5254281B.4040203@oracle.com>
Message-ID: 

Ok, here an updated webrev then, with the test added:

http://cr.openjdk.java.net/~leonidr/8019623/webrev.01/

On Oct 8, 2013, at 7:43 PM, Artem Ananiev  wrote:

> 
> On 10/8/2013 6:54 PM, Leonid Romanov wrote:
>> Hi,
>> I tried different variations of your suggestion and none of them worked. The reason is timing: suppose two threads, A and B, entered AppContetx.getAppContext() and then AppContext.initMainAppContext() at the same time. We need thread A to be able to initialize mainAppContext, return from initMainAppContext() and then initialize local variable with AppContext to be returned without thread B intervening in between. This just doesn't happen.
> 
> This is perfectly expected, that the created regression test won't fail without your fix. It will still be useful to prevent regression in the future.
> 
> Thanks,
> 
> Artem
> 
>> On Oct 4, 2013, at 1:06 PM, Artem Ananiev  wrote:
>> 
>>> Hi, Leonid,
>>> 
>>> the fix looks fine.
>>> 
>>> I believe it is possible to create a regression test for this fix. The test should create several thread groups and call AC.getAC() there, then check that all the returned AC's are equal. Although it won't 100% fail before your fix, it should 100% pass after it. What do you think about it?
>>> 
>>> Thanks,
>>> 
>>> Artem
>>> 
>>> On 10/2/2013 6:22 PM, Leonid Romanov wrote:
>>>> Hello,
>>>> Please, review a fix for 8019623: Lack of synchronization in AppContext.getAppContext(). I don't think it makes sense to ensure that AppContext.getAppContext()/SunToolkit.createNewAppContext() is thread safe, because in practice we haven't had any problems with this combination. What we have had problems with is the getAppContext()/getAppContext() combination because of the double mainAppContext initialization.  Therefore, the fix takes care of this issue. While I could have simply made the whole AppContext.getAppContext() method synchronized, I wanted the most common path through it (returning cached AppContext) to remain lock-free, so I decided to place the lock around the most critical part, where initMainAppContext() gets called.
>>>> As for a regression test, I couldn't find a way to detect double initMainAppContext initialization. We put newly created AppContexts into a thread-safe map, so whatever AppContext wins the race remains in the map, and the other is simply lost, without any convenient means to detect its existence.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8019623
>>>> Webrev: http://cr.openjdk.java.net/~leonidr/8019623/webrev.00/
>>>> 
>>>> Thanks,
>>>> Leonid.
>>>> 
>> 


From anthony.petrov at oracle.com  Wed Oct  9 05:53:50 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 09 Oct 2013 16:53:50 +0400
Subject:  [8] Review request for 8019623: Lack of
 synchronization in AppContext.getAppContext()
In-Reply-To: 
References: 
	<524E851E.6020006@oracle.com>
	<3D74E49D-1423-4955-9D55-3204F475124D@oracle.com>
	<5254281B.4040203@oracle.com>
	
Message-ID: <525551DE.8000509@oracle.com>

Quite unusual to start a name of a class (or a variable) with a verb 
("GetAppContextLock"), but otherwise the fix looks fine to me.

--
best regards,
Anthony

On 10/09/2013 04:32 PM, Leonid Romanov wrote:
> Ok, here an updated webrev then, with the test added:
>
> http://cr.openjdk.java.net/~leonidr/8019623/webrev.01/
>
> On Oct 8, 2013, at 7:43 PM, Artem Ananiev  wrote:
>
>>
>> On 10/8/2013 6:54 PM, Leonid Romanov wrote:
>>> Hi,
>>> I tried different variations of your suggestion and none of them worked. The reason is timing: suppose two threads, A and B, entered AppContetx.getAppContext() and then AppContext.initMainAppContext() at the same time. We need thread A to be able to initialize mainAppContext, return from initMainAppContext() and then initialize local variable with AppContext to be returned without thread B intervening in between. This just doesn't happen.
>>
>> This is perfectly expected, that the created regression test won't fail without your fix. It will still be useful to prevent regression in the future.
>>
>> Thanks,
>>
>> Artem
>>
>>> On Oct 4, 2013, at 1:06 PM, Artem Ananiev  wrote:
>>>
>>>> Hi, Leonid,
>>>>
>>>> the fix looks fine.
>>>>
>>>> I believe it is possible to create a regression test for this fix. The test should create several thread groups and call AC.getAC() there, then check that all the returned AC's are equal. Although it won't 100% fail before your fix, it should 100% pass after it. What do you think about it?
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> On 10/2/2013 6:22 PM, Leonid Romanov wrote:
>>>>> Hello,
>>>>> Please, review a fix for 8019623: Lack of synchronization in AppContext.getAppContext(). I don't think it makes sense to ensure that AppContext.getAppContext()/SunToolkit.createNewAppContext() is thread safe, because in practice we haven't had any problems with this combination. What we have had problems with is the getAppContext()/getAppContext() combination because of the double mainAppContext initialization.  Therefore, the fix takes care of this issue. While I could have simply made the whole AppContext.getAppContext() method synchronized, I wanted the most common path through it (returning cached AppContext) to remain lock-free, so I decided to place the lock around the most critical part, where initMainAppContext() gets called.
>>>>> As for a regression test, I couldn't find a way to detect double initMainAppContext initialization. We put newly created AppContexts into a thread-safe map, so whatever AppContext wins the race remains in the map, and the other is simply lost, without any convenient means to detect its existence.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8019623
>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/8019623/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Leonid.
>>>>>
>>>
>

From artem.ananiev at oracle.com  Wed Oct  9 07:04:20 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Wed, 09 Oct 2013 18:04:20 +0400
Subject:  [8] Review Request: JDK-8025588 [macosx] Frozen
 AppKit thread in 7u40
In-Reply-To: 
References: <7E2D8DE1-AF29-4C57-9D1D-154BD0E1B4B0@oracle.com>
	<5255307C.9050707@oracle.com>
	
Message-ID: <52556264.7010006@oracle.com>


On 10/9/2013 2:48 PM, Petr Pchelko wrote:
> Hello, Anthony.
>
>> 1. Can InvocationEvent.notifier be final instead of volatile?
> It's protected, so it's a part of the public API. It is extremely unlikely someone would be broken by making this field final, but who knows..
>
>> 2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the public ctors call the private one directly? Right now there is an extra call from one public ctor to another, which then call the private one.
> I've update the fix.
>
>> 3. LWCToolkit.java: for backwards compatibility I suggest to replace "true" with "false" at line 562, so all the uncaught exceptions are thrown to the calling code, as it was before the fix.
> Actually I think the behaviour before the fix was a bug. If you look to the end of the invokeAndWait method (LWCToolkit:577-583) we are taking the exceptions from the InvocationEvent and rethrowing them as the IvocationTargetException.
> So originally the code was written with the intention to catch exceptions, but this was lost during the refactorings of this code (by me in JDK-8006634)

OK, thanks for clarification.

The new version (.02) still looks fine.

Thanks,

Artem

> The updated fix is available here:
> http://cr.openjdk.java.net/~pchelko/8025588/webrev.01/
>
> With best regards. Petr.
>
> On 09.10.2013, at 14:31, Artem Ananiev  wrote:
>
>> Hi, Petr,
>>
>> a few comments:
>>
>> 1. Can InvocationEvent.notifier be final instead of volatile?
>>
>> 2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the public ctors call the private one directly? Right now there is an extra call from one public ctor to another, which then call the private one.
>>
>> 3. LWCToolkit.java: for backwards compatibility I suggest to replace "true" with "false" at line 562, so all the uncaught exceptions are thrown to the calling code, as it was before the fix.
>>
>> Thanks,
>>
>> Artem
>>
>> On 10/9/2013 12:54 PM, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8025588
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/8025588/webrev.00/
>>> The CCC request for public API changes was approved:
>>> http://ccc.us.oracle.com/8025588
>>>
>>> The problem:
>>> Is some cases InvocationEvent was deleted from the EventQueue when it's source was disposed. If this InvocationEvent was created by the LWCToolkit.invokeAnWait, it never exited from the nested event loop, so the application frizzed.
>>>
>>> The solution:
>>> Now when the InvocationEvent is removed it's disposed and the invokeAndWait mechanism gets notified and exits the nested event loop.
>>>
>>> It's impossible to create a regression test here as the issue is very hard to reproduce.
>>>
>>> With best regards. Petr.
>>>
>>>
>

From artem.ananiev at oracle.com  Wed Oct  9 07:10:32 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Wed, 09 Oct 2013 18:10:32 +0400
Subject:  [8] Review request for 8019623: Lack of
 synchronization in AppContext.getAppContext()
In-Reply-To: 
References: 
	<524E851E.6020006@oracle.com>
	<3D74E49D-1423-4955-9D55-3204F475124D@oracle.com>
	<5254281B.4040203@oracle.com>
	
Message-ID: <525563D8.1080504@oracle.com>


On 10/9/2013 4:32 PM, Leonid Romanov wrote:
> Ok, here an updated webrev then, with the test added:
>
> http://cr.openjdk.java.net/~leonidr/8019623/webrev.01/

The test looks fine, but NUM_TRIES is redundant: after the first run, 
mainAppContext is initialized, so it doesn't make sense to keep testing.

Thanks,

Artem

> On Oct 8, 2013, at 7:43 PM, Artem Ananiev  wrote:
>
>>
>> On 10/8/2013 6:54 PM, Leonid Romanov wrote:
>>> Hi,
>>> I tried different variations of your suggestion and none of them worked. The reason is timing: suppose two threads, A and B, entered AppContetx.getAppContext() and then AppContext.initMainAppContext() at the same time. We need thread A to be able to initialize mainAppContext, return from initMainAppContext() and then initialize local variable with AppContext to be returned without thread B intervening in between. This just doesn't happen.
>>
>> This is perfectly expected, that the created regression test won't fail without your fix. It will still be useful to prevent regression in the future.
>>
>> Thanks,
>>
>> Artem
>>
>>> On Oct 4, 2013, at 1:06 PM, Artem Ananiev  wrote:
>>>
>>>> Hi, Leonid,
>>>>
>>>> the fix looks fine.
>>>>
>>>> I believe it is possible to create a regression test for this fix. The test should create several thread groups and call AC.getAC() there, then check that all the returned AC's are equal. Although it won't 100% fail before your fix, it should 100% pass after it. What do you think about it?
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> On 10/2/2013 6:22 PM, Leonid Romanov wrote:
>>>>> Hello,
>>>>> Please, review a fix for 8019623: Lack of synchronization in AppContext.getAppContext(). I don't think it makes sense to ensure that AppContext.getAppContext()/SunToolkit.createNewAppContext() is thread safe, because in practice we haven't had any problems with this combination. What we have had problems with is the getAppContext()/getAppContext() combination because of the double mainAppContext initialization.  Therefore, the fix takes care of this issue. While I could have simply made the whole AppContext.getAppContext() method synchronized, I wanted the most common path through it (returning cached AppContext) to remain lock-free, so I decided to place the lock around the most critical part, where initMainAppContext() gets called.
>>>>> As for a regression test, I couldn't find a way to detect double initMainAppContext initialization. We put newly created AppContexts into a thread-safe map, so whatever AppContext wins the race remains in the map, and the other is simply lost, without any convenient means to detect its existence.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8019623
>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/8019623/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Leonid.
>>>>>
>>>
>

From petr.pchelko at oracle.com  Wed Oct  9 09:45:11 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 9 Oct 2013 20:45:11 +0400
Subject:  [8] Review Request: JDK-8026143 [macosx] Maximized state
	could be inconsistent between peer and frame
Message-ID: <550D0572-4A56-4016-A63D-A17A64058D53@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8026143
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8026143/webrev.00/

When the window is created and it's size is bigger/equal to the size of the screen, Cocoa implicitly sets the native zoomed state to true. In JDK-8007219 this state was made consistent with peer level, this fix makes peer-level state consistent with frame level.

With best regards. Petr.

From leonid.romanov at oracle.com  Wed Oct  9 09:59:29 2013
From: leonid.romanov at oracle.com (leonid.romanov at oracle.com)
Date: Wed, 09 Oct 2013 16:59:29 +0000
Subject:  hg: jdk8/awt/jdk: 8019623: Lack of synchronization
	in	AppContext.getAppContext()
Message-ID: <20131009170026.8D8A662E9C@hg.openjdk.java.net>

Changeset: 976e5f580124
Author:    leonidr
Date:      2013-10-09 20:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/976e5f580124

8019623: Lack of synchronization in AppContext.getAppContext()
Reviewed-by: anthony, art

! src/share/classes/sun/awt/AppContext.java
+ test/sun/awt/AppContext/MultiThread/MultiThreadTest.java


From leonid.romanov at oracle.com  Wed Oct  9 10:16:22 2013
From: leonid.romanov at oracle.com (leonid.romanov at oracle.com)
Date: Wed, 09 Oct 2013 17:16:22 +0000
Subject:  hg: jdk8/awt/jdk: 8016551: JMenuItem in
	WindowsLookAndFeel can't	paint default icons
Message-ID: <20131009171657.84DA362E9F@hg.openjdk.java.net>

Changeset: fba62451d705
Author:    leonidr
Date:      2013-10-09 21:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/fba62451d705

8016551: JMenuItem in WindowsLookAndFeel can't paint default icons
Reviewed-by: alexsch, serb

! src/share/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java
+ test/com/sun/java/swing/plaf/windows/8016551/bug8016551.java


From anthony.petrov at oracle.com  Wed Oct  9 11:20:33 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 09 Oct 2013 22:20:33 +0400
Subject:  [8] Review Request: JDK-8026143 [macosx] Maximized
 state could be inconsistent between peer and frame
In-Reply-To: <550D0572-4A56-4016-A63D-A17A64058D53@oracle.com>
References: <550D0572-4A56-4016-A63D-A17A64058D53@oracle.com>
Message-ID: <52559E71.2060204@oracle.com>

Hi Petr,

src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java:
>  577             if (!wasMaximized && isMaximized()) {
>  578                 deliverZoom(true);
>  579             } else if (target instanceof Frame) {

And other occurrences of deliverZoom: it looks like we call it for any 
CPlatofrmWindow instance, while the extended state is only tracked for 
Frame instances in public API in AWT. Do we have to manage the maximized 
state for Window or Dialog peers?

--
best regards,
Anthony

On 10/09/2013 08:45 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8026143
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/8026143/webrev.00/
>
> When the window is created and it's size is bigger/equal to the size of the screen, Cocoa implicitly sets the native zoomed state to true. In JDK-8007219 this state was made consistent with peer level, this fix makes peer-level state consistent with frame level.
>
> With best regards. Petr.
>

From srikalyan.chandrashekar at oracle.com  Wed Oct  9 11:22:33 2013
From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar)
Date: Wed, 09 Oct 2013 11:22:33 -0700
Subject:  [8] Review request for JDK-8022185 - JDK8 Fix Raw and
 unchecked warnings in classes belonging to java.awt.datatransfer
In-Reply-To: <52552BFE.5000601@oracle.com>
References: <52377DC1.1090504@oracle.com> <524489C2.8040706@oracle.com>
	<1B1150E9-F9D4-4EC4-98F7-633389784CA2@oracle.com>
	<52448F66.9050702@oracle.com> <52552BFE.5000601@oracle.com>
Message-ID: <52559EE9.2000604@oracle.com>

Thanks Artem, i have done the fixes, you can find the updated webrev at
the same location
.

---
Thanks
kalyan

On 10/9/2013 3:12 AM, Artem Ananiev wrote:
>
> I put the updated webrev here:
>
> http://cr.openjdk.java.net/~art/srikalyc/8022185.01/
>
> A few comments:
>
> 1. DataFlavor.java: some of the lines got too long after the fix.
> Please, reformat or add import statements.
>
> 2. DataFlavor.java: there are some redundant class casts left, e.g. at
> line #334.
>
> 3. MimeTypeParameterList.java: after the fix, some of the class casts
> are redundant, e.g. (String)enum_.nextElement() or
> (String)parameters.get(key)
>
> Thanks,
>
> Artem
>
> On 9/26/2013 11:47 PM, srikalyan chandrashekar wrote:
>> Thanks Petr, I just made the fix and the webrev has been updated, please
>> re download to see the changes.
>>
>> ---
>> Thanks
>> kalyan
>>
>> On 9/26/2013 12:36 PM, Petr Pchelko wrote:
>>> Hello, Srikalyan.
>>>
>>> The SystemFlavorMap class was recently fixed by the following
>>> changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7cad8ef127a9
>>> There was a severe bug which was fixed, and by the way the generics
>>> were added.
>>>
>>> So could you please remove your changes to this class from the webrev?
>>>
>>> With best regards. Petr.
>>>
>>> On Sep 26, 2013, at 11:23 PM, srikalyan chandrashekar
>>>  wrote:
>>>
>>>> Hi folks , a gentle reminder for review.
>>>>
>>>> ---
>>>> Thanks
>>>> kalyan
>>>>
>>>> On 9/16/2013 2:53 PM, srikalyan chandrashekar wrote:
>>>>> Hi team ,  could someone review the fix
>>>>>     Bug      : https://jbs.oracle.com/bugs/browse/JDK-8022185
>>>>>     Webrev :
>>>>> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.datatransfer.raw_unchecked_webrevwebrev.zip
>>>>>
>>>>>
>>>>>     Fix       :  raw and unchecked type warnings fix for
>>>>> java.awt.datatransfer classes
>>>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131009/001b699b/attachment-0001.html 

From Sergey.Bylokhov at oracle.com  Wed Oct  9 11:26:49 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 09 Oct 2013 22:26:49 +0400
Subject:  [8] Review Request: JDK-8026143 [macosx] Maximized
 state could be inconsistent between peer and frame
In-Reply-To: <550D0572-4A56-4016-A63D-A17A64058D53@oracle.com>
References: <550D0572-4A56-4016-A63D-A17A64058D53@oracle.com>
Message-ID: <52559FE9.7030700@oracle.com>

Hi, Petr.
Is it possible to track this state in the deliverMoveResizeEvent? and 
update the state of the frame accordingly?

On 09.10.2013 20:45, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8026143
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/8026143/webrev.00/
>
> When the window is created and it's size is bigger/equal to the size of the screen, Cocoa implicitly sets the native zoomed state to true. In JDK-8007219 this state was made consistent with peer level, this fix makes peer-level state consistent with frame level.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From srikalyan.chandrashekar at oracle.com  Wed Oct  9 11:37:26 2013
From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar)
Date: Wed, 09 Oct 2013 11:37:26 -0700
Subject:  [8] Review request for JDK-8025684 - Fix Raw and
 unchecked warnings java.awt.image classes
In-Reply-To: <524BEF41.2000304@oracle.com>
References: <524B43EF.4080603@oracle.com> <524BEF41.2000304@oracle.com>
Message-ID: <5255A266.6030201@oracle.com>

Hi Artem, i have done some changes (more redundant casts identified and
removed), please get the webrev from the same location again . Thanks
for your review.

---
Thanks
kalyan

On 10/2/2013 3:02 AM, Artem Ananiev wrote:
>
> java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to
> CC. Please, wait for at least one approval from Java2D team.
>
> For easier review, I put the webrev here:
>
> http://cr.openjdk.java.net/~art/srikalyc/8025684.00/
>
> It looks fine to me. There is one "unchecked" warning still left, at
> BufferedImage.java:645, it can be fixed by introducing a local
> variable and @SuppressWarnings("unchecked"), but I'm not sure it's
> worth doing.
>
> Thanks,
>
> Artem
>
> On 10/2/2013 1:51 AM, srikalyan chandrashekar wrote:
>> Hi team ,  could someone review the fix
>>      Bug      : https://bugs.openjdk.java.net/browse/JDK-8025684
>>      Webrev   :
>> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.image.raw_unchecked_webrev.zip
>>
>>
>>      Fix      : Raw and unchecked warnings in AWT image classes fixed
>>


From srikalyan.chandrashekar at oracle.com  Wed Oct  9 12:07:42 2013
From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar)
Date: Wed, 09 Oct 2013 12:07:42 -0700
Subject:  [8] Review request for JDK-8026071 - Fix raw warnings in
 java AWT geometry package
Message-ID: <5255A97E.2040902@oracle.com>

Hi team ,  could someone review the fix
    Bug      : https://bugs.openjdk.java.net/browse/JDK-8026071
    Webrev   :
https://github.com/srikalyc/JDKfixes/blob/master/java.awt.geom.raw.webrev.zip
    Fix      : Raw warnings in AWT geom classes fixed

*NOTE*: In java.awt.geom.Area.java , the inner class AreaIterator's
public constructor's signature has been changed and is only indirectly
exposed through a public method "PathIterator
getPathIterator(AffineTransform at)" which is harmless .

-- 

-- 
Thanks
kalyan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131009/f8926b44/attachment.html 

From christine.lu at oracle.com  Wed Oct  9 14:33:00 2013
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Wed, 09 Oct 2013 21:33:00 +0000
Subject:  hg: jdk8/awt/jdk: 8026021: more fix of javadoc errors and
	warnings	reported by doclint, see the description
Message-ID: <20131009213323.E326B62EB2@hg.openjdk.java.net>

Changeset: cea6ca16142e
Author:    cl
Date:      2013-10-09 14:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/cea6ca16142e

8026021: more fix of javadoc errors and warnings reported by doclint, see the description
Reviewed-by: anthony, serb

! src/share/classes/java/awt/GraphicsDevice.java
! src/share/classes/java/awt/GridBagLayout.java
! src/share/classes/java/awt/LinearGradientPaint.java
! src/share/classes/java/awt/RadialGradientPaint.java
! src/share/classes/java/awt/font/LineBreakMeasurer.java
! src/share/classes/java/awt/font/MultipleMaster.java
! src/share/classes/java/awt/font/NumericShaper.java
! src/share/classes/java/awt/font/OpenType.java
! src/share/classes/java/awt/geom/AffineTransform.java
! src/share/classes/java/awt/im/InputContext.java
! src/share/classes/javax/swing/Action.java
! src/share/classes/javax/swing/GroupLayout.java
! src/share/classes/javax/swing/text/JTextComponent.java
! src/share/classes/javax/swing/text/StyleConstants.java
! src/share/classes/javax/swing/text/html/HTMLDocument.java
! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java


From sergey.bylokhov at oracle.com  Wed Oct  9 15:44:43 2013
From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com)
Date: Wed, 09 Oct 2013 22:44:43 +0000
Subject:  hg: jdk8/awt/jdk: 7058662: AiffFileReader
	throws	java.lang.ArithmeticException: division by zero when
	frame size	is zero; ...
Message-ID: <20131009224457.CA17662EB3@hg.openjdk.java.net>

Changeset: 81ea6299230a
Author:    serb
Date:      2013-10-10 02:35 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/81ea6299230a

7058662: AiffFileReader throws java.lang.ArithmeticException: division by zero when frame size is zero
7058666: Unexpected exception in AU parser code
7058672: Unexpected exceptions and freezes in WAV parser code
Reviewed-by: prr

! src/share/classes/com/sun/media/sound/AiffFileReader.java
! src/share/classes/com/sun/media/sound/AuFileReader.java
! src/share/classes/com/sun/media/sound/WaveFileReader.java
+ test/javax/sound/sampled/FileReader/ReadersExceptions.java


From petr.pchelko at oracle.com  Thu Oct 10 00:38:47 2013
From: petr.pchelko at oracle.com (petr.pchelko at oracle.com)
Date: Thu, 10 Oct 2013 07:38:47 +0000
Subject:  hg: jdk8/awt/jdk: 8025588: [macosx] Frozen AppKit thread
	in 7u40
Message-ID: <20131010073941.26DD862ECA@hg.openjdk.java.net>

Changeset: 857d6f78f241
Author:    pchelko
Date:      2013-10-10 11:40 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/857d6f78f241

8025588: [macosx] Frozen AppKit thread in 7u40
Reviewed-by: anthony, art, serb

! src/macosx/classes/sun/lwawt/macosx/CInputMethod.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/event/InvocationEvent.java
! src/share/classes/sun/awt/AWTAccessor.java


From petr.pchelko at oracle.com  Thu Oct 10 00:56:12 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 10 Oct 2013 11:56:12 +0400
Subject:  [8] Review Request: JDK-8024864 [macosx] Problems with
	rendering of controls
Message-ID: <8778B49D-B8E0-4D94-A36B-B7A580CBBA78@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8024864
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8024864/webrev.00/

The problem: it's a hard-to-describe thread race. The main problem is the following: when we set the bounds of the frame they could be modified by the native system, so we reset them in notifyReshape. However, there are cases when the peer bounds, native bounds and frame bound get completely unsynchronized with each other. In those cases the rendering problems occur, because paint events are generated with wrong bounds. 
The solution is to only set peer's bounds in the callback from the native system and not set them in setBounds directly. This would fix the problem, because now the peer bounds and real native bounds are always synchronized and there's no time frame when the peers bounds are set to some different value which would then be updated by the native system.

With best regards. Petr.

From artem.ananiev at oracle.com  Thu Oct 10 02:15:33 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Thu, 10 Oct 2013 13:15:33 +0400
Subject:  [8] Review request for JDK-8025684 - Fix Raw and
 unchecked warnings java.awt.image classes
In-Reply-To: <5255A266.6030201@oracle.com>
References: <524B43EF.4080603@oracle.com> <524BEF41.2000304@oracle.com>
	<5255A266.6030201@oracle.com>
Message-ID: <52567035.9040301@oracle.com>


On 10/9/2013 10:37 PM, srikalyan chandrashekar wrote:
> Hi Artem, i have done some changes (more redundant casts identified and
> removed), please get the webrev from the same location again . Thanks
> for your review.

The webrev is updated:

http://cr.openjdk.java.net/~art/srikalyc/8025684.01/

I haven't see your replies to Jim's questions, have you seen his email?

Thanks,

Artem

> ---
> Thanks
> kalyan
>
> On 10/2/2013 3:02 AM, Artem Ananiev wrote:
>>
>> java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to
>> CC. Please, wait for at least one approval from Java2D team.
>>
>> For easier review, I put the webrev here:
>>
>> http://cr.openjdk.java.net/~art/srikalyc/8025684.00/
>>
>> It looks fine to me. There is one "unchecked" warning still left, at
>> BufferedImage.java:645, it can be fixed by introducing a local
>> variable and @SuppressWarnings("unchecked"), but I'm not sure it's
>> worth doing.
>>
>> Thanks,
>>
>> Artem
>>
>> On 10/2/2013 1:51 AM, srikalyan chandrashekar wrote:
>>> Hi team ,  could someone review the fix
>>>       Bug      : https://bugs.openjdk.java.net/browse/JDK-8025684
>>>       Webrev   :
>>> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.image.raw_unchecked_webrev.zip
>>>
>>>
>>>       Fix      : Raw and unchecked warnings in AWT image classes fixed
>>>
>

From Sergey.Bylokhov at oracle.com  Thu Oct 10 03:34:48 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Oct 2013 14:34:48 +0400
Subject:  [8] Review Request: JDK-8024864 [macosx] Problems
 with rendering of controls
In-Reply-To: <8778B49D-B8E0-4D94-A36B-B7A580CBBA78@oracle.com>
References: <8778B49D-B8E0-4D94-A36B-B7A580CBBA78@oracle.com>
Message-ID: <525682C8.2050105@oracle.com>

Hi, Petr.

315         Rectangle newBounds = new Rectangle(getBounds());

It is not necessary to create new Rectangle, because getBounds creates 
it too.

typo:

324so the peer wold be updated in the callback


On 10.10.2013 11:56, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8024864
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/8024864/webrev.00/
>
> The problem: it's a hard-to-describe thread race. The main problem is the following: when we set the bounds of the frame they could be modified by the native system, so we reset them in notifyReshape. However, there are cases when the peer bounds, native bounds and frame bound get completely unsynchronized with each other. In those cases the rendering problems occur, because paint events are generated with wrong bounds.
> The solution is to only set peer's bounds in the callback from the native system and not set them in setBounds directly. This would fix the problem, because now the peer bounds and real native bounds are always synchronized and there's no time frame when the peers bounds are set to some different value which would then be updated by the native system.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From leonid.romanov at oracle.com  Thu Oct 10 04:27:10 2013
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Thu, 10 Oct 2013 15:27:10 +0400
Subject:  [8] Review Request: JDK-8024864 [macosx] Problems
	with rendering of controls
In-Reply-To: <8778B49D-B8E0-4D94-A36B-B7A580CBBA78@oracle.com>
References: <8778B49D-B8E0-4D94-A36B-B7A580CBBA78@oracle.com>
Message-ID: 

There is "nativeBounds" field in CPlatformWindow. Can't we use it instead of adding yet another bounds in LWWindowPeer?

On 10.10.2013, at 11:56, Petr Pchelko  wrote:

> Hello, AWT Team.
> 
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8024864
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/8024864/webrev.00/
> 
> The problem: it's a hard-to-describe thread race. The main problem is the following: when we set the bounds of the frame they could be modified by the native system, so we reset them in notifyReshape. However, there are cases when the peer bounds, native bounds and frame bound get completely unsynchronized with each other. In those cases the rendering problems occur, because paint events are generated with wrong bounds. 
> The solution is to only set peer's bounds in the callback from the native system and not set them in setBounds directly. This would fix the problem, because now the peer bounds and real native bounds are always synchronized and there's no time frame when the peers bounds are set to some different value which would then be updated by the native system.
> 
> With best regards. Petr.


From andrei.eremeev at oracle.com  Thu Oct 10 04:05:07 2013
From: andrei.eremeev at oracle.com (andrei eremeev)
Date: Thu, 10 Oct 2013 15:05:07 +0400
Subject:  [8] Review Request: JDK-7002846 Fix for 6989505 may be
 incomplete
Message-ID: <525689E3.7070308@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-7002846
The fix is available at:
http://cr.openjdk.java.net/~yan/jdk-7002846/webrev.00/

The problem: WinAPI's function GetPixel returns incorrect value of not 
fully opaque pixel on Intel graphic card.
The idea of the fix is to use getPixels(x, y, 1, 1)[0] which gets pixels 
correctly. But this solution is 2 times slower than we had.

From petr.pchelko at oracle.com  Thu Oct 10 04:39:07 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 10 Oct 2013 15:39:07 +0400
Subject:  [8] Review Request: JDK-8024864 [macosx] Problems
	with rendering of controls
In-Reply-To: 
References: <8778B49D-B8E0-4D94-A36B-B7A580CBBA78@oracle.com>
	
Message-ID: 

Hello, Leonid.

> There is "nativeBounds" field in CPlatformWindow. Can't we use it instead of adding yet another bounds in LWWindowPeer?
We are not adding yet another bounds in LWWindowPeer, we are removing them (sysX, sysY, sysW and sysH).

The bounds we are updating belong to LWComponentPeer, so we cannot remove them. 
We also cannot override getSize and getBounds in LWWindowPeer to return bounds from CPlatformWindow, 
because it's not an only implementation of the PlatformWindow. So this fix is the only option I see.

With best regards. Petr.

On 10.10.2013, at 15:27, Leonid Romanov  wrote:

> There is "nativeBounds" field in CPlatformWindow. Can't we use it instead of adding yet another bounds in LWWindowPeer?
> 
> On 10.10.2013, at 11:56, Petr Pchelko  wrote:
> 
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8024864
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/8024864/webrev.00/
>> 
>> The problem: it's a hard-to-describe thread race. The main problem is the following: when we set the bounds of the frame they could be modified by the native system, so we reset them in notifyReshape. However, there are cases when the peer bounds, native bounds and frame bound get completely unsynchronized with each other. In those cases the rendering problems occur, because paint events are generated with wrong bounds. 
>> The solution is to only set peer's bounds in the callback from the native system and not set them in setBounds directly. This would fix the problem, because now the peer bounds and real native bounds are always synchronized and there's no time frame when the peers bounds are set to some different value which would then be updated by the native system.
>> 
>> With best regards. Petr.
> 


From leonid.romanov at oracle.com  Thu Oct 10 04:50:16 2013
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Thu, 10 Oct 2013 15:50:16 +0400
Subject:  [8] Review Request: JDK-8024864 [macosx] Problems
	with rendering of controls
In-Reply-To: 
References: <8778B49D-B8E0-4D94-A36B-B7A580CBBA78@oracle.com>
	
	
Message-ID: <25311137-1661-4082-A52A-6C3DF7FAEE3D@oracle.com>

Sorry, I'm a bit sleepy today. The fix looks good to me. 

On 10.10.2013, at 15:39, Petr Pchelko  wrote:

> Hello, Leonid.
> 
>> There is "nativeBounds" field in CPlatformWindow. Can't we use it instead of adding yet another bounds in LWWindowPeer?
> We are not adding yet another bounds in LWWindowPeer, we are removing them (sysX, sysY, sysW and sysH).
> 
> The bounds we are updating belong to LWComponentPeer, so we cannot remove them. 
> We also cannot override getSize and getBounds in LWWindowPeer to return bounds from CPlatformWindow, 
> because it's not an only implementation of the PlatformWindow. So this fix is the only option I see.
> 
> With best regards. Petr.
> 
> On 10.10.2013, at 15:27, Leonid Romanov  wrote:
> 
>> There is "nativeBounds" field in CPlatformWindow. Can't we use it instead of adding yet another bounds in LWWindowPeer?
>> 
>> On 10.10.2013, at 11:56, Petr Pchelko  wrote:
>> 
>>> Hello, AWT Team.
>>> 
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8024864
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/8024864/webrev.00/
>>> 
>>> The problem: it's a hard-to-describe thread race. The main problem is the following: when we set the bounds of the frame they could be modified by the native system, so we reset them in notifyReshape. However, there are cases when the peer bounds, native bounds and frame bound get completely unsynchronized with each other. In those cases the rendering problems occur, because paint events are generated with wrong bounds. 
>>> The solution is to only set peer's bounds in the callback from the native system and not set them in setBounds directly. This would fix the problem, because now the peer bounds and real native bounds are always synchronized and there's no time frame when the peers bounds are set to some different value which would then be updated by the native system.
>>> 
>>> With best regards. Petr.
>> 
> 


From yuri.nesterenko at oracle.com  Thu Oct 10 05:33:04 2013
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 10 Oct 2013 16:33:04 +0400
Subject:  [8] Review Request: JDK-8025824 [cleanup] Fix tidy errors
 and warnings in preformatted HTML files related to 2d/awt/swing
Message-ID: <52569E80.1060104@oracle.com>

Hi colleagues,

please review this fix for the RFE
https://bugs.openjdk.java.net/browse/JDK-8025824
See the webrev at
http://cr.openjdk.java.net/~yan/jdk-8025824/webrev.00

In the JDK-8025824 there are two files attached:
one with initial set of tidy warnings, and the second with warnings 
after this fix.
Visually, virtually nothing changed -- well, some
visible formatting errors were pointed by tidy and fixed.

Thanks,
-yan

From petr.pchelko at oracle.com  Thu Oct 10 06:45:50 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 10 Oct 2013 17:45:50 +0400
Subject:  [8] Review Request: JDK-8026143 [macosx] Maximized
	state could be inconsistent between peer and frame
In-Reply-To: <52559FE9.7030700@oracle.com>
References: <550D0572-4A56-4016-A63D-A17A64058D53@oracle.com>
	<52559FE9.7030700@oracle.com>
Message-ID: 

Hello, Sergey, Anthony.

Thank you for the review. I've updated the fix, the new version is available here:
http://cr.openjdk.java.net/~pchelko/8026143/webrev.01/

Sergey wrote:
> Is it possible to track this state in the deliverMoveResizeEvent? and update the state of the frame accordingly?
This was a great idea. It significantly simplified our implementation. windowShouldZoom method appears to be VERY unreliable, so checking the state every time the window is resized works much better.

Anthony wrote:
> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java:
>> 577             if (!wasMaximized && isMaximized()) {
>> 578                 deliverZoom(true);
>> 579             } else if (target instanceof Frame) {
> 
> And other occurrences of deliverZoom: it looks like we call it for any CPlatofrmWindow instance, while the extended state is only tracked for Frame instances in public API in AWT. Do we have to manage the maximized state for Window or Dialog peers?
Actually Dialog javadoc states that it should not receive WindowStateChanged events. 
Window javadoc does not say anything about it. So in the new version we deliver zoom events only to frames.

With best regards. Petr.

On 09.10.2013, at 22:26, Sergey Bylokhov  wrote:

> Hi, Petr.
> Is it possible to track this state in the deliverMoveResizeEvent? and update the state of the frame accordingly?
> 
> On 09.10.2013 20:45, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8026143
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/8026143/webrev.00/
>> 
>> When the window is created and it's size is bigger/equal to the size of the screen, Cocoa implicitly sets the native zoomed state to true. In JDK-8007219 this state was made consistent with peer level, this fix makes peer-level state consistent with frame level.
>> 
>> With best regards. Petr.
> 
> 
> -- 
> Best regards, Sergey.
> 


From petr.pchelko at oracle.com  Thu Oct 10 06:50:59 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 10 Oct 2013 17:50:59 +0400
Subject:  [8] Review Request: JDK-8024864 [macosx] Problems
	with rendering of controls
In-Reply-To: <525682C8.2050105@oracle.com>
References: <8778B49D-B8E0-4D94-A36B-B7A580CBBA78@oracle.com>
	<525682C8.2050105@oracle.com>
Message-ID: <79437410-6882-4FE5-8D14-2477B431F954@oracle.com>

Hello, Sergey.

I've updated the fix according to your comments:
http://cr.openjdk.java.net/~pchelko/8024864/webrev.01/

With best regards. Petr.

On 10.10.2013, at 14:34, Sergey Bylokhov  wrote:

> Hi, Petr.
> 
> 315         Rectangle newBounds = new Rectangle(getBounds());
> 
> It is not necessary to create new Rectangle, because getBounds creates it too.
> 
> typo:
> 
> 324so the peer wold be updated in the callback
> 
> 
> On 10.10.2013 11:56, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8024864
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/8024864/webrev.00/
>> 
>> The problem: it's a hard-to-describe thread race. The main problem is the following: when we set the bounds of the frame they could be modified by the native system, so we reset them in notifyReshape. However, there are cases when the peer bounds, native bounds and frame bound get completely unsynchronized with each other. In those cases the rendering problems occur, because paint events are generated with wrong bounds.
>> The solution is to only set peer's bounds in the callback from the native system and not set them in setBounds directly. This would fix the problem, because now the peer bounds and real native bounds are always synchronized and there's no time frame when the peers bounds are set to some different value which would then be updated by the native system.
>> 
>> With best regards. Petr.
> 
> 
> -- 
> Best regards, Sergey.
> 


From Sergey.Bylokhov at oracle.com  Thu Oct 10 06:52:37 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Oct 2013 17:52:37 +0400
Subject:  [8] Review Request: JDK-8024864 [macosx] Problems
 with rendering of controls
In-Reply-To: <79437410-6882-4FE5-8D14-2477B431F954@oracle.com>
References: <8778B49D-B8E0-4D94-A36B-B7A580CBBA78@oracle.com>
	<525682C8.2050105@oracle.com>
	<79437410-6882-4FE5-8D14-2477B431F954@oracle.com>
Message-ID: <5256B125.5030405@oracle.com>

Hi, Petr.
The fix looks good.

On 10.10.2013 17:50, Petr Pchelko wrote:
> Hello, Sergey.
>
> I've updated the fix according to your comments:
> http://cr.openjdk.java.net/~pchelko/8024864/webrev.01/
>
> With best regards. Petr.
>
> On 10.10.2013, at 14:34, Sergey Bylokhov  wrote:
>
>> Hi, Petr.
>>
>> 315         Rectangle newBounds = new Rectangle(getBounds());
>>
>> It is not necessary to create new Rectangle, because getBounds creates it too.
>>
>> typo:
>>
>> 324so the peer wold be updated in the callback
>>
>>
>> On 10.10.2013 11:56, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8024864
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/8024864/webrev.00/
>>>
>>> The problem: it's a hard-to-describe thread race. The main problem is the following: when we set the bounds of the frame they could be modified by the native system, so we reset them in notifyReshape. However, there are cases when the peer bounds, native bounds and frame bound get completely unsynchronized with each other. In those cases the rendering problems occur, because paint events are generated with wrong bounds.
>>> The solution is to only set peer's bounds in the callback from the native system and not set them in setBounds directly. This would fix the problem, because now the peer bounds and real native bounds are always synchronized and there's no time frame when the peers bounds are set to some different value which would then be updated by the native system.
>>>
>>> With best regards. Petr.
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Oct 10 06:58:33 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Oct 2013 17:58:33 +0400
Subject:  [8] Review Request: JDK-8026143 [macosx] Maximized
 state could be inconsistent between peer and frame
In-Reply-To: 
References: <550D0572-4A56-4016-A63D-A17A64058D53@oracle.com>
	<52559FE9.7030700@oracle.com>
	
Message-ID: <5256B289.7060607@oracle.com>

Hi, Petr.
The fix looks good.

On 10.10.2013 17:45, Petr Pchelko wrote:
> Hello, Sergey, Anthony.
>
> Thank you for the review. I've updated the fix, the new version is available here:
> http://cr.openjdk.java.net/~pchelko/8026143/webrev.01/
>
> Sergey wrote:
>> Is it possible to track this state in the deliverMoveResizeEvent? and update the state of the frame accordingly?
> This was a great idea. It significantly simplified our implementation. windowShouldZoom method appears to be VERY unreliable, so checking the state every time the window is resized works much better.
>
> Anthony wrote:
>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java:
>>> 577             if (!wasMaximized && isMaximized()) {
>>> 578                 deliverZoom(true);
>>> 579             } else if (target instanceof Frame) {
>> And other occurrences of deliverZoom: it looks like we call it for any CPlatofrmWindow instance, while the extended state is only tracked for Frame instances in public API in AWT. Do we have to manage the maximized state for Window or Dialog peers?
> Actually Dialog javadoc states that it should not receive WindowStateChanged events.
> Window javadoc does not say anything about it. So in the new version we deliver zoom events only to frames.
>
> With best regards. Petr.
>
> On 09.10.2013, at 22:26, Sergey Bylokhov  wrote:
>
>> Hi, Petr.
>> Is it possible to track this state in the deliverMoveResizeEvent? and update the state of the frame accordingly?
>>
>> On 09.10.2013 20:45, Petr Pchelko wrote:
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8026143
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/8026143/webrev.00/
>>>
>>> When the window is created and it's size is bigger/equal to the size of the screen, Cocoa implicitly sets the native zoomed state to true. In JDK-8007219 this state was made consistent with peer level, this fix makes peer-level state consistent with frame level.
>>>
>>> With best regards. Petr.
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Thu Oct 10 07:10:37 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 10 Oct 2013 18:10:37 +0400
Subject:  [8] Review Request: JDK-8026143 [macosx] Maximized
 state could be inconsistent between peer and frame
In-Reply-To: <5256B289.7060607@oracle.com>
References: <550D0572-4A56-4016-A63D-A17A64058D53@oracle.com>	<52559FE9.7030700@oracle.com>	
	<5256B289.7060607@oracle.com>
Message-ID: <5256B55D.2050204@oracle.com>

+1. Looks great.

--
best regards,
Anthony

On 10/10/13 17:58, Sergey Bylokhov wrote:
> Hi, Petr.
> The fix looks good.
>
> On 10.10.2013 17:45, Petr Pchelko wrote:
>> Hello, Sergey, Anthony.
>>
>> Thank you for the review. I've updated the fix, the new version is
>> available here:
>> http://cr.openjdk.java.net/~pchelko/8026143/webrev.01/
>>
>> Sergey wrote:
>>> Is it possible to track this state in the deliverMoveResizeEvent? and
>>> update the state of the frame accordingly?
>> This was a great idea. It significantly simplified our implementation.
>> windowShouldZoom method appears to be VERY unreliable, so checking the
>> state every time the window is resized works much better.
>>
>> Anthony wrote:
>>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java:
>>>> 577 if (!wasMaximized && isMaximized()) {
>>>> 578 deliverZoom(true);
>>>> 579 } else if (target instanceof Frame) {
>>> And other occurrences of deliverZoom: it looks like we call it for
>>> any CPlatofrmWindow instance, while the extended state is only
>>> tracked for Frame instances in public API in AWT. Do we have to
>>> manage the maximized state for Window or Dialog peers?
>> Actually Dialog javadoc states that it should not receive
>> WindowStateChanged events.
>> Window javadoc does not say anything about it. So in the new version
>> we deliver zoom events only to frames.
>>
>> With best regards. Petr.
>>
>> On 09.10.2013, at 22:26, Sergey Bylokhov 
>> wrote:
>>
>>> Hi, Petr.
>>> Is it possible to track this state in the deliverMoveResizeEvent? and
>>> update the state of the frame accordingly?
>>>
>>> On 09.10.2013 20:45, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>>
>>>> Please review the fix for the issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8026143
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/8026143/webrev.00/
>>>>
>>>> When the window is created and it's size is bigger/equal to the size
>>>> of the screen, Cocoa implicitly sets the native zoomed state to
>>>> true. In JDK-8007219 this state was made consistent with peer level,
>>>> this fix makes peer-level state consistent with frame level.
>>>>
>>>> With best regards. Petr.
>>>
>>> --
>>> Best regards, Sergey.
>>>
>
>

From petr.pchelko at oracle.com  Thu Oct 10 07:19:23 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Thu, 10 Oct 2013 18:19:23 +0400
Subject:  [8] Review Request: JDK-8024329 [macosx]
	JRadioButtonMenuItem behaves like a checkbox when using the
	ScreenMenuBar
Message-ID: 

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8024329
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8024329/webrev.00/

The problem: for AWT menu the peer should update the menu item state unconditionally. However for the Swing menu items used in screen menubar swing should decide wether to update the state or not. So we should not unconditionally update the sate.
There's no regression test as there's no way to understand if the native menu item is checked or not.

With best regards. Petr.

From petr.pchelko at oracle.com  Thu Oct 10 08:25:51 2013
From: petr.pchelko at oracle.com (petr.pchelko at oracle.com)
Date: Thu, 10 Oct 2013 15:25:51 +0000
Subject:  hg: jdk8/awt/jdk: 8024864: [macosx] Problems with
	rendering of	controls
Message-ID: <20131010152701.8019762EFD@hg.openjdk.java.net>

Changeset: 31a156bae7cb
Author:    pchelko
Date:      2013-10-10 19:27 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/31a156bae7cb

8024864: [macosx] Problems with rendering of controls
Reviewed-by: serb, leonidr

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
+ test/java/awt/Paint/bug8024864.java


From petr.pchelko at oracle.com  Fri Oct 11 00:48:32 2013
From: petr.pchelko at oracle.com (petr.pchelko at oracle.com)
Date: Fri, 11 Oct 2013 07:48:32 +0000
Subject:  hg: jdk8/awt/jdk: 8026143: [macosx] Maximized state could
	be	inconsistent between peer and frame
Message-ID: <20131011074943.03AEF62F62@hg.openjdk.java.net>

Changeset: de36486eadd2
Author:    pchelko
Date:      2013-10-11 11:48 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/de36486eadd2

8026143: [macosx] Maximized state could be inconsistent between peer and frame
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.m
+ test/java/awt/Frame/MaximizedByPlatform/MaximizedByPlatform.java


From petr.pchelko at oracle.com  Fri Oct 11 01:59:06 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 11 Oct 2013 12:59:06 +0400
Subject:  [8] Review Request: JDK-8026262 NPE in
	SystemFlavorMap.getAllNativesForType - regression in jdk8
	b110 by fix of #JDK-8024987
Message-ID: 

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8026262
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8026262/webrev.00/

The cause is a forgotten null check in the JDK-8024987 fix. When we try to find all known natives for a type the flavour-to-native cache could not contain some data flavours yet, 
so we are getting a null as a list of corresponding mime-types. It's a valid situation, so a simple null check fixes the problem. The cache will be updated later when the getNativesForFlavour
method will finish.

The fix was tested with the case described in a netbeans bug: without the fix I fail to DnD a file from Krusader file manager, with a fix I can drag it successfully.

With best regards. Petr.

From petr.pchelko at oracle.com  Fri Oct 11 02:35:32 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 11 Oct 2013 13:35:32 +0400
Subject:  [8] Review Request: JDK-8024329 [macosx]
	JRadioButtonMenuItem behaves like a checkbox when using the
	ScreenMenuBar
In-Reply-To: 
References: 
Message-ID: 

Hello, AWT Team.

Please review the new version of the fix:
http://cr.openjdk.java.net/~pchelko/8024329/webrev.01/

This version of the fix does not expose the package-private class com.apple.laf.ScreenMenuItemCheckbox
Instead we override the setState method to no-op and force the setState only when it's really needed.

With best regards. Petr.

On 10.10.2013, at 18:19, Petr Pchelko  wrote:

> Hello, AWT Team.
> 
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8024329
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/8024329/webrev.00/
> 
> The problem: for AWT menu the peer should update the menu item state unconditionally. However for the Swing menu items used in screen menubar swing should decide wether to update the state or not. So we should not unconditionally update the sate.
> There's no regression test as there's no way to understand if the native menu item is checked or not.
> 
> With best regards. Petr.


From artem.ananiev at oracle.com  Fri Oct 11 03:42:23 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Fri, 11 Oct 2013 14:42:23 +0400
Subject:  [8] Review Request: JDK-8026262 NPE in
 SystemFlavorMap.getAllNativesForType - regression in jdk8 b110 by fix of
 #JDK-8024987
In-Reply-To: 
References: 
Message-ID: <5257D60F.5000102@oracle.com>


Looks fine.

Thanks,

Artem

On 10/11/2013 12:59 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8026262
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/8026262/webrev.00/
>
> The cause is a forgotten null check in the JDK-8024987 fix. When we try to find all known natives for a type the flavour-to-native cache could not contain some data flavours yet,
> so we are getting a null as a list of corresponding mime-types. It's a valid situation, so a simple null check fixes the problem. The cache will be updated later when the getNativesForFlavour
> method will finish.
>
> The fix was tested with the case described in a netbeans bug: without the fix I fail to DnD a file from Krusader file manager, with a fix I can drag it successfully.
>
> With best regards. Petr.
>

From konstantin.shefov at oracle.com  Fri Oct 11 03:54:15 2013
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 11 Oct 2013 14:54:15 +0400
Subject:  [8] Review request for CR 7124338 [macosx] Selection
 lost if a selected item removed from a java.awt.List
In-Reply-To: <5242A110.2070707@oracle.com>
References: <52418F16.2010608@oracle.com> <5242A110.2070707@oracle.com>
Message-ID: <5257D8D7.50506@oracle.com>

Please, review the fix
On 25-Sep-13 12:38, Anthony Petrov wrote:
> Looks good to me.
>
> -- 
> best regards,
> Anthony
>
> On 09/24/2013 05:09 PM, Konstantin Shefov wrote:
>> Hello,
>>
>> Please review a fix for the issue:
>>
>> 7124338 [macosx] Selection lost if a selected item removed from a
>> java.awt.List
>>
>> Test bug fix. Move from closed repo.
>>
>> http://bugs.sun.com/view_bug.do?bug_id=7124338
>>
>> The webrev is: http://cr.openjdk.java.net/~kshefov/7124338/webrev.00  -
>> add to open repo.
>> http://cr.openjdk.java.net/~kshefov/7124338/webrev.diff - diff with
>> previous version of the test.
>>
>> Thanks,
>> Konstantin


From Sergey.Bylokhov at oracle.com  Fri Oct 11 03:59:25 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 11 Oct 2013 14:59:25 +0400
Subject:  [8] Review Request: JDK-8026262 NPE in
 SystemFlavorMap.getAllNativesForType - regression in jdk8 b110 by fix of
 #JDK-8024987
In-Reply-To: 
References: 
Message-ID: <5257DA0D.3020701@oracle.com>

Hi, Petr.
The fix looks good.

On 11.10.2013 12:59, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8026262
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/8026262/webrev.00/
>
> The cause is a forgotten null check in the JDK-8024987 fix. When we try to find all known natives for a type the flavour-to-native cache could not contain some data flavours yet,
> so we are getting a null as a list of corresponding mime-types. It's a valid situation, so a simple null check fixes the problem. The cache will be updated later when the getNativesForFlavour
> method will finish.
>
> The fix was tested with the case described in a netbeans bug: without the fix I fail to DnD a file from Krusader file manager, with a fix I can drag it successfully.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Fri Oct 11 04:26:48 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 11 Oct 2013 15:26:48 +0400
Subject:  [8] Review request for CR 7124338 [macosx] Selection
 lost if a selected item removed from a java.awt.List
In-Reply-To: <5257D8D7.50506@oracle.com>
References: <52418F16.2010608@oracle.com> <5242A110.2070707@oracle.com>
	<5257D8D7.50506@oracle.com>
Message-ID: <5257E078.3020403@oracle.com>

The fix looks good.

On 11.10.2013 14:54, Konstantin Shefov wrote:
> Please, review the fix
> On 25-Sep-13 12:38, Anthony Petrov wrote:
>> Looks good to me.
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 09/24/2013 05:09 PM, Konstantin Shefov wrote:
>>> Hello,
>>>
>>> Please review a fix for the issue:
>>>
>>> 7124338 [macosx] Selection lost if a selected item removed from a
>>> java.awt.List
>>>
>>> Test bug fix. Move from closed repo.
>>>
>>> http://bugs.sun.com/view_bug.do?bug_id=7124338
>>>
>>> The webrev is: http://cr.openjdk.java.net/~kshefov/7124338/webrev.00  -
>>> add to open repo.
>>> http://cr.openjdk.java.net/~kshefov/7124338/webrev.diff - diff with
>>> previous version of the test.
>>>
>>> Thanks,
>>> Konstantin
>


-- 
Best regards, Sergey.


From konstantin.shefov at oracle.com  Fri Oct 11 04:41:15 2013
From: konstantin.shefov at oracle.com (konstantin.shefov at oracle.com)
Date: Fri, 11 Oct 2013 11:41:15 +0000
Subject:  hg: jdk8/awt/jdk: 7124338: [macosx] Selection lost if a
	selected item	removed from a java.awt.List
Message-ID: <20131011114202.E319E62F69@hg.openjdk.java.net>

Changeset: d96f9a8cf89a
Author:    kshefov
Date:      2013-10-11 15:39 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d96f9a8cf89a

7124338: [macosx] Selection lost if a selected item removed from a java.awt.List
Reviewed-by: serb, anthony

+ test/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.html
+ test/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.java


From artem.ananiev at oracle.com  Fri Oct 11 05:31:47 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Fri, 11 Oct 2013 16:31:47 +0400
Subject:  [8] Review request for JDK-8022185 - JDK8 Fix Raw and
 unchecked warnings in classes belonging to java.awt.datatransfer
In-Reply-To: <52559EE9.2000604@oracle.com>
References: <52377DC1.1090504@oracle.com> <524489C2.8040706@oracle.com>
	<1B1150E9-F9D4-4EC4-98F7-633389784CA2@oracle.com>
	<52448F66.9050702@oracle.com> <52552BFE.5000601@oracle.com>
	<52559EE9.2000604@oracle.com>
Message-ID: <5257EFB3.9090805@oracle.com>


On 10/9/2013 10:22 PM, srikalyan chandrashekar wrote:
> Thanks Artem, i have done the fixes, you can find the updated webrev at
> the same location
> .

Looks fine now. I will push the fix shortly.

Thanks,

Artem

> ---
> Thanks
> kalyan
>
> On 10/9/2013 3:12 AM, Artem Ananiev wrote:
>>
>> I put the updated webrev here:
>>
>> http://cr.openjdk.java.net/~art/srikalyc/8022185.01/
>>
>> A few comments:
>>
>> 1. DataFlavor.java: some of the lines got too long after the fix.
>> Please, reformat or add import statements.
>>
>> 2. DataFlavor.java: there are some redundant class casts left, e.g. at
>> line #334.
>>
>> 3. MimeTypeParameterList.java: after the fix, some of the class casts
>> are redundant, e.g. (String)enum_.nextElement() or
>> (String)parameters.get(key)
>>
>> Thanks,
>>
>> Artem
>>
>> On 9/26/2013 11:47 PM, srikalyan chandrashekar wrote:
>>> Thanks Petr, I just made the fix and the webrev has been updated, please
>>> re download to see the changes.
>>>
>>> ---
>>> Thanks
>>> kalyan
>>>
>>> On 9/26/2013 12:36 PM, Petr Pchelko wrote:
>>>> Hello, Srikalyan.
>>>>
>>>> The SystemFlavorMap class was recently fixed by the following
>>>> changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7cad8ef127a9
>>>> There was a severe bug which was fixed, and by the way the generics
>>>> were added.
>>>>
>>>> So could you please remove your changes to this class from the webrev?
>>>>
>>>> With best regards. Petr.
>>>>
>>>> On Sep 26, 2013, at 11:23 PM, srikalyan chandrashekar
>>>>  wrote:
>>>>
>>>>> Hi folks , a gentle reminder for review.
>>>>>
>>>>> ---
>>>>> Thanks
>>>>> kalyan
>>>>>
>>>>> On 9/16/2013 2:53 PM, srikalyan chandrashekar wrote:
>>>>>> Hi team ,  could someone review the fix
>>>>>>     Bug      : https://jbs.oracle.com/bugs/browse/JDK-8022185
>>>>>>     Webrev :
>>>>>> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.datatransfer.raw_unchecked_webrevwebrev.zip
>>>>>>
>>>>>>
>>>>>>     Fix       :  raw and unchecked type warnings fix for
>>>>>> java.awt.datatransfer classes
>>>>>>
>>>
>

From anthony.petrov at oracle.com  Fri Oct 11 05:41:43 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 11 Oct 2013 16:41:43 +0400
Subject:  [8] Review Request: JDK-7002846 Fix for 6989505 may
 be incomplete
In-Reply-To: <525689E3.7070308@oracle.com>
References: <525689E3.7070308@oracle.com>
Message-ID: <5257F207.3010801@oracle.com>

Hi Andrei,

src/windows/classes/sun/awt/windows/WRobotPeer.java
>   59          // See 6989505: that's ineffective, but works correctly with non-opaque windows

It'd be more correct to mention 7002846 instead of 6989505 in this 
comment. The fix looks fine to me otherwise.

--
best regards,
Anthony

On 10/10/2013 03:05 PM, andrei eremeev wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-7002846
> The fix is available at:
> http://cr.openjdk.java.net/~yan/jdk-7002846/webrev.00/
>
> The problem: WinAPI's function GetPixel returns incorrect value of not
> fully opaque pixel on Intel graphic card.
> The idea of the fix is to use getPixels(x, y, 1, 1)[0] which gets pixels
> correctly. But this solution is 2 times slower than we had.

From anthony.petrov at oracle.com  Fri Oct 11 05:46:54 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 11 Oct 2013 16:46:54 +0400
Subject:  [8] Review Request: JDK-8024329 [macosx]
 JRadioButtonMenuItem behaves like a checkbox when using the ScreenMenuBar
In-Reply-To: 
References: 
	
Message-ID: <5257F33E.5060404@oracle.com>

Hi Petr,

I'm not an expert in this code, but the changes look good to me.

--
best regards,
Anthony

On 10/11/2013 01:35 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the new version of the fix:
> http://cr.openjdk.java.net/~pchelko/8024329/webrev.01/
>
> This version of the fix does not expose the package-private class com.apple.laf.ScreenMenuItemCheckbox
> Instead we override the setState method to no-op and force the setState only when it's really needed.
>
> With best regards. Petr.
>
> On 10.10.2013, at 18:19, Petr Pchelko  wrote:
>
>> Hello, AWT Team.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8024329
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/8024329/webrev.00/
>>
>> The problem: for AWT menu the peer should update the menu item state unconditionally. However for the Swing menu items used in screen menubar swing should decide wether to update the state or not. So we should not unconditionally update the sate.
>> There's no regression test as there's no way to understand if the native menu item is checked or not.
>>
>> With best regards. Petr.
>

From anthony.petrov at oracle.com  Fri Oct 11 05:58:08 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 11 Oct 2013 16:58:08 +0400
Subject:  [8] Review Request: JDK-8025824 [cleanup] Fix tidy
 errors and warnings in preformatted HTML files related to 2d/awt/swing
In-Reply-To: <52569E80.1060104@oracle.com>
References: <52569E80.1060104@oracle.com>
Message-ID: <5257F5E0.503@oracle.com>

Hi Yuri,

I briefly skimmed through the patch and it looks fine to me.

--
best regards,
Anthony

On 10/10/2013 04:33 PM, Yuri Nesterenko wrote:
> Hi colleagues,
>
> please review this fix for the RFE
> https://bugs.openjdk.java.net/browse/JDK-8025824
> See the webrev at
> http://cr.openjdk.java.net/~yan/jdk-8025824/webrev.00
>
> In the JDK-8025824 there are two files attached:
> one with initial set of tidy warnings, and the second with warnings
> after this fix.
> Visually, virtually nothing changed -- well, some
> visible formatting errors were pointed by tidy and fixed.
>
> Thanks,
> -yan

From artem.ananiev at oracle.com  Fri Oct 11 06:01:17 2013
From: artem.ananiev at oracle.com (artem.ananiev at oracle.com)
Date: Fri, 11 Oct 2013 13:01:17 +0000
Subject:  hg: jdk8/awt/jdk: 8022185: Fix Raw and unchecked warnings
	in classes	belonging to java.awt.datatransfer
Message-ID: <20131011130252.8455562F6E@hg.openjdk.java.net>

Changeset: 2e04843f1c1d
Author:    art
Date:      2013-10-11 16:44 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2e04843f1c1d

8022185: Fix Raw and unchecked warnings in classes belonging to java.awt.datatransfer
Reviewed-by: art, pchelko
Contributed-by: Srikalyan Chandrashekar 

! src/share/classes/java/awt/datatransfer/DataFlavor.java
! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java


From Sergey.Bylokhov at oracle.com  Fri Oct 11 06:48:18 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 11 Oct 2013 17:48:18 +0400
Subject:  [8] Review Request: JDK-8024329 [macosx]
 JRadioButtonMenuItem behaves like a checkbox when using the ScreenMenuBar
In-Reply-To: 
References: 
	
Message-ID: <525801A2.30406@oracle.com>

Hi, Petr.
The fix looks good.

On 11.10.2013 13:35, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the new version of the fix:
> http://cr.openjdk.java.net/~pchelko/8024329/webrev.01/
>
> This version of the fix does not expose the package-private class com.apple.laf.ScreenMenuItemCheckbox
> Instead we override the setState method to no-op and force the setState only when it's really needed.
>
> With best regards. Petr.
>
> On 10.10.2013, at 18:19, Petr Pchelko  wrote:
>
>> Hello, AWT Team.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8024329
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/8024329/webrev.00/
>>
>> The problem: for AWT menu the peer should update the menu item state unconditionally. However for the Swing menu items used in screen menubar swing should decide wether to update the state or not. So we should not unconditionally update the sate.
>> There's no regression test as there's no way to understand if the native menu item is checked or not.
>>
>> With best regards. Petr.


-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Fri Oct 11 07:03:06 2013
From: petr.pchelko at oracle.com (petr.pchelko at oracle.com)
Date: Fri, 11 Oct 2013 14:03:06 +0000
Subject:  hg: jdk8/awt/jdk: 8024329: [macosx] JRadioButtonMenuItem
	behaves like	a checkbox when using the ScreenMenuBar
Message-ID: <20131011140319.B8BA062F74@hg.openjdk.java.net>

Changeset: af273c9b564a
Author:    pchelko
Date:      2013-10-11 18:04 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/af273c9b564a

8024329: [macosx] JRadioButtonMenuItem behaves like a checkbox when using the ScreenMenuBar
Reviewed-by: anthony, serb

! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java


From Sergey.Bylokhov at oracle.com  Fri Oct 11 07:10:44 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 11 Oct 2013 18:10:44 +0400
Subject:  [8] Review Request: 8019591 JCK:
 testICSEthrowing_fullScreen fails: no ICSE thrown
Message-ID: <525806E4.2010607@oracle.com>

  Hello.
Please review the fix for jdk 8. The problem is in inconsistent state of 
the GraphicsDevice, Window and Peer.
We update GraphicsDevice synchronously in setFullScreenWindow(), we 
update peer's coordinate a little bit later in the native call back, and 
we update state of the window much later on EDT.
In the fix I try to update GraphicsDevice and Window.gc, so they points 
to each other.
All attempts to do the same things synchronously from the native 
callback deadlocked.

Bug: https://bugs.openjdk.java.net/browse/JDK-8019591
Webrev can be found at: http://cr.openjdk.java.net/~serb/8019591/webrev.00

-- 
Best regards, Sergey.


From petr.pchelko at oracle.com  Fri Oct 11 06:57:07 2013
From: petr.pchelko at oracle.com (petr.pchelko at oracle.com)
Date: Fri, 11 Oct 2013 13:57:07 +0000
Subject:  hg: jdk8/awt/jdk: 8026262: NPE
	in	SystemFlavorMap.getAllNativesForType - regression in jdk8
	b110	by fix of #JDK-8024987
Message-ID: <20131011135740.21C5D62F71@hg.openjdk.java.net>

Changeset: 2f7f6995fa64
Author:    pchelko
Date:      2013-10-11 17:57 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2f7f6995fa64

8026262: NPE in SystemFlavorMap.getAllNativesForType - regression in jdk8 b110 by fix of #JDK-8024987
Reviewed-by: art, serb

! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java


From alexandr.scherbatiy at oracle.com  Fri Oct 11 07:33:13 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 11 Oct 2013 18:33:13 +0400
Subject:  [8] Review Request: JDK-8025824 [cleanup] Fix tidy
 errors and warnings in preformatted HTML files related to 2d/awt/swing
In-Reply-To: <52569E80.1060104@oracle.com>
References: <52569E80.1060104@oracle.com>
Message-ID: <52580C29.7060109@oracle.com>


   The fix looks good for me.

    Thanks,
    Alexandr.

On 10/10/2013 4:33 PM, Yuri Nesterenko wrote:
> Hi colleagues,
>
> please review this fix for the RFE
> https://bugs.openjdk.java.net/browse/JDK-8025824
> See the webrev at
> http://cr.openjdk.java.net/~yan/jdk-8025824/webrev.00
>
> In the JDK-8025824 there are two files attached:
> one with initial set of tidy warnings, and the second with warnings 
> after this fix.
> Visually, virtually nothing changed -- well, some
> visible formatting errors were pointed by tidy and fixed.
>
> Thanks,
> -yan


From anton.nashatyrev at oracle.com  Fri Oct 11 08:49:41 2013
From: anton.nashatyrev at oracle.com (anton nashatyrev)
Date: Fri, 11 Oct 2013 19:49:41 +0400
Subject:  [8] Review request for 8024061: Exception thrown when
 drag and drop between two components is executed quickly
Message-ID: <52581E15.20108@oracle.com>

Hello,
     could you please review the following fix:

fix: http://cr.openjdk.java.net/~mcherkas/anton/8024061/webrev.00/ 

bug: https://bugs.openjdk.java.net/browse/JDK-8024061

     Problem:  when doing quick drag'n'drop in X11 the incorrect 
behavior appears in the different forms. One is the exception when 
trying to get 'local Jvm' Transferable from DropTargetListener.

     Reason: on quick drag the following sequence of events may appear: 
(1) mouse pressed on source  -> (2) mouse moved to target in a single 
X11 event -> (3) mouse released. What's happening in that case: on event 
(2) only a drag gesture is recognized and no drag enter is generated 
yet. On event (3) the XDragSourceContextPeer assumes that entered event 
(if it happened) was already generated and the 'local JVM' transferable 
had been already captured by SunDropTargetContextPeer from the static 
field currentJVMLocalSourceTransferable. Thus on event (3) the 
XDragSourceContextPeer posts the additional mouseMove event (which turns 
into DragEnter later) and initiates the cleanup which then resets the 
currentJVMLocalSourceTransferable to null. Thus on DragEnter the 
currentJVMLocalSourceTransferable is already null and the 
SunDropTargetContextPeer appears in the inconsistent state.

     Solution: the event (2) from the example above should not only 
initiate the DnD operation but also be a part of that operation, i.e. 
this event should also appear as a drag motion. For that I propose to 
keep a track of the XMotionEvents in the XDragSourceContextPeer to catch 
the mouse event which initiated the DnD and when a startDrag() is called 
process this event as the first drag motion event.

Thanks!
Anton.

From lana.steuck at oracle.com  Fri Oct 11 16:46:48 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Oct 2013 23:46:48 +0000
Subject:  hg: jdk8/awt/corba: 5 new changesets
Message-ID: <20131011234706.CF7AF62FB2@hg.openjdk.java.net>

Changeset: c1eb93f57603
Author:    cl
Date:      2013-09-19 09:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/c1eb93f57603

Added tag jdk8-b108 for changeset a4bb3b450016

! .hgtags

Changeset: 428428cf5e06
Author:    tbell
Date:      2013-09-25 12:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/428428cf5e06

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties

Changeset: 3d2b7ce93c5c
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/3d2b7ce93c5c

Added tag jdk8-b109 for changeset 428428cf5e06

! .hgtags

Changeset: 85c1c94e7235
Author:    katleman
Date:      2013-10-02 13:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/85c1c94e7235

Added tag jdk8-b110 for changeset 3d2b7ce93c5c

! .hgtags

Changeset: d7e478820c56
Author:    cl
Date:      2013-10-10 10:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/corba/rev/d7e478820c56

Added tag jdk8-b111 for changeset 85c1c94e7235

! .hgtags


From lana.steuck at oracle.com  Fri Oct 11 16:46:57 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Oct 2013 23:46:57 +0000
Subject:  hg: jdk8/awt: 17 new changesets
Message-ID: <20131011234706.99ED762FB1@hg.openjdk.java.net>

Changeset: d4762f463fe0
Author:    cl
Date:      2013-09-19 09:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/d4762f463fe0

Added tag jdk8-b108 for changeset 9286a6e61291

! .hgtags

Changeset: 91f47e8da5c6
Author:    tbell
Date:      2013-09-25 12:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/91f47e8da5c6

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties

Changeset: 0cc21882d2f6
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/0cc21882d2f6

Added tag jdk8-b109 for changeset 91f47e8da5c6

! .hgtags

Changeset: 5ec3c4948863
Author:    ksrini
Date:      2013-09-27 16:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/5ec3c4948863

8023495: [infra] create 64-bit solaris bits with symlinks
Reviewed-by: ihse, tbell, erikj

! common/makefiles/Jprt.gmk
! common/makefiles/Main.gmk

Changeset: 72c2495c86c9
Author:    katleman
Date:      2013-10-01 12:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/72c2495c86c9

Merge


Changeset: 0f704e36bc5d
Author:    ihse
Date:      2013-10-01 10:58 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/0f704e36bc5d

8006661: Use LC_ALL=C instead of LANG=C compare.sh
Reviewed-by: tbell

! common/bin/compare.sh

Changeset: 4faa09c7fe55
Author:    erikj
Date:      2013-10-02 15:08 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/4faa09c7fe55

Merge


Changeset: 669e3e3d4459
Author:    katleman
Date:      2013-10-02 13:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/669e3e3d4459

Added tag jdk8-b110 for changeset 4faa09c7fe55

! .hgtags

Changeset: feb4f2d97042
Author:    ihse
Date:      2013-10-03 11:26 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/feb4f2d97042

8008944: Correct typos
Reviewed-by: tbell, erikj

! NewMakefile.gmk
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/makefiles/JavaCompilation.gmk

Changeset: d23177734b28
Author:    thurka
Date:      2013-10-07 13:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/d23177734b28

8025920: webrev.ksh does not provide any details about changes in zip files
Summary: Add support for diffs for zip files
Reviewed-by: ksrini, chegar

! make/scripts/webrev.ksh

Changeset: 9b102ab97693
Author:    erikj
Date:      2013-10-07 18:19 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/9b102ab97693

8005924: Make it possible to set both --with-user-release-suffix and --with-build-number
Reviewed-by: ihse, tbell

! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/autoconf/spec.gmk.in

Changeset: d086227bfc45
Author:    katleman
Date:      2013-10-08 13:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/d086227bfc45

Merge


Changeset: 82a36c5c4eaf
Author:    cl
Date:      2013-10-10 10:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/82a36c5c4eaf

Added tag jdk8-b111 for changeset d086227bfc45

! .hgtags

Changeset: 187a759c08ba
Author:    alanb
Date:      2013-10-02 04:21 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/187a759c08ba

8006843: org.w3c.dom.events.UIEvent.getView is specified to return type that is not in the Java SE specification
Reviewed-by: mduigou, tbell

! common/makefiles/javadoc/CORE_PKGS.gmk

Changeset: 6b8f5030e5ad
Author:    bpatel
Date:      2013-10-04 15:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/6b8f5030e5ad

8025741: Fix jdk/make/docs/Makefile to point to correct docs URL for JDK 8.
Reviewed-by: tbell

! common/makefiles/javadoc/Javadoc.gmk

Changeset: 7c0e2fd8be4d
Author:    lana
Date:      2013-10-08 14:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/7c0e2fd8be4d

Merge


Changeset: 3ece65f23ed2
Author:    lana
Date:      2013-10-11 00:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/rev/3ece65f23ed2

Merge



From lana.steuck at oracle.com  Fri Oct 11 16:47:23 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Oct 2013 23:47:23 +0000
Subject:  hg: jdk8/awt/jaxws: 9 new changesets
Message-ID: <20131011234914.BDD0662FB3@hg.openjdk.java.net>

Changeset: f64b1e497722
Author:    cl
Date:      2013-09-19 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/f64b1e497722

Added tag jdk8-b108 for changeset d1ea68556fd7

! .hgtags

Changeset: df5d4d016425
Author:    tbell
Date:      2013-09-25 12:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/df5d4d016425

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties

Changeset: cc682329886b
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/cc682329886b

Added tag jdk8-b109 for changeset df5d4d016425

! .hgtags

Changeset: 32edc7a2c866
Author:    katleman
Date:      2013-10-02 13:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/32edc7a2c866

Added tag jdk8-b110 for changeset cc682329886b

! .hgtags

Changeset: fc94ce4b899e
Author:    cl
Date:      2013-10-10 10:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/fc94ce4b899e

Added tag jdk8-b111 for changeset 32edc7a2c866

! .hgtags

Changeset: b0610cd08440
Author:    mkos
Date:      2013-10-04 16:21 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/b0610cd08440

8025054: Update JAX-WS RI integration to 2.2.9-b130926.1035
Reviewed-by: chegar

! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/ExternalMetadataFeature.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/WscompileMessages.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/Options.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportOptions.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMForest.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/AbstractExtendedComplexTypeBuilder.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/SchemaConstraintChecker.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/AccessorInjector.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Injector.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedAccessorFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64Data.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64Encoder.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64EncoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/ByteArrayOutputStreamEx.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/NamespaceContextEx.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/XMLStreamWriterEx.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/binary/SchemaBuilderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DDataPattern.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DPattern.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DXMLPrinter.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DataPatternBuilderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/GrammarBuilderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/AnyNameClass.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/NameClassBuilderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/SimpleNameClass.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/parse/compact/UCode_UCodeESC_CharStream.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/parse/xml/SchemaParser.java
! src/share/jaxws_classes/com/sun/xml/internal/rngom/xml/sax/JAXPXMLReaderCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaTubeHelper.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundOperation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundPortType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLExtensible.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLFault.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLModel.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOperation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOutput.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPort.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPortType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLService.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundFault.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundOperation.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundPortType.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLFault.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLInput.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLMessage.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLModel.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLOperation.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLOutput.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPart.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPort.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPortType.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLService.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtensionContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/WebServiceFeatureList.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/MonitorRootClient.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/PortInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/Stub.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/WSServiceDelegate.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/ExternalMetadataReader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/JavaMethodImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/AbstractExtensibleImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundFaultImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundOperationImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundPortTypeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLFaultImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLInputImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLMessageImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLModelImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOperationImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOutputImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPartImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortTypeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLProperties.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLServiceImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/WsservletMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/WSEndpointImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/ProviderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpAdapter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/client/HttpTransportPipe.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/ActionBasedOperationFinder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/PayloadQNameBasedOperationFinder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/DelegatingParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/FoolProofParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/MemberSubmissionAddressingWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/RuntimeWSDLParser.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingMetadataWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionContextImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionFacade.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java
! src/share/jaxws_classes/javax/annotation/PostConstruct.java
! src/share/jaxws_classes/javax/annotation/PreDestroy.java
! src/share/jaxws_classes/javax/xml/bind/JAXBException.java
! src/share/jaxws_classes/javax/xml/bind/Marshaller.java
! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/package.html
! src/share/jaxws_classes/javax/xml/soap/MessageFactory.java

Changeset: e56be3a2287a
Author:    coffeys
Date:      2013-10-05 08:56 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/e56be3a2287a

8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash
Reviewed-by: mkos, chegar

! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java

Changeset: 1d6c13d3b8de
Author:    lana
Date:      2013-10-08 14:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/1d6c13d3b8de

Merge


Changeset: 7c0a7937f6ef
Author:    lana
Date:      2013-10-11 00:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/7c0a7937f6ef

Merge



From lana.steuck at oracle.com  Fri Oct 11 16:47:23 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Oct 2013 23:47:23 +0000
Subject:  hg: jdk8/awt/nashorn: 42 new changesets
Message-ID: <20131011234921.2CEB762FB4@hg.openjdk.java.net>

Changeset: 6ec2f9e5ed5b
Author:    cl
Date:      2013-09-19 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/6ec2f9e5ed5b

Added tag jdk8-b108 for changeset 445ad3f6d3b4

! .hgtags

Changeset: d1e2050e575e
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/d1e2050e575e

Added tag jdk8-b109 for changeset 6ec2f9e5ed5b

! .hgtags

Changeset: 1971c2d770ae
Author:    sundar
Date:      2013-09-18 13:06 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/1971c2d770ae

8024972: for (LeftHandSideExpression in Expression) crashes the compiler
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
+ test/script/basic/JDK-8024972.js
+ test/script/basic/JDK-8024972.js.EXPECTED

Changeset: a62172fe5bae
Author:    sundar
Date:      2013-09-18 16:36 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/a62172fe5bae

8024973: Using a different ScriptContext with a CompiledScript results in ScriptException
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/runtime/Source.java
! test/script/trusted/JDK-8008305.js
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: f954d3f4d192
Author:    sundar
Date:      2013-09-19 13:34 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/f954d3f4d192

8025048: true as case label results in ClassCastException
Reviewed-by: lagergren

! src/jdk/nashorn/internal/codegen/Attr.java
+ test/script/basic/JDK-8025048-2.js
+ test/script/basic/JDK-8025048.js

Changeset: 740b1133f1b6
Author:    hannesw
Date:      2013-09-19 15:39 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/740b1133f1b6

8023154: compileAllTests fails with: 2 tests failed to compile
Reviewed-by: sundar, jlaskey

! make/build-benchmark.xml
! make/build.xml
! make/project.properties

Changeset: 821b0b610861
Author:    sundar
Date:      2013-09-19 21:20 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/821b0b610861

8025080: Object literal getter, setter function with number format property name results in ClassFormatError
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/ir/debug/JSONWriter.java
! src/jdk/nashorn/internal/parser/Parser.java
+ test/script/basic/JDK-8025080.js
+ test/script/basic/JDK-8025080.js.EXPECTED
! test/script/basic/parser/objectLitExpr.js.EXPECTED

Changeset: 18d64bc4937d
Author:    sundar
Date:      2013-09-19 23:48 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/18d64bc4937d

8025090: 'while' statement with 'test' using var before being declared in body results in VerifyError
Reviewed-by: jlaskey

! src/jdk/nashorn/internal/ir/WhileNode.java
+ test/script/basic/JDK-8025090.js

Changeset: 195be8ca5c97
Author:    sundar
Date:      2013-09-20 12:56 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/195be8ca5c97

8025111: undefined or null 'with' expression in empty with block should throw TypeError
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
+ test/script/basic/JDK-8025111.js

Changeset: fa491b75d3e4
Author:    hannesw
Date:      2013-09-20 12:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/fa491b75d3e4

8022587: ClassCache is not optimal and leaks Source instances
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/objects/Global.java

Changeset: 13210550765c
Author:    lana
Date:      2013-09-20 19:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/13210550765c

Merge


Changeset: 279f47b353f3
Author:    sundar
Date:      2013-09-20 20:55 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/279f47b353f3

8025147: Trailing comma is not allowed in JSONArray and JSONObject
Reviewed-by: hannesw, jlaskey

! src/jdk/nashorn/internal/parser/JSONParser.java
! src/jdk/nashorn/internal/runtime/resources/Messages.properties
+ test/script/basic/JDK-8025147.js
+ test/script/basic/JDK-8025147.js.EXPECTED

Changeset: 16b6db9f7225
Author:    sundar
Date:      2013-09-20 22:37 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/16b6db9f7225

8025149: JSON.stringify does not handle 'space' argument as per the spec.
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/objects/NativeJSON.java
+ test/script/basic/JDK-8025149.js
+ test/script/basic/JDK-8025149.js.EXPECTED

Changeset: b8d9a63578e2
Author:    hannesw
Date:      2013-09-21 10:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/b8d9a63578e2

8025163: Date methods should not return -0
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/NativeDate.java
+ test/script/basic/JDK-8025163.js
+ test/script/basic/JDK-8025163.js.EXPECTED

Changeset: 8f6304373671
Author:    sundar
Date:      2013-09-23 14:20 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/8f6304373671

Merge


Changeset: c5475f5d4647
Author:    sundar
Date:      2013-09-24 20:43 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/c5475f5d4647

8025312: parseInt should convert 'radix' argument to ToInt32 even if empty string is parsed
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/runtime/GlobalFunctions.java
+ test/script/basic/JDK-8025312.js
+ test/script/basic/JDK-8025312.js.EXPECTED

Changeset: 754ecd62bde3
Author:    sundar
Date:      2013-09-25 08:17 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/754ecd62bde3

8025325: parseFloat does not handle '.' in exponent part
Reviewed-by: hannesw

! src/jdk/nashorn/internal/runtime/GlobalFunctions.java
+ test/script/basic/JDK-8025325.js
+ test/script/basic/JDK-8025325.js.EXPECTED

Changeset: 2f8f99e5ed76
Author:    hannesw
Date:      2013-09-25 16:37 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/2f8f99e5ed76

8025434: RegExp lastIndex can exceed int range
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/objects/NativeRegExp.java
+ test/script/basic/JDK-8025434.js

Changeset: 712f5e31739b
Author:    hannesw
Date:      2013-09-26 10:14 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/712f5e31739b

8025197: String replace method fails with regexp /$/gi
Reviewed-by: sundar

! src/jdk/nashorn/internal/objects/NativeRegExp.java
+ test/script/basic/JDK-8025197.js
+ test/script/basic/JDK-8025197.js.EXPECTED

Changeset: 23958764f866
Author:    hannesw
Date:      2013-09-26 11:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/23958764f866

8025486: RegExp constructor arguments are not evaluated in right order
Reviewed-by: sundar

! src/jdk/nashorn/internal/objects/NativeRegExp.java
+ test/script/basic/JDK-8025486.js
+ test/script/basic/JDK-8025486.js.EXPECTED

Changeset: f1f027907a69
Author:    sundar
Date:      2013-09-26 16:37 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/f1f027907a69

Merge


Changeset: d49a8c2173f5
Author:    lana
Date:      2013-09-26 17:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/d49a8c2173f5

Merge


Changeset: 75fd3486e584
Author:    katleman
Date:      2013-10-02 13:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/75fd3486e584

Added tag jdk8-b110 for changeset d49a8c2173f5

! .hgtags

Changeset: fc2b6885e60e
Author:    cl
Date:      2013-10-10 10:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/fc2b6885e60e

Added tag jdk8-b111 for changeset 75fd3486e584

! .hgtags

Changeset: 982dd6e1bf4f
Author:    lana
Date:      2013-09-27 18:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/982dd6e1bf4f

Merge


Changeset: 2016a6b9e1f3
Author:    hannesw
Date:      2013-09-27 16:59 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/2016a6b9e1f3

8025515: Performance issues with Source.getLine()
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/ir/LexicalContext.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/Source.java
+ test/script/basic/JDK-8025515.js

Changeset: 1809c9e97c71
Author:    hannesw
Date:      2013-09-27 17:00 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/1809c9e97c71

8025520: Array.prototype.slice should only copy defined elements
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8025520.js

Changeset: efc40aacaee4
Author:    hannesw
Date:      2013-09-30 15:54 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/efc40aacaee4

8025589: Array.prototype.shift should only copy defined elements in generic mode
Reviewed-by: sundar, attila

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8025589.js

Changeset: ad5f9ce2a95b
Author:    jlaskey
Date:      2013-09-30 10:24 -0300
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/ad5f9ce2a95b

Merge


Changeset: 787e36fdf69a
Author:    jlaskey
Date:      2013-09-30 12:06 -0300
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/787e36fdf69a

Merge


Changeset: 7272ec90f2c6
Author:    sundar
Date:      2013-09-30 21:33 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/7272ec90f2c6

8025629: load function should support a way to load scripts from classpath
Reviewed-by: lagergren, hannesw, attila

! make/build.xml
! src/jdk/nashorn/internal/runtime/Context.java
+ test/script/trusted/JDK-8025629.js
+ test/src/jdk/nashorn/internal/runtime/resources/load_test.js

Changeset: f5aefbe76cec
Author:    jlaskey
Date:      2013-09-30 18:09 -0300
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/f5aefbe76cec

8025689: fx:base.js classes not loading
Reviewed-by: sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/resources/fx/base.js

Changeset: cd7fb58043cb
Author:    sundar
Date:      2013-10-01 14:38 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/cd7fb58043cb

8025488: Error.captureStackTrace should not format error stack
Reviewed-by: hannesw, attila

! src/jdk/nashorn/internal/objects/NativeError.java
+ test/script/basic/JDK-8025488.js
+ test/script/basic/JDK-8025488.js.EXPECTED

Changeset: 3470bc26128f
Author:    sundar
Date:      2013-10-04 16:21 +0530
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/3470bc26128f

8025771: Enhance Nashorn Contexts
Reviewed-by: jlaskey, hannesw

- make/java.security.override
! make/project.properties
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! test/script/basic/JDK-8023026.js
+ test/script/sandbox/arrayclass.js
+ test/script/sandbox/arrayclass.js.EXPECTED

Changeset: 6345d08fd5de
Author:    hannesw
Date:      2013-10-08 11:55 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/6345d08fd5de

8025213: Assignment marks variable as defined too early
Reviewed-by: jlaskey, lagergren, sundar

! src/jdk/nashorn/internal/codegen/Attr.java
+ test/script/basic/JDK-8025213.js
+ test/script/basic/JDK-8025213.js.EXPECTED

Changeset: 8c326f8c6799
Author:    sundar
Date:      2013-10-08 13:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/8c326f8c6799

8026033: Switch should load expression even when there are no cases in it
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
+ test/script/basic/JDK-8026033.js
+ test/script/basic/JDK-8026033.js.EXPECTED

Changeset: 025e2ff9e91b
Author:    hannesw
Date:      2013-10-08 13:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/025e2ff9e91b

8025965: Specialized functions with same weight replace each other in TreeSet
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/runtime/CompiledFunction.java

Changeset: 19dba6637f20
Author:    sundar
Date:      2013-10-08 14:57 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/19dba6637f20

8026039: future strict names are allowed as function name and argument name of a strict function
Reviewed-by: hannesw, jlaskey

! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/parser/AbstractParser.java
! src/jdk/nashorn/internal/parser/Parser.java
+ test/script/error/JDK-8026039.js
+ test/script/error/JDK-8026039.js.EXPECTED

Changeset: c9921761903b
Author:    hannesw
Date:      2013-10-08 15:53 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/c9921761903b

8026042: FoldConstants need to guard against ArrayLiteralNode
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/codegen/FoldConstants.java
! src/jdk/nashorn/internal/ir/LiteralNode.java
+ test/script/basic/JDK-8026042.js
+ test/script/basic/JDK-8026042.js.EXPECTED

Changeset: 346ba5b8a488
Author:    sundar
Date:      2013-10-08 16:46 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/346ba5b8a488

8026048: Function constructor should convert arguments to String before performing any syntax checks
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/objects/NativeFunction.java
+ test/script/basic/JDK-8026048.js

Changeset: 3551855c4f40
Author:    lana
Date:      2013-10-08 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/3551855c4f40

Merge

- make/java.security.override

Changeset: b48b719c5efc
Author:    lana
Date:      2013-10-11 03:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/b48b719c5efc

Merge

- make/java.security.override


From lana.steuck at oracle.com  Fri Oct 11 16:47:20 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Oct 2013 23:47:20 +0000
Subject:  hg: jdk8/awt/jaxp: 11 new changesets
Message-ID: <20131011234926.227E362FB5@hg.openjdk.java.net>

Changeset: 21b10835b88a
Author:    cl
Date:      2013-09-19 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/21b10835b88a

Added tag jdk8-b108 for changeset 8ade3eed63da

! .hgtags

Changeset: 02bfab2aa938
Author:    tbell
Date:      2013-09-25 12:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/02bfab2aa938

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties

Changeset: 4c84c5b447b0
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/4c84c5b447b0

Added tag jdk8-b109 for changeset 02bfab2aa938

! .hgtags

Changeset: 17ee0d3e97fd
Author:    katleman
Date:      2013-10-02 13:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/17ee0d3e97fd

Added tag jdk8-b110 for changeset 4c84c5b447b0

! .hgtags

Changeset: a4622ff1462b
Author:    cl
Date:      2013-10-10 10:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/a4622ff1462b

Added tag jdk8-b111 for changeset 17ee0d3e97fd

! .hgtags

Changeset: 84a2b2ee6fc6
Author:    aefimov
Date:      2013-10-01 17:14 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/84a2b2ee6fc6

8024707: TransformerException : item() return null with node list of length != 1
Reviewed-by: joehw, lancea

! src/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIterNodeList.java

Changeset: f031b2fe21cd
Author:    dfuchs
Date:      2013-10-04 19:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/f031b2fe21cd

8025745: Clarify API documentation of JAXP factories.
Summary: Clarifies usage of ServiceLoader in JAXP factories.
Reviewed-by: alanb, joehw, psandoz

! src/javax/xml/datatype/DatatypeFactory.java
! src/javax/xml/parsers/DocumentBuilderFactory.java
! src/javax/xml/parsers/SAXParserFactory.java
! src/javax/xml/stream/XMLEventFactory.java
! src/javax/xml/stream/XMLInputFactory.java
! src/javax/xml/stream/XMLOutputFactory.java
! src/javax/xml/transform/TransformerFactory.java
! src/javax/xml/validation/SchemaFactory.java
! src/javax/xml/xpath/XPathFactory.java

Changeset: dbecbb685503
Author:    mfang
Date:      2013-10-08 09:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/dbecbb685503

8025215: jdk8 l10n resource file translation update 4
Reviewed-by: joehw, yhuang

! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_de.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_fr.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_it.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ja.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ko.java
+ src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_pt_BR.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_sv.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_CN.java
! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_TW.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java

Changeset: 1c074a0c2b97
Author:    mfang
Date:      2013-10-08 09:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/1c074a0c2b97

Merge


Changeset: d69f4ac43d64
Author:    lana
Date:      2013-10-08 14:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/d69f4ac43d64

Merge


Changeset: cdc3577cba0b
Author:    lana
Date:      2013-10-11 00:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/cdc3577cba0b

Merge



From lana.steuck at oracle.com  Fri Oct 11 16:50:17 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Oct 2013 23:50:17 +0000
Subject:  hg: jdk8/awt/hotspot: 160 new changesets
Message-ID: <20131011235716.EB1A262FB9@hg.openjdk.java.net>

Changeset: 34aa07e92d22
Author:    cl
Date:      2013-09-19 09:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/34aa07e92d22

Added tag jdk8-b108 for changeset 85072013aad4

! .hgtags

Changeset: e42e456fbe6e
Author:    amurillo
Date:      2013-09-13 00:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e42e456fbe6e

8024764: new hotspot build - hs25-b51
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: baa7927dfbd2
Author:    zgu
Date:      2013-09-04 08:55 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/baa7927dfbd2

8022798: "assert(seq > 0) failed: counter overflow" in Kitchensink
Summary: Removed incorrect assertion, sequence number can overflow
Reviewed-by: dholmes, kamg

! src/share/vm/services/memPtr.cpp

Changeset: 38f750491293
Author:    iklam
Date:      2013-09-06 08:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/38f750491293

8022335: Native stack walk while generating hs_err does not work on Windows x64
Summary: Use WinDbg API StackWalk64()
Reviewed-by: zgu, dholmes

! src/os/windows/vm/decoder_windows.cpp
! src/os/windows/vm/decoder_windows.hpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/utilities/decoder.cpp
! src/share/vm/utilities/decoder.hpp
! src/share/vm/utilities/vmError.cpp
! src/share/vm/utilities/vmError.hpp

Changeset: 592520c14121
Author:    kevinw
Date:      2013-09-09 10:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/592520c14121

8023478: Test fails with HS crash in GCNotifier.
Reviewed-by: sla

! src/share/vm/services/gcNotifier.cpp

Changeset: b6767a18b379
Author:    hseigel
Date:      2013-09-09 14:44 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b6767a18b379

8023167: JVM allows duplicate Runtime[In]VisibleTypeAnnotations attributes in ClassFile/field_info/method_info structures
Summary: Add checks for duplicates and issue errors when detected.
Reviewed-by: coleenp, zgu

! src/share/vm/classfile/classFileParser.cpp

Changeset: 0f648fbe4404
Author:    dsamersoff
Date:      2013-09-11 14:30 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/0f648fbe4404

8024056: runtime/InitialThreadOverflow/testme.sh fails
Summary: on some macines gcc not able to link cxx program
Reviewed-by: dholmes

! test/runtime/InitialThreadOverflow/testme.sh

Changeset: 1c6b721a3fbf
Author:    dsamersoff
Date:      2013-09-12 15:53 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/1c6b721a3fbf

8022617: Openjdk hotspot build is broken on BSD platforms using gcc
Summary: Enforce of preprocessing of all assembly sources by assembler-with-cpp
Reviewed-by: dholmes, erikj

! make/bsd/makefiles/gcc.make

Changeset: 225cedaf9a4b
Author:    zgu
Date:      2013-09-13 10:34 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/225cedaf9a4b

Merge

! src/share/vm/classfile/classFileParser.cpp

Changeset: 623d923529df
Author:    mgronlun
Date:      2013-09-13 17:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/623d923529df

8021353: Event based tracing is missing thread exit
Reviewed-by: allwin, acorn, dcubed, dholmes, egahlin

! src/share/vm/runtime/thread.cpp
! src/share/vm/trace/traceMacros.hpp

Changeset: b89a1a870965
Author:    mgronlun
Date:      2013-09-13 19:20 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b89a1a870965

Merge

! src/share/vm/runtime/thread.cpp

Changeset: ff8a09595db3
Author:    sspitsyn
Date:      2013-09-13 12:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ff8a09595db3

8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed
Summary: Handle pending exceptions instead of firing a guarantee()
Reviewed-by: coleenp, dholmes
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: ce5ee9de50ce
Author:    sspitsyn
Date:      2013-09-13 12:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ce5ee9de50ce

8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool
Summary: The OOME's in the JVMTI merge_cp_and_rewrite and set_new_constant_pool must be handled correctly
Reviewed-by: coleenp, dholmes
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: 0d3ff4d36a31
Author:    sspitsyn
Date:      2013-09-13 12:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/0d3ff4d36a31

8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated
Summary: Pending exceptions must be handled properly after a call to the JVMTI merge_cp_and_rewrite
Reviewed-by: coleenp, dholmes
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: b135b600a66c
Author:    sspitsyn
Date:      2013-09-13 16:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b135b600a66c

Merge


Changeset: 2e6938dd68f2
Author:    dholmes
Date:      2013-09-16 07:38 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2e6938dd68f2

6900441: PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock
Summary: Associate CLOCK_MONOTONIC with the pthread_cond_t objects used for relative timed waits
Reviewed-by: dcubed, shade

! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp

Changeset: 4472884d8b37
Author:    dcubed
Date:      2013-09-16 12:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/4472884d8b37

6986195: correctly identify Ubuntu as the operating system in crash report instead of "Debian"
Summary: Cleanup and document how various Linux release info files are used by print_distro_info().
Reviewed-by: dcubed, dsamersoff, coleenp, iklam, omajid
Contributed-by: gerald.thornbrugh at oracle.com

! src/os/linux/vm/os_linux.cpp

Changeset: 42863137168c
Author:    acorn
Date:      2013-09-16 17:57 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/42863137168c

8024647: Default method resolution with private superclass method
Reviewed-by: kamg, minqi

! src/share/vm/classfile/defaultMethods.cpp

Changeset: 921967020b3b
Author:    acorn
Date:      2013-09-16 15:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/921967020b3b

Merge


Changeset: 621eda7235d2
Author:    minqi
Date:      2013-09-16 15:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/621eda7235d2

7164841: Improvements to the GC log file rotation
Summary: made changes to easily identify current log file in rotation. Parameterize the input with %t for time replacement in file name.
Reviewed-by: ccheung, tschatzl, tamao, zgu
Contributed-by: yumin.qi at oracle.com

! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/ostream.hpp

Changeset: 535973ddf22c
Author:    minqi
Date:      2013-09-16 18:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/535973ddf22c

Merge


Changeset: 88d6b9a1c27c
Author:    mseledtsov
Date:      2013-09-17 20:09 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/88d6b9a1c27c

8016029: test runtime/6878713/Test6878713.sh failed
Summary: Rewrote test in Java; updated the test condition to reflect latest changes in the source
Reviewed-by: dholmes, ctornqvi

- test/runtime/6878713/Test6878713.sh
- test/runtime/6878713/testcase.jar
+ test/runtime/ClassFile/OomWhileParsingRepeatedJsr.java
+ test/runtime/ClassFile/testcase.jar

Changeset: 6f45933aef35
Author:    mseledtsov
Date:      2013-09-17 20:20 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6f45933aef35

7149464: [TESTBUG] Test runtime/7020373/Test7020373.sh failed to clean up files after test
Summary: Re-wrote in Java, this also eliminated temporary result file; set upper limit on malloc'd memory
Reviewed-by: dcubed, dholmes, ccheung

- test/runtime/7020373/Test7020373.sh
- test/runtime/7020373/testcase.jar
+ test/runtime/ClassFile/JsrRewriting.java
+ test/runtime/ClassFile/JsrRewritingTestCase.jar

Changeset: 41e6ae9f6dd7
Author:    zgu
Date:      2013-09-18 12:52 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/41e6ae9f6dd7

Merge

- test/runtime/6878713/Test6878713.sh
- test/runtime/6878713/testcase.jar
- test/runtime/7020373/Test7020373.sh
- test/runtime/7020373/testcase.jar

Changeset: 8e94527f601e
Author:    bpittore
Date:      2013-09-11 20:03 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8e94527f601e

8024007: Misc. cleanup of static agent code
Summary: Minor cleanup of static agent code from 8014135
Reviewed-by: dcubed, sspitsyn

! src/os/windows/vm/os_windows.cpp
! src/share/vm/prims/jvmti.xml
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/thread.cpp

Changeset: de88570fabfc
Author:    dholmes
Date:      2013-09-11 00:38 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/de88570fabfc

8024256: Minimal VM build is broken with PCH disabled
Reviewed-by: coleenp, twisti

! make/excludeSrc.make
! src/share/vm/gc_implementation/shared/allocationStats.hpp
! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp
! src/share/vm/memory/binaryTreeDictionary.cpp
! src/share/vm/utilities/yieldingWorkgroup.hpp

Changeset: 4c9d415db1c5
Author:    dholmes
Date:      2013-09-11 23:49 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/4c9d415db1c5

Merge


Changeset: b1491b0303ee
Author:    bdelsart
Date:      2013-09-13 07:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b1491b0303ee

Merge


Changeset: 10efeefa6485
Author:    dholmes
Date:      2013-09-13 21:36 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/10efeefa6485

8024505: [TESTBUG] update test groups for additional tests that can't run on the minimal VM
Reviewed-by: coleenp, hseigel

! test/TEST.groups

Changeset: cc5b40a76049
Author:    bdelsart
Date:      2013-09-18 21:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/cc5b40a76049

Merge

! src/share/vm/runtime/thread.cpp

Changeset: 7944aba7ba41
Author:    ehelin
Date:      2013-08-12 17:37 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7944aba7ba41

8015107: NPG: Use consistent naming for metaspace concepts
Reviewed-by: coleenp, mgerdin, hseigel

! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceCounters.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/arrayOop.hpp
! src/share/vm/oops/instanceOop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/services/memoryPool.cpp
! src/share/vm/services/memoryService.cpp
+ test/gc/arguments/TestCompressedClassFlags.java
- test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java
+ test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java
! test/gc/metaspace/TestMetaspaceMemoryPool.java
! test/gc/metaspace/TestMetaspacePerfCounters.java
! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java
! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java
! test/runtime/CompressedOops/CompressedKlassPointerAndOops.java

Changeset: 440edcf30231
Author:    mgerdin
Date:      2013-09-11 08:57 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/440edcf30231

8024176: [macosx] gc/metaspace/ClassMetaspaceSizeInJmapHeap.java failed since jdk8b105, hs25b47
Summary: The code for reading compressed klass pointers in the sa-agent on Mac used readCompOopAddress instead of readCompKlassAddress, this is wrong but has been hidden because compressed oops and compressed klasses has used the same base address in the past.
Reviewed-by: sla, jmasa
Contributed-by: stefan.johansson at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java

Changeset: f7bc2ab5f659
Author:    tschatzl
Date:      2013-09-11 10:14 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f7bc2ab5f659

8016825: Large pages for the heap broken on Windows for compressed oops
Summary: Correctly pass the requested base address for the heap to the OS function to reserve memory.
Reviewed-by: brutisso, stefank

! src/os/windows/vm/os_windows.cpp

Changeset: ff218fdb30ba
Author:    tschatzl
Date:      2013-09-11 10:19 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ff218fdb30ba

8021823: G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs
Summary: Correctly calculate the initialization value for the shift between object start and bitmap bit in the G1 mark bitmaps.
Reviewed-by: tonyp

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
+ test/gc/TestObjectAlignment.java

Changeset: 040895ec3920
Author:    tschatzl
Date:      2013-09-11 12:03 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/040895ec3920

Merge


Changeset: 24e87613ee58
Author:    mgerdin
Date:      2013-09-11 09:37 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/24e87613ee58

8009561: NPG: Metaspace fragmentation when retiring a Metachunk
Summary: Use best-fit block-splitting freelist allocation from the block freelist.
Reviewed-by: jmasa, stefank

! src/share/vm/memory/metaspace.cpp

Changeset: 6608fa23708f
Author:    mgerdin
Date:      2013-09-11 06:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6608fa23708f

Merge


Changeset: 40136aa2cdb1
Author:    tschatzl
Date:      2013-09-11 16:25 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/40136aa2cdb1

8010722: assert: failed: heap size is too big for compressed oops
Summary: Use conservative assumptions of required alignment for the various garbage collector components into account when determining the maximum heap size that supports compressed oops. Using this conservative value avoids several circular dependencies in the calculation.
Reviewed-by: stefank, dholmes

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.hpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/thread.cpp
+ test/gc/arguments/TestUseCompressedOopsErgo.java
+ test/gc/arguments/TestUseCompressedOopsErgoTools.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: b82260e84582
Author:    tschatzl
Date:      2013-09-11 18:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b82260e84582

Merge


Changeset: d6c266999345
Author:    ehelin
Date:      2013-09-12 10:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d6c266999345

8023476: Metaspace capacity > reserved
Reviewed-by: stefank, hseigel, mgerdin

! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceCounters.cpp

Changeset: c4c768305a8f
Author:    stefank
Date:      2013-09-12 10:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c4c768305a8f

8024638: Count and expose the amount of committed memory in the metaspaces
Reviewed-by: brutisso, ehelin

! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/virtualspace.cpp
! src/share/vm/runtime/virtualspace.hpp

Changeset: 335b388c4b28
Author:    stefank
Date:      2013-09-13 22:21 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/335b388c4b28

8024651: Remove the incorrect usage of Metablock::overhead()
Reviewed-by: brutisso, mgerdin, coleenp, jmasa

! src/share/vm/memory/metablock.cpp
! src/share/vm/memory/metablock.hpp
! src/share/vm/memory/metaspace.cpp

Changeset: 9e11762cee52
Author:    stefank
Date:      2013-09-13 22:22 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9e11762cee52

8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize
Reviewed-by: jwilhelm, brutisso, tschatzl

! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp
! src/share/vm/memory/collectorPolicy.cpp
+ test/gc/metaspace/TestMetaspaceSizeFlags.java
! test/testlibrary/OutputAnalyzerTest.java
! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java

Changeset: 8227700da288
Author:    stefank
Date:      2013-09-13 22:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8227700da288

8024751: Fix bugs in TraceMetadata
Reviewed-by: jmasa, brutisso

! src/share/vm/memory/metaspace.cpp

Changeset: 8c5e6482cbfc
Author:    stefank
Date:      2013-09-13 22:25 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8c5e6482cbfc

8024752: Log TraceMetadata* output to gclog_or_tty instead of tty
Reviewed-by: brutisso, mgerdin, coleenp

! src/share/vm/memory/metaspace.cpp
! src/share/vm/runtime/virtualspace.cpp
! src/share/vm/runtime/virtualspace.hpp

Changeset: 9cb63cd234a0
Author:    shade
Date:      2013-09-13 07:57 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9cb63cd234a0

8024671: G1 generates assert error messages in product builds
Reviewed-by: brutisso, tschatzl

! src/share/vm/gc_implementation/g1/g1CardCounts.cpp
! src/share/vm/gc_implementation/g1/g1CardCounts.hpp

Changeset: 884ed7a10f09
Author:    tschatzl
Date:      2013-09-16 09:41 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/884ed7a10f09

Merge

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 23ae5a04724d
Author:    tschatzl
Date:      2013-09-16 10:20 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/23ae5a04724d

8024396: VM crashing with assert(!UseLargePages || UseParallelOldGC || use_large_pages) failed: Wrong alignment to use large pages
Summary: Loosen wrong assert for UseParallelOldGC to UseParallelGC
Reviewed-by: stefank, brutisso

! src/share/vm/memory/universe.cpp
+ test/gc/arguments/TestAlignmentToUseLargePages.java

Changeset: f9b58dbeab91
Author:    tschatzl
Date:      2013-09-16 13:32 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f9b58dbeab91

Merge


Changeset: 17deed6716af
Author:    tschatzl
Date:      2013-09-17 12:04 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/17deed6716af

8024914: Swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp
Summary: Incorrect usage of idx_t where bm_word_t is appropriate.
Reviewed-by: tschatzl, brutisso
Contributed-by: Dan Horak 

! src/share/vm/utilities/bitMap.inline.hpp

Changeset: 5767996b7b7b
Author:    jwilhelm
Date:      2013-09-17 14:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5767996b7b7b

8024884: Test name changed, test list not updated
Summary: Updated the test list with the new test name.
Reviewed-by: brutisso, ehelin

! test/TEST.groups

Changeset: fac394091d73
Author:    jwilhelm
Date:      2013-09-18 00:08 +0000
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/fac394091d73

Merge


Changeset: 73d0d0218068
Author:    ehelin
Date:      2013-09-17 20:59 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/73d0d0218068

8024718: Metaspace performance counters and memory pools should report the same data
Reviewed-by: stefank, dholmes, coleenp

! src/share/vm/memory/metaspaceCounters.cpp
! src/share/vm/memory/metaspaceCounters.hpp
! src/share/vm/services/memoryPool.cpp
! src/share/vm/services/memoryPool.hpp
! src/share/vm/services/memoryUsage.hpp
! test/gc/metaspace/TestMetaspaceMemoryPool.java
! test/gc/metaspace/TestMetaspacePerfCounters.java
+ test/gc/metaspace/TestPerfCountersAndMemoryPools.java
! test/testlibrary/com/oracle/java/testlibrary/InputArguments.java

Changeset: 2f426063daea
Author:    tschatzl
Date:      2013-09-18 10:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2f426063daea

8024662: gc/arguments/TestUseCompressedOopsErgo.java does not compile.
Summary: Fix compilation error and use of an outdated VM option in the test
Reviewed-by: stefank, jwilhelm

! test/gc/arguments/TestUseCompressedOopsErgoTools.java

Changeset: 9044964f9163
Author:    tschatzl
Date:      2013-09-18 13:18 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9044964f9163

8024669: Native OOME when allocating after changes to maximum heap supporting Coops sizing on sparcv9
Summary: After changes in 8010722 the ergonomics for calculating the size of the heap that supports zero based compressed oops changed. This lead to the VM actually using zero based compressed oops. Due to low default HeapBaseMinAddress, the OS mapping in the application image at the same address, and limitations of the malloc implementation on Solaris this resulted in very little C heap available for the VM. So the VM immediately gives a native OOME when the machine has lots of physical memory (>=32G). The solution is to increase the HeapBaseMinAddress so that the VM has enough C heap.
Reviewed-by: kvn, brutisso

! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp

Changeset: 719e886d4f72
Author:    tschatzl
Date:      2013-09-18 15:59 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/719e886d4f72

Merge


Changeset: 06ae47d9d088
Author:    tschatzl
Date:      2013-09-19 09:26 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/06ae47d9d088

Merge

! src/os/linux/vm/os_linux.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/thread.cpp
- test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java

Changeset: 179cd89fb279
Author:    tschatzl
Date:      2013-09-19 09:34 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/179cd89fb279

Merge

! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/thread.cpp
! test/TEST.groups

Changeset: 8c83625e3a53
Author:    adlertz
Date:      2013-09-12 23:13 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8c83625e3a53

8024646: Remove LRG_List container, replace it with GrowableArray
Summary: We already have GrowableArray, use it instead of LRG_List
Reviewed-by: kvn

! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/coalesce.hpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/live.hpp

Changeset: 3a4e6c929bf3
Author:    twisti
Date:      2013-09-12 14:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3a4e6c929bf3

8024275: During CTW: assert(sig_bt[member_arg_pos] == T_OBJECT) failed: dispatch argument must be an object
Reviewed-by: kvn, vlivanov

! src/share/vm/classfile/classLoader.cpp

Changeset: 591b49112612
Author:    twisti
Date:      2013-09-12 18:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/591b49112612

Merge


Changeset: 01b268b3080a
Author:    vlivanov
Date:      2013-09-13 04:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/01b268b3080a

8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log)
Reviewed-by: twisti, kvn, sla

! src/share/tools/LogCompilation/README
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/ostream.cpp

Changeset: 69f26e8e09f9
Author:    twisti
Date:      2013-09-13 16:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/69f26e8e09f9

8024760: add more types, fields and constants to VMStructs
Reviewed-by: kvn, coleenp

! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java
! src/share/vm/gc_implementation/g1/ptrQueue.hpp
! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/klassVtable.hpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: ae3e68933caf
Author:    adlertz
Date:      2013-09-17 05:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ae3e68933caf

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 22194f27fbfb
Author:    ctornqvi
Date:      2013-09-17 16:55 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/22194f27fbfb

8014905: [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk
Summary: Change JDKToolFinder to look in compile.jdk if the executable cannot be found in test.jdk
Reviewed-by: dholmes, hseigel

! test/TEST.groups
! test/gc/TestVerifyDuringStartup.java
! test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java

Changeset: 2c98370f2611
Author:    ctornqvi
Date:      2013-09-17 23:12 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2c98370f2611

Merge


Changeset: 6d7eba360ba4
Author:    anoll
Date:      2013-09-17 08:39 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6d7eba360ba4

8024128: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation
Summary: Increase interpreter size for x86 template interpreter
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/templateInterpreter_x86.hpp

Changeset: a4788ba67e20
Author:    adlertz
Date:      2013-09-17 16:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a4788ba67e20

Merge


Changeset: b2e698d2276c
Author:    drchase
Date:      2013-09-13 22:38 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b2e698d2276c

8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation
Summary: Enhance method resolution and resulting data structures, plus some refactoring.
Reviewed-by: twisti, acorn, jrose

! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/ci/ciField.cpp
! src/share/vm/ci/ciField.hpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciSymbol.hpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/code/compiledIC.cpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/code/vtableStubs.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/cpCache.hpp
! src/share/vm/oops/fieldStreams.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/klassVtable.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/symbol.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/fieldDescriptor.cpp
! src/share/vm/runtime/fieldDescriptor.hpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/runtime/reflectionUtils.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 67bae56fdd69
Author:    jrose
Date:      2013-09-17 20:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/67bae56fdd69

Merge


Changeset: ab274453d37f
Author:    anoll
Date:      2013-09-18 07:22 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ab274453d37f

8022883: Assertion failed: sweptCount >= flushedCount + markedCount + zombifiedCount
Summary: Provide correct number of visited nmethods to Tracing
Reviewed-by: kvn, iveresov

! src/share/vm/runtime/sweeper.cpp

Changeset: 04cbe2026912
Author:    rbackman
Date:      2013-09-18 09:31 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/04cbe2026912

Merge


Changeset: 2795dff62b6c
Author:    iveresov
Date:      2013-09-18 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2795dff62b6c

8023542: Test java/io/File/CheckPermission.java fails due to unfinished recursion (java.lang.StackOverflowError) when JIT'ed code (-client,-server) is running
Summary: Move null check before klass reference materialization in checkcast
Reviewed-by: kvn, roland

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp

Changeset: da051ce490eb
Author:    adlertz
Date:      2013-09-19 18:01 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/da051ce490eb

Merge

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/utilities/ostream.cpp
! test/TEST.groups

Changeset: 566db1b0e6ef
Author:    amurillo
Date:      2013-09-20 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/566db1b0e6ef

Merge

- test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java
- test/runtime/6878713/Test6878713.sh
- test/runtime/6878713/testcase.jar
- test/runtime/7020373/Test7020373.sh
- test/runtime/7020373/testcase.jar

Changeset: bf13c3da3d11
Author:    amurillo
Date:      2013-09-20 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/bf13c3da3d11

Added tag hs25-b51 for changeset 566db1b0e6ef

! .hgtags

Changeset: c81dd5393a5e
Author:    tbell
Date:      2013-09-25 12:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c81dd5393a5e

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties

Changeset: fff4842215d1
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/fff4842215d1

Added tag jdk8-b109 for changeset c81dd5393a5e

! .hgtags

Changeset: 8a6a85321d3a
Author:    amurillo
Date:      2013-09-20 11:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8a6a85321d3a

8025127: new hotspot build - hs25-b52
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 63147986a428
Author:    dcubed
Date:      2013-09-18 07:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/63147986a428

8019835: Strings interned in different threads equal but does not ==
Summary: Add -XX:+VerifyStringTableAtExit option and code to verify StringTable invariants.
Reviewed-by: rdurbin, sspitsyn, coleenp

! 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/runtime/globals.hpp
! src/share/vm/runtime/java.cpp

Changeset: dfae98867ee8
Author:    dholmes
Date:      2013-09-18 20:08 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/dfae98867ee8

8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps
Reviewed-by: alanb, chegar, dholmes, ksrini
Contributed-by: Mike Duigou 

! src/share/vm/runtime/arguments.cpp

Changeset: c1d7040a1183
Author:    sgabdura
Date:      2013-09-18 16:48 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c1d7040a1183

8022836: JVM crashes in JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR and GET_OWNED_MONITOR
Summary: Check that the _java_thread parameter is valid when it is possible that the JavaThread has exited after the initial checks were made in generated/jvmtifiles/jvmtiEnter.cpp: jvmti_GetCurrentContendedMonitor()
Reviewed-by: dcubed, dsamersoff

! src/share/vm/prims/jvmtiEnvBase.hpp

Changeset: 8c84f04ff977
Author:    kevinw
Date:      2013-09-18 19:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8c84f04ff977

Merge


Changeset: 6eb908998b32
Author:    kevinw
Date:      2013-09-19 08:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6eb908998b32

Merge


Changeset: 9ed97b511b26
Author:    hseigel
Date:      2013-09-19 11:04 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9ed97b511b26

8024517: runtime/CDSCompressedKPtrs/XShareAuto.java failed with RuntimeException
Summary: Make sure CDS is off by default when running server compiler.
Reviewed-by: dholmes, coleenp

! src/share/vm/runtime/arguments.cpp
! test/runtime/CDSCompressedKPtrs/XShareAuto.java

Changeset: 4f9a42c33738
Author:    coleenp
Date:      2013-09-20 09:30 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/4f9a42c33738

8022887: Assertion hit while using class and redefining it with RedefineClasses simultaneously
Summary: Need to refetch each method from InstanceKlass after all safepoints.  Removed leaky PreviousVersionInfo code.
Reviewed-by: dcubed, sspitsyn

! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiImpl.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/handles.inline.hpp

Changeset: f201713502e0
Author:    coleenp
Date:      2013-09-20 09:44 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f201713502e0

Merge


Changeset: 1b03bed31241
Author:    allwin
Date:      2013-09-17 17:16 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/1b03bed31241

7196151: ParserTest SEGv on solaris
Reviewed-by: sla, coleenp, ctornqvi, dsamersoff

! src/share/vm/services/diagnosticArgument.cpp

Changeset: e5a25e4ae509
Author:    mgerdin
Date:      2013-09-20 10:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e5a25e4ae509

Merge


Changeset: 7c29904fdfa2
Author:    coleenp
Date:      2013-09-20 18:34 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7c29904fdfa2

8014956: nashorn/api/javaaccess/MethodAccessTest.java test fails on sparc-solaris 64
Summary: reference_map[] array had uninitialized junk that was causing a bogus bootstrap method to be found.
Reviewed-by: hseigel, dcubed, sspitsyn

! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp

Changeset: df03413ad1a9
Author:    coleenp
Date:      2013-09-21 01:45 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/df03413ad1a9

Merge


Changeset: 0f37d1badced
Author:    dcubed
Date:      2013-09-20 12:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/0f37d1badced

Merge

! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: a7609ec351d6
Author:    dcubed
Date:      2013-09-20 18:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a7609ec351d6

Merge

! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
- test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java

Changeset: 8ddc26f62476
Author:    sla
Date:      2013-09-22 06:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8ddc26f62476

6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions"
Reviewed-by: sla, dsamersoff
Contributed-by: Yasumasa Suenaga 

! src/share/vm/services/attachListener.cpp

Changeset: 1f42d3ec1759
Author:    dsamersoff
Date:      2013-09-22 18:49 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/1f42d3ec1759

7133122: SA throws sun.jvm.hotspot.debugger.UnmappedAddressException when it should not
Summary: replace PT_LOAD segment with library segment when necessary
Reviewed-by: dholmes, sla

! agent/src/os/linux/ps_core.c

Changeset: ae2edb3df7fb
Author:    dsamersoff
Date:      2013-09-22 18:07 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ae2edb3df7fb

Merge


Changeset: 084b21cd0228
Author:    iklam
Date:      2013-09-23 08:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/084b21cd0228

8025088: Missing cases for JVM_CONSTANT_MethodHandleInError cause crash if debugger steps into error-tagged method handle
Summary: Need to refetch each method from InstanceKlass after all safepoints.  Removed leaky PreviousVersionInfo code.
Reviewed-by: coleenp, sspitsyn

! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp

Changeset: e8a0010ba69e
Author:    zgu
Date:      2013-09-25 13:03 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e8a0010ba69e

Merge


Changeset: 891687731b59
Author:    anoll
Date:      2013-09-24 15:56 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/891687731b59

7009641: Don't fail VM when CodeCache is full
Summary: Allocation in the code cache returns NULL instead of failing the entire VM
Reviewed-by: kvn, iveresov

! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/vtableStubs_x86_32.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/share/vm/code/compiledIC.cpp
! src/share/vm/code/compiledIC.hpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 1b64d46620a3
Author:    kvn
Date:      2013-09-24 16:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/1b64d46620a3

8022585: VM crashes when ran with -XX:+PrintInlining
Summary: use adr_at() to access inline info structures in growableArray. Add ability to specify print inlining per method.
Reviewed-by: twisti

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/library_call.cpp
+ test/compiler/print/PrintInlining.java

Changeset: f637d4dc21bb
Author:    adlertz
Date:      2013-09-26 08:48 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f637d4dc21bb

Merge


Changeset: 586fa1919a89
Author:    bpittore
Date:      2013-09-20 15:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/586fa1919a89

8014911: Should use SUPPORTS_NATIVE_CX8 define to help C/C++ compiler elide blocks of code
Summary: If SUPPORTS_NATIVE_CX8 true then supports_cx8() function hard coded to return 'true'
Reviewed-by: kvn, twisti, dholmes

! src/share/vm/runtime/vm_version.hpp

Changeset: 504d8f519adf
Author:    jiangli
Date:      2013-09-20 20:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/504d8f519adf

Merge


Changeset: d682c6e24fe3
Author:    bdelsart
Date:      2013-09-26 01:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d682c6e24fe3

Merge


Changeset: 60a2d625db36
Author:    bdelsart
Date:      2013-09-26 04:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/60a2d625db36

Merge


Changeset: 2c022e432e10
Author:    stefank
Date:      2013-09-20 10:53 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2c022e432e10

8024974: Incorrect use of GC_locker::is_active()
Summary: SymbolTable and StringTable can make calls to GC_locker::is_active() outside a safepoint. This isn't safe because the GC_locker active state (lock count) is only updated at a safepoint and only remains valid as long as _needs_gc is true. However, outside a safepoint_needs_gc can change to false at any time, which makes it impossible to do a correct call to is_active() in that context. In this case these calls can just be removed since the input argument to basic_add() should never be on the heap and so there's no need to check the GC_locker state. This change also adjusts the assert() in is_active() to makes sure all calls to this function are always done under a safepoint.
Reviewed-by: brutisso, dcubed
Contributed-by: per.liden at oracle.com

! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/memory/gcLocker.cpp
! src/share/vm/memory/gcLocker.hpp

Changeset: 9361de86a50f
Author:    stefank
Date:      2013-09-20 11:00 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9361de86a50f

8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize
Reviewed-by: coleenp, brutisso, mgerdin, jmasa

! src/share/vm/memory/metaspace.cpp

Changeset: b960c9df4f11
Author:    stefank
Date:      2013-09-21 10:09 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b960c9df4f11

8025096: Move the ChunkManager instances out of the VirtualSpaceLists
Reviewed-by: coleenp, mgerdin, jmasa

! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp

Changeset: 10cc3b624f8f
Author:    tschatzl
Date:      2013-09-24 10:14 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/10cc3b624f8f

Merge

- test/runtime/6878713/Test6878713.sh
- test/runtime/6878713/testcase.jar
- test/runtime/7020373/Test7020373.sh
- test/runtime/7020373/testcase.jar

Changeset: a19bea467577
Author:    tschatzl
Date:      2013-09-25 13:25 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a19bea467577

7163191: G1: introduce a "heap spanning table" abstraction
Summary: Add G1BiasedArray that is an array where each element represents a fixed-sized subdivision of the heap. Use this abstraction to refactor the HeapRegionSeq class.
Reviewed-by: brutisso

! make/excludeSrc.make
+ src/share/vm/gc_implementation/g1/g1BiasedArray.cpp
+ src/share/vm/gc_implementation/g1/g1BiasedArray.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp
! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp
! src/share/vm/prims/jni.cpp

Changeset: 03f493ce3a71
Author:    brutisso
Date:      2013-09-25 17:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/03f493ce3a71

8025228: assert(new_entry->reserved_words() == vs_word_size) fails in nightly
Reviewed-by: mgerdin, tschatzl, jmasa

! src/share/vm/memory/metaspace.cpp
! src/share/vm/prims/jni.cpp

Changeset: 461159cd7a91
Author:    tschatzl
Date:      2013-09-26 12:18 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/461159cd7a91

Merge

! src/share/vm/classfile/symbolTable.cpp

Changeset: 3da9fad1391e
Author:    tschatzl
Date:      2013-09-26 06:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3da9fad1391e

Merge


Changeset: 58043478c26d
Author:    amurillo
Date:      2013-09-26 13:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/58043478c26d

Merge


Changeset: 6209b0ed51c0
Author:    amurillo
Date:      2013-09-26 13:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6209b0ed51c0

Added tag hs25-b52 for changeset 58043478c26d

! .hgtags

Changeset: ebfa5793d349
Author:    katleman
Date:      2013-10-02 13:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ebfa5793d349

Added tag jdk8-b110 for changeset 6209b0ed51c0

! .hgtags

Changeset: 24250c363d7f
Author:    amurillo
Date:      2013-09-26 13:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/24250c363d7f

8025536: new hotspot build - hs25-b53
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 899ecf76b570
Author:    dsimms
Date:      2013-09-25 13:58 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/899ecf76b570

8023956: Provide a work-around to broken Linux 32 bit "Exec Shield" using CS for NX emulation (crashing with SI_KERNEL)
Summary: Execute some code at a high virtual address value, and keep mapped
Reviewed-by: coleenp, zgu

! src/os/linux/vm/os_linux.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.hpp

Changeset: 5b1191bf0b4b
Author:    ctornqvi
Date:      2013-09-25 17:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5b1191bf0b4b

8024677: [TESTBUG] Move tests for classes in /testlibrary
Summary: Moved the tests to /testlibrary_tests and updated TEST.groups
Reviewed-by: dholmes, sla

! test/TEST.groups
- test/testlibrary/AssertsTest.java
- test/testlibrary/OutputAnalyzerReportingTest.java
- test/testlibrary/OutputAnalyzerTest.java
+ test/testlibrary_tests/AssertsTest.java
+ test/testlibrary_tests/OutputAnalyzerReportingTest.java
+ test/testlibrary_tests/OutputAnalyzerTest.java

Changeset: c1fbf21c7397
Author:    ctornqvi
Date:      2013-09-25 17:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c1fbf21c7397

8024492: [TESTBUG] Test library class Platform.java needs to include methods for missing OS's and architectures
Summary: Added methods for 32bit, arm, ppc, x64 and x86
Reviewed-by: zgu, hseigel, mseledtsov

! test/testlibrary/com/oracle/java/testlibrary/Platform.java

Changeset: 190899198332
Author:    hseigel
Date:      2013-09-26 10:25 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/190899198332

7195622: CheckUnhandledOops has limited usefulness now
Summary: Enable CHECK_UNHANDLED_OOPS in fastdebug builds across all supported platforms.
Reviewed-by: coleenp, hseigel, dholmes, stefank, twisti, ihse, rdurbin
Contributed-by: lois.foltan at oracle.com

! make/bsd/makefiles/fastdebug.make
! make/linux/makefiles/fastdebug.make
! make/windows/makefiles/fastdebug.make
! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/dictionary.hpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/compiler/oopMap.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1OopClosures.hpp
! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp
! src/share/vm/interpreter/bytecodeTracer.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/memory/heapInspection.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceMirrorKlass.hpp
! src/share/vm/oops/instanceRefKlass.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/oops/oopsHierarchy.hpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/biasedLocking.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/javaCalls.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/services/classLoadingService.cpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/memoryManager.cpp
! src/share/vm/services/memoryPool.cpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/globalDefinitions_visCPP.hpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/taskqueue.hpp

Changeset: a5ac0873476c
Author:    zgu
Date:      2013-09-27 10:08 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a5ac0873476c

Merge

! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 36b97be47bde
Author:    acorn
Date:      2013-10-01 08:10 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/36b97be47bde

8011311: Private interface methods. Default conflicts:ICCE. no erased_super_default.
Reviewed-by: coleenp, bharadwaj, minqi

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/defaultMethods.cpp
! src/share/vm/classfile/defaultMethods.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/klassVtable.cpp

Changeset: de059a14e159
Author:    zgu
Date:      2013-10-01 08:54 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/de059a14e159

8022187: Missing ResourceMark crash when assertion using FormatBufferResource fails
Summary: Uses stack for the format buffer instead of resource memory
Reviewed-by: kvn, coleenp

! src/share/vm/utilities/array.hpp

Changeset: 90b27e931639
Author:    zgu
Date:      2013-10-01 09:21 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/90b27e931639

Merge


Changeset: 31f0118ea584
Author:    zgu
Date:      2013-10-01 11:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/31f0118ea584

Merge


Changeset: 72b7e96c1922
Author:    twisti
Date:      2013-09-26 12:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/72b7e96c1922

8024545: make develop and notproduct flag values available in product builds
Reviewed-by: dholmes, kvn

! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/globals_extension.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/classLoadingService.cpp
! src/share/vm/services/dtraceAttacher.cpp
! src/share/vm/services/management.cpp
! src/share/vm/services/memoryService.cpp

Changeset: c9ccd7b85f20
Author:    rbackman
Date:      2013-09-27 08:39 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c9ccd7b85f20

8024924: Intrinsify java.lang.Math.addExact
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/sparc.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/formssel.cpp
! src/share/vm/adlc/formssel.hpp
! src/share/vm/adlc/output_h.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/classes.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/ifnode.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/matcher.hpp
+ src/share/vm/opto/mathexactnode.cpp
+ src/share/vm/opto/mathexactnode.hpp
! src/share/vm/opto/multnode.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/subnode.hpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/vmStructs.cpp
+ test/compiler/intrinsics/mathexact/CondTest.java
+ test/compiler/intrinsics/mathexact/ConstantTest.java
+ test/compiler/intrinsics/mathexact/LoadTest.java
+ test/compiler/intrinsics/mathexact/LoopDependentTest.java
+ test/compiler/intrinsics/mathexact/NonConstantTest.java
+ test/compiler/intrinsics/mathexact/Verify.java

Changeset: 510fbd28919c
Author:    anoll
Date:      2013-09-27 10:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/510fbd28919c

8020151: PSR:PERF Large performance regressions when code cache is filled
Summary: Code cache sweeping based on method hotness; removed speculatively disconnect
Reviewed-by: kvn, iveresov

! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp
! src/share/vm/trace/trace.xml

Changeset: a07c25e4f67e
Author:    adlertz
Date:      2013-09-27 12:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a07c25e4f67e

Merge

! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/services/attachListener.cpp

Changeset: 1c3486050433
Author:    adlertz
Date:      2013-09-27 15:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/1c3486050433

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: e8e077292da3
Author:    iignatyev
Date:      2013-09-28 12:32 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e8e077292da3

8024678: Java source files in hotspot/test/testlibrary should not use @author tag in JavaDoc
Reviewed-by: twisti

! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathDirEntry.java
! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarEntry.java
! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarInDirEntry.java
! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassesListInFile.java
! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/CompileTheWorld.java
! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java
! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java
! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Utils.java

Changeset: 303826f477c6
Author:    iignatyev
Date:      2013-09-28 12:32 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/303826f477c6

8023452: TestCase$Helper(java.lang.Object) must be osr_compiled
Reviewed-by: kvn

! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
! test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java

Changeset: f2512d89ad0c
Author:    twisti
Date:      2013-09-28 12:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f2512d89ad0c

8025613: clang: remove -Wno-unused-value
Reviewed-by: iveresov

! agent/src/os/linux/LinuxDebuggerLocal.c
! agent/src/os/linux/ps_proc.c
! agent/src/os/linux/salibelf.c
! agent/src/os/linux/symtab.c
! make/bsd/makefiles/gcc.make
! make/linux/makefiles/gcc.make
! src/cpu/x86/vm/assembler_x86.cpp
! src/share/vm/classfile/defaultMethods.cpp

Changeset: 29bdcf12457c
Author:    shade
Date:      2013-09-27 11:52 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/29bdcf12457c

8014447: Object.hashCode intrinsic breaks inline caches
Summary: Try to inline as normal method first, then fall back to intrinsic.
Reviewed-by: kvn, twisti

! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/library_call.cpp

Changeset: d8d059e90ec1
Author:    twisti
Date:      2013-09-30 15:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d8d059e90ec1

8025599: Missing store barrier with OptimizeStringConcat
Reviewed-by: kvn, twisti
Contributed-by: Axel Siebenborn 

! src/share/vm/opto/graphKit.cpp

Changeset: dc261f466b6d
Author:    drchase
Date:      2013-09-27 13:36 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/dc261f466b6d

8025260: Methodhandles/JSR292: NullPointerException (NPE) thrown instead of AbstractMethodError (AME)
Summary: Copied null-checks from templateInterpreter_CPU into methodHandles_CPU
Reviewed-by: jrose, twisti

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
+ test/compiler/jsr292/methodHandleExceptions/ByteClassLoader.java
+ test/compiler/jsr292/methodHandleExceptions/C.java
+ test/compiler/jsr292/methodHandleExceptions/I.java
+ test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java

Changeset: cacc4c6bfc80
Author:    vlivanov
Date:      2013-10-02 06:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/cacc4c6bfc80

8025233: Move sun.invoke.Stable into java.lang.invoke package
Reviewed-by: twisti, iveresov

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/vmSymbols.hpp

Changeset: 268e7a2178d7
Author:    iveresov
Date:      2013-10-03 16:38 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/268e7a2178d7

Merge

! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/defaultMethods.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/services/classLoadingService.cpp

Changeset: d68894a09c7c
Author:    jiangli
Date:      2013-09-27 13:49 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d68894a09c7c

8024990: JT_JDK: 11 failures with SIGSEGV on arm-sflt platforms in nightly fastdebug build.
Summary: Enable patching for load_appendix_id.
Reviewed-by: kvn, dlong, bdelsart

! src/share/vm/c1/c1_Runtime1.cpp

Changeset: 5186dcaca431
Author:    jiangli
Date:      2013-09-27 13:53 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5186dcaca431

Merge

! src/share/vm/c1/c1_Runtime1.cpp
- test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java
- test/runtime/6878713/Test6878713.sh
- test/runtime/6878713/testcase.jar
- test/runtime/7020373/Test7020373.sh
- test/runtime/7020373/testcase.jar

Changeset: d0cfa6502dfe
Author:    jprovino
Date:      2013-10-03 10:25 -0400
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d0cfa6502dfe

Merge

! src/share/vm/c1/c1_Runtime1.cpp

Changeset: 100614790c1e
Author:    vladidan
Date:      2013-10-03 10:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/100614790c1e

Merge


Changeset: c319b188c7b2
Author:    tschatzl
Date:      2013-09-26 12:49 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c319b188c7b2

8014078: G1: improve remembered set summary information by providing per region type information
Summary: Add memory consumption breakdown on a per region type in the G1 remembered set summary statistics. This simplifies remembered set memory consumption analysis.
Reviewed-by: brutisso

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp
! test/gc/g1/TestSummarizeRSetStats.java
+ test/gc/g1/TestSummarizeRSetStatsPerRegion.java
+ test/gc/g1/TestSummarizeRSetStatsTools.java

Changeset: bc918fd1e584
Author:    mgerdin
Date:      2013-09-27 10:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/bc918fd1e584

8025279: metaspace/flags/maxMetaspaceSize throws OOM: out of Compressed Klass space
Summary: Only put "Compressed class space" as OOM cause if actually using Compressed class space
Reviewed-by: jwilhelm, stefank, ehelin, coleenp

! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp

Changeset: 4fa18058548e
Author:    tschatzl
Date:      2013-09-27 11:18 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/4fa18058548e

Merge


Changeset: ccef6e165e8b
Author:    tschatzl
Date:      2013-09-27 13:41 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ccef6e165e8b

Merge


Changeset: d55c004e1d4d
Author:    mgerdin
Date:      2013-09-24 14:46 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d55c004e1d4d

8025305: Cleanup CardTableModRefBS usage in G1
Summary: Move some G1 specific code from CardTableModRefBS to G1SATBCardTableModRefBS.
Reviewed-by: brutisso, tschatzl, ehelin

! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp
! src/share/vm/gc_implementation/g1/g1CardCounts.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp
! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.hpp

Changeset: 7ec10139bf37
Author:    tschatzl
Date:      2013-09-30 12:43 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7ec10139bf37

8025441: G1: assert "assert(thread < _num_vtimes) failed: just checking" fails when G1ConcRefinementThreads > ParallelGCThreads
Summary: The initialization for the remembered set summary data structures used the wrong thread count, i.e. number of worker threads instead of number of refinement threads.
Reviewed-by: brutisso

! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp
! src/share/vm/gc_implementation/g1/g1RemSetSummary.hpp
+ test/gc/g1/TestSummarizeRSetStatsThreads.java

Changeset: 9de9169ddde6
Author:    brutisso
Date:      2013-10-01 07:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9de9169ddde6

8025605: G1: Heap expansion logging misleading for fully expanded heap
Reviewed-by: tschatzl, jwilhelm, jmasa

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 9ecd6d3782b1
Author:    ehelin
Date:      2013-10-01 15:21 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9ecd6d3782b1

8025313: MetaspaceMemoryPool incorrectly reports undefined size for max
Reviewed-by: stefank, tschatzl

! src/share/vm/memory/collectorPolicy.cpp

Changeset: 77a774ab3cf0
Author:    mgerdin
Date:      2013-10-02 14:33 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/77a774ab3cf0

8012525: gc/metaspace/G1AddMetaspaceDependency.java Test fails a safepoint timeout assertion or hangs.
Reviewed-by: brutisso, tschatzl

! test/gc/metaspace/G1AddMetaspaceDependency.java

Changeset: 6e22e7042433
Author:    ehelin
Date:      2013-09-30 11:39 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6e22e7042433

8025226: TestPerfCountersAndMemoryPools.java fails with -Xmixed or -Xcomp
Reviewed-by: brutisso, mgerdin

! test/gc/metaspace/TestPerfCountersAndMemoryPools.java

Changeset: 379ef2cc19c0
Author:    ehelin
Date:      2013-10-02 18:24 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/379ef2cc19c0

Merge


Changeset: ab68fc0101ce
Author:    jwilhelm
Date:      2013-10-03 13:19 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ab68fc0101ce

8025855: Simplify GenRemSet code slightly
Summary: Remove a few redundant switch-statements
Reviewed-by: jcoomes, tschatzl

! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/genRemSet.cpp

Changeset: c49c7f835e8d
Author:    jwilhelm
Date:      2013-10-03 17:16 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c49c7f835e8d

8025853: Remove unnecessary uses of GenerationSizer
Summary: Removed stray includes and some minor cleanup of GenerationSizer
Reviewed-by: tschatzl, jcoomes

! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp

Changeset: 798522662fcd
Author:    jcoomes
Date:      2013-10-04 13:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/798522662fcd

Merge

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp

Changeset: 562a3d356de6
Author:    amurillo
Date:      2013-10-04 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/562a3d356de6

Merge

- test/testlibrary/AssertsTest.java
- test/testlibrary/OutputAnalyzerReportingTest.java
- test/testlibrary/OutputAnalyzerTest.java

Changeset: f6962730bbde
Author:    amurillo
Date:      2013-10-04 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f6962730bbde

Added tag hs25-b53 for changeset 562a3d356de6

! .hgtags

Changeset: 02d171a3b5d1
Author:    cl
Date:      2013-10-10 10:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/02d171a3b5d1

Added tag jdk8-b111 for changeset f6962730bbde

! .hgtags


From lana.steuck at oracle.com  Fri Oct 11 16:54:51 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 11 Oct 2013 23:54:51 +0000
Subject:  hg: jdk8/awt/jdk: 132 new changesets
Message-ID: <20131012002302.5AEBD62FBA@hg.openjdk.java.net>

Changeset: a7dd84b9557c
Author:    cl
Date:      2013-09-19 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a7dd84b9557c

Added tag jdk8-b108 for changeset 006aaa5f069e

! .hgtags

Changeset: 946f3fd5f8bf
Author:    tbell
Date:      2013-09-25 12:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/946f3fd5f8bf

8025411: JPRT to switch to the new Win platforms for JDK8 builds this week
Reviewed-by: ksrini, katleman

! make/jprt.properties
! makefiles/jprt.properties

Changeset: f8c9a4b80148
Author:    cl
Date:      2013-09-26 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f8c9a4b80148

Added tag jdk8-b109 for changeset 946f3fd5f8bf

! .hgtags

Changeset: 529cd4de1823
Author:    prr
Date:      2013-09-26 15:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/529cd4de1823

7092764: java.awt.font.TransformAttribute.equals(null) throws NPE
Reviewed-by: jgodinez, jchen

! src/share/classes/java/awt/font/TransformAttribute.java
+ test/java/awt/font/TransformAttribute/TransformEqualityTest.java

Changeset: 1bcd48cfb7be
Author:    ceisserer
Date:      2013-09-26 16:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1bcd48cfb7be

8024895: xrender MaskImage cache isn't accounting for change in alpha
Reviewed-by: prr, jchen

! src/solaris/classes/sun/java2d/xr/XRMaskImage.java
+ test/java/awt/image/DrawImage/EABlitTest.java

Changeset: dae020405903
Author:    lana
Date:      2013-09-26 17:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dae020405903

Merge


Changeset: 3b22833f2695
Author:    lana
Date:      2013-09-26 17:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3b22833f2695

Merge

- src/macosx/classes/sun/lwawt/SelectionClearListener.java
- src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java

Changeset: 8708569b5524
Author:    sjiang
Date:      2013-09-18 08:51 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8708569b5524

8023954: MBean*Info.equals: throw NPE
Reviewed-by: dfuchs, dholmes

! src/share/classes/javax/management/MBeanAttributeInfo.java
! src/share/classes/javax/management/MBeanConstructorInfo.java
! src/share/classes/javax/management/MBeanFeatureInfo.java
! src/share/classes/javax/management/MBeanNotificationInfo.java
! src/share/classes/javax/management/MBeanOperationInfo.java
! src/share/classes/javax/management/MBeanParameterInfo.java
+ test/javax/management/MBeanInfo/MBeanInfoEqualsNPETest.java

Changeset: ee8b292ee568
Author:    weijun
Date:      2013-09-18 18:22 +0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ee8b292ee568

8012615: Realm.getRealmsList returns realms list in wrong
Reviewed-by: valeriep, xuelei

! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/Realm.java
! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
! test/sun/security/krb5/ParseCAPaths.java
! test/sun/security/krb5/krb5-capaths.conf

Changeset: e92635d6834c
Author:    alanb
Date:      2013-09-18 14:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e92635d6834c

8024883: (se) SelectableChannel.register throws NPE if fd >= 64k (lnx)
Reviewed-by: alanb, coffeys
Contributed-by: nmaurer at redhat.com, alan.bateman at oracle.com

! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EventPortWrapper.java
! test/java/nio/channels/Selector/LotsOfChannels.java
! test/java/nio/channels/Selector/SelectorLimit.java

Changeset: 07d73060e0da
Author:    weijun
Date:      2013-09-18 21:37 +0800
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/07d73060e0da

8011402: Move blacklisting certificate logic from hard code to data
Reviewed-by: erikj, mullan

! make/java/security/Makefile
! makefiles/CopyFiles.gmk
! src/share/classes/java/security/cert/Certificate.java
! src/share/classes/sun/security/util/UntrustedCertificates.java
! src/share/classes/sun/security/x509/X509CertImpl.java
+ src/share/lib/security/BlacklistedCertsConverter.java
+ src/share/lib/security/blacklisted.certs
+ src/share/lib/security/blacklisted.certs.pem
+ test/lib/security/CheckBlacklistedCerts.java

Changeset: b3a506a30fda
Author:    ewang
Date:      2013-09-18 15:13 +0100
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b3a506a30fda

8015762: TEST_BUG: java/nio/channels/DatagramChannel/AdaptDatagramSocket.java failing intermittently [win]
Reviewed-by: chegar, alanb

! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java

Changeset: 22e9f0067b5a
Author:    kizune
Date:      2013-09-19 17:04 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/22e9f0067b5a

8017248: Compiler Diacritics Issue
Reviewed-by: naoto

! src/share/classes/sun/launcher/LauncherHelper.java
+ test/tools/launcher/8017248/ClassA??.java
+ test/tools/launcher/8017248/test.sh

Changeset: 7557062d2dd2
Author:    plevart
Date:      2013-09-19 16:14 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7557062d2dd2

8011940: java.lang.Class.getAnnotations() always enters synchronized method
Reviewed-by: jfranck, chegar, psandoz, shade

! src/share/classes/java/lang/Class.java
+ test/java/lang/annotation/AnnotationsInheritanceOrderRedefinitionTest.java

Changeset: 278873b2b3f8
Author:    sherman
Date:      2013-09-19 10:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/278873b2b3f8

8023113: tools/jar/ChangeDir.java fails if /tmp/a exists
Summary: updated the test case
Reviewed-by: alanb

! test/tools/jar/ChangeDir.java

Changeset: f36714707c38
Author:    psandoz
Date:      2013-09-18 10:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f36714707c38

8025002: "".codePoints().sorted().iterator().hasNext() causes NegativeArraySizeException
Reviewed-by: henryjen, alanb

! src/share/classes/java/lang/CharSequence.java
! test/java/lang/CharSequence/DefaultTest.java

Changeset: 0ef7ddef9de0
Author:    psandoz
Date:      2013-09-19 20:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0ef7ddef9de0

8024405: Spliterators.spliterator should support CONCURRENT characteristic
Reviewed-by: martin

! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/Spliterators.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java

Changeset: 58fd427b454d
Author:    sla
Date:      2013-09-20 10:14 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/58fd427b454d

8024985: com/sun/jdi/StepTest.java failed since jdk8b107
Reviewed-by: dcubed

! test/com/sun/jdi/ExceptionEvents.java
! test/com/sun/jdi/FilterNoMatch.java
! test/com/sun/jdi/JDIScaffold.java
! test/com/sun/jdi/PopAndStepTest.java
! test/com/sun/jdi/RepStep.java
! test/com/sun/jdi/TestScaffold.java

Changeset: 6a1c70e191d4
Author:    sla
Date:      2013-09-20 10:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6a1c70e191d4

8024416: TESTBUG: com/sun/jdi/MethodEntryExitEvents.java: method entry count mismatch
Reviewed-by: dcubed

! test/com/sun/jdi/MethodEntryExitEvents.java

Changeset: afe857b13b62
Author:    kizune
Date:      2013-09-20 17:56 +0400
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/afe857b13b62

8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales
Reviewed-by: naoto, ksrini

- test/tools/launcher/8017248/ClassA??.java
- test/tools/launcher/8017248/test.sh
+ test/tools/launcher/DiacriticTest.java

Changeset: 94cc251d0c45
Author:    sla
Date:      2013-09-20 16:40 +0200
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/94cc251d0c45

7200277: [parfait] potential buffer overflow in npt/utf.c
Reviewed-by: dsamersoff, dcubed

! src/share/npt/utf.c

Changeset: 7913855ff66c
Author:    psandoz
Date:      2013-09-20 11:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7913855ff66c

8024253: ThreadLocal random can use SecureRandom for the initial seed
Reviewed-by: psandoz, chegar, alanb
Contributed-by: Doug Lea 
, Peter Levart , Guy Steele ! src/share/classes/java/util/SplittableRandom.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java Changeset: 2552cd270350 Author: bpb Date: 2013-09-20 15:12 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2552cd270350 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent Summary: Explicitly check for null remappingFunction parameter. Reviewed-by: mduigou, forax, psandoz Contributed-by: Brian Burkhalter ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! test/java/util/Map/Defaults.java Changeset: c30dc8e7744e Author: psandoz Date: 2013-09-20 17:11 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c30dc8e7744e 8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond to split() method if using an example from the spec Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java + test/java/util/regex/PatternStreamTest.java - test/java/util/regex/PatternTest.java Changeset: 56d247821694 Author: alanb Date: 2013-09-23 04:05 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/56d247821694 8023130: (process) ProcessBuilder#inheritIO does not work on Windows Reviewed-by: alanb, martin Contributed-by: ivan.gerasimov at oracle.com ! src/windows/native/java/lang/ProcessImpl_md.c ! test/java/lang/ProcessBuilder/Basic.java + test/java/lang/ProcessBuilder/InheritIO/InheritIO.java + test/java/lang/ProcessBuilder/InheritIO/InheritIO.sh Changeset: a3b17b91127d Author: lana Date: 2013-09-20 19:15 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a3b17b91127d Merge Changeset: f1b251affc6a Author: lana Date: 2013-09-22 20:21 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f1b251affc6a Merge Changeset: b606775fd1a3 Author: stefank Date: 2013-08-29 11:08 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b606775fd1a3 8014659: NPG: performance counters for compressed klass space Reviewed-by: jmasa, sla Contributed-by: erik.helin at oracle.com ! src/share/classes/sun/tools/jstat/resources/jstat_options ! test/sun/tools/jstat/gcCapacityOutput1.awk ! test/sun/tools/jstat/gcCauseOutput1.awk ! test/sun/tools/jstat/gcMetaCapacityOutput1.awk ! test/sun/tools/jstat/gcOldOutput1.awk ! test/sun/tools/jstat/gcOutput1.awk ! test/sun/tools/jstat/lineCounts1.awk ! test/sun/tools/jstat/lineCounts2.awk ! test/sun/tools/jstat/lineCounts3.awk ! test/sun/tools/jstat/lineCounts4.awk ! test/sun/tools/jstat/timeStamp1.awk ! test/sun/tools/jstatd/jstatGcutilOutput1.awk Changeset: 76619d71a7c5 Author: dfuchs Date: 2013-09-25 09:47 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/76619d71a7c5 8025140: TEST_BUG: java/util/logging/Logger/getGlobal tests fail due to timeout Summary: Arbitrary timeouts in the tests @run lines where too agressive for some configurations. The tests will now run with default timeout. Reviewed-by: alanb, mchung ! test/java/util/logging/Logger/getGlobal/TestGetGlobal.java ! test/java/util/logging/Logger/getGlobal/TestGetGlobalByName.java ! test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java Changeset: 2b928330970a Author: mfang Date: 2013-09-24 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2b928330970a 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: naoto, yhuang ! src/macosx/classes/com/apple/laf/resources/aqua_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties + src/share/classes/com/sun/java/util/jar/pack/DriverResource_ja.java + src/share/classes/com/sun/java/util/jar/pack/DriverResource_zh_CN.java ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/share/classes/sun/security/tools/keytool/Resources_de.java ! src/share/classes/sun/security/tools/keytool/Resources_es.java ! src/share/classes/sun/security/tools/keytool/Resources_fr.java ! src/share/classes/sun/security/tools/keytool/Resources_it.java ! src/share/classes/sun/security/tools/keytool/Resources_ja.java ! src/share/classes/sun/security/tools/keytool/Resources_ko.java ! src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/keytool/Resources_sv.java ! src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java ! src/share/classes/sun/security/tools/policytool/Resources_de.java ! src/share/classes/sun/security/tools/policytool/Resources_es.java ! src/share/classes/sun/security/tools/policytool/Resources_fr.java ! src/share/classes/sun/security/tools/policytool/Resources_it.java ! src/share/classes/sun/security/tools/policytool/Resources_ja.java ! src/share/classes/sun/security/tools/policytool/Resources_ko.java ! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/policytool/Resources_sv.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties Changeset: 9765801f209f Author: mfang Date: 2013-09-24 14:34 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9765801f209f Merge - test/java/util/regex/PatternTest.java Changeset: d16a53d1762f Author: mfang Date: 2013-09-25 07:36 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d16a53d1762f Merge Changeset: 8f27030686a6 Author: bchristi Date: 2013-09-26 11:13 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8f27030686a6 8025173: HashMap.put() replacing an existing key can trigger a resize() Summary: Ensure that HashMap is not resized if we're just replacing a value Reviewed-by: alanb, martin ! src/share/classes/java/util/HashMap.java + test/java/util/HashMap/ReplaceExisting.java Changeset: 8edd604bf960 Author: lana Date: 2013-09-26 17:21 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8edd604bf960 Merge - test/java/util/regex/PatternTest.java Changeset: 9684ed81cd21 Author: ksrini Date: 2013-09-27 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9684ed81cd21 8020552: [launcher] changes to support removal of Solaris 32-bit distribution 8023495: [infra] create 64-bit solaris bits with symlinks Reviewed-by: ihse, tbell, dholmes, darcy, alanb, erikj, sla, martin ! makefiles/Images.gmk ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/solaris/bin/java_md_solinux.c ! test/com/sun/jdi/BadHandshakeTest.java ! test/com/sun/jdi/DoubleAgentTest.java ! test/com/sun/jdi/ExclusiveBind.java ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/RunToExit.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh ! test/com/sun/jdi/connect/spi/SimpleLaunchingConnector.java ! test/demo/jvmti/DemoRun.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Makefile + test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/tools/jhat/HatRun.java ! test/tools/launcher/6842838/Test6842838.sh ! test/tools/launcher/ChangeDataModel.java ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/FXLauncherTest.java ! test/tools/launcher/RunpathTest.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java Changeset: 2c7c7b813eb3 Author: katleman Date: 2013-10-01 12:45 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2c7c7b813eb3 Merge - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so Changeset: dd43ccb3bac9 Author: ihse Date: 2013-10-01 11:08 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dd43ccb3bac9 8019219: Fix typo in jdk/makefiles "default" targets Reviewed-by: erikj ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 54e099776f08 Author: erikj Date: 2013-10-02 15:08 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/54e099776f08 Merge Changeset: 9f57d2774603 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9f57d2774603 Added tag jdk8-b110 for changeset 54e099776f08 ! .hgtags Changeset: 88597d465e48 Author: ihse Date: 2013-10-01 15:13 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/88597d465e48 8016024: Remove solaris path from FillCacheFind Reviewed-by: erikj ! makefiles/Tools.gmk Changeset: 760af86b3f3f Author: erikj Date: 2013-10-03 11:27 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/760af86b3f3f 8024522: java.time packages missing from src.zip Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: 719befd87c7b Author: katleman Date: 2013-10-08 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/719befd87c7b Merge Changeset: 7af04d2d2139 Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7af04d2d2139 Added tag jdk8-b111 for changeset 719befd87c7b ! .hgtags Changeset: 8a041011b6e6 Author: jgodinez Date: 2013-09-27 13:04 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8a041011b6e6 6870661: Setting a custom PrintService on a PrinterJob leads to a PrinterException Reviewed-by: prr, jgodinez Contributed-by: patrick at reini.net ! src/windows/classes/sun/awt/windows/WPrinterJob.java + test/java/awt/print/PrinterJob/CustomPrintService/PrintDialog.java + test/java/awt/print/PrinterJob/CustomPrintService/PrintServiceStub.java + test/java/awt/print/PrinterJob/CustomPrintService/SetPrintServiceTest.java Changeset: 31b8d4931a09 Author: prr Date: 2013-09-27 13:06 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/31b8d4931a09 8020190: Fatal: Bug in native code: jfieldID must match object Reviewed-by: jgodinez, vadim ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/native/sun/font/freetypeScaler.c Changeset: 6ef33b4553a4 Author: vadim Date: 2013-09-30 12:50 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6ef33b4553a4 8001119: [fingbugs] Evaluate necessity to make some arrays package protected Reviewed-by: prr, bae + src/share/classes/com/sun/imageio/plugins/bmp/BMPCompressionTypes.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPConstants.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java ! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java Changeset: e2604b873b36 Author: prr Date: 2013-10-01 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e2604b873b36 8007386: On physical machine (video card is Intel Q45) the text is blank. Reviewed-by: prr, jchen ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 96ff585555f4 Author: vadim Date: 2013-10-02 10:06 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/96ff585555f4 8024343: Change different color with the "The XOR alternation color" combobox, the color of the image can not shown immediately. Reviewed-by: ceisserer, prr, bae ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java + test/sun/java2d/AcceleratedXORModeTest.java Changeset: 5f3d984d8207 Author: prr Date: 2013-10-02 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5f3d984d8207 8025837: Extraneous changes in the fix for 8007386 Reviewed-by: jgodinez, jchen ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: f53aeb3c7eed Author: prr Date: 2013-10-02 11:22 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f53aeb3c7eed 7179526: xrender : closed/sun/java2d/volatileImage/LineClipTest.java failed since jdk8b36 Reviewed-by: prr, jchen ! src/solaris/classes/sun/java2d/xr/GrowableRectArray.java ! src/solaris/classes/sun/java2d/xr/MaskTile.java ! src/solaris/classes/sun/java2d/xr/MaskTileManager.java + src/solaris/classes/sun/java2d/xr/XRDrawLine.java ! src/solaris/classes/sun/java2d/xr/XRRenderer.java + test/java/awt/Graphics/LineClipTest.java Changeset: a15cad0e12d3 Author: bae Date: 2013-10-03 11:28 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a15cad0e12d3 8022632: Reading a PNG file fails because of WBMPImageReaderSpi.canDecodeInput() Reviewed-by: prr, jgodinez ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java + test/javax/imageio/plugins/wbmp/StreamResetTest.java Changeset: 2f11a00279ec Author: jchen Date: 2013-10-03 13:16 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2f11a00279ec 8025280: [parfait] warnings from b107 for jdk.src.share.native.sun.java2d.loops: JNI exception pending, JNI critical region violation Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/loops/Blit.c ! src/share/native/sun/java2d/loops/BlitBg.c ! src/share/native/sun/java2d/loops/DrawPath.c ! src/share/native/sun/java2d/loops/DrawPolygons.c ! src/share/native/sun/java2d/loops/FillPath.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/MaskBlit.c ! src/share/native/sun/java2d/loops/MaskFill.c ! src/share/native/sun/java2d/loops/ScaledBlit.c ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: e88d39b110dd Author: jchen Date: 2013-10-03 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e88d39b110dd 8025480: [parfait] "JNI exception pending" warnings from b107 for jdk.src.share.native.sun.java2d Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/Disposer.c ! src/share/native/sun/java2d/SurfaceData.c Changeset: 3c1b13ad0677 Author: jchen Date: 2013-10-03 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3c1b13ad0677 8025309: [parfait] JNI-related warnings from b107 for jdk.src.share.native.sun.java2d.pipe Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/pipe/BufferedRenderPipe.c ! src/share/native/sun/java2d/pipe/Region.c ! src/share/native/sun/java2d/pipe/ShapeSpanIterator.c ! src/share/native/sun/java2d/pipe/SpanClipRenderer.c Changeset: d37594b689ce Author: jchen Date: 2013-10-03 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d37594b689ce 8025664: [parfait] warnings from b62 for jdk.src.share.native.sun.font Reviewed-by: prr, jgodinez ! src/share/native/sun/font/freetypeScaler.c Changeset: 0ed939dc4230 Author: jchen Date: 2013-10-03 13:49 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0ed939dc4230 8025294: [parfait] JNI-related warnings from b107 for jdk.src.solaris.native.sun.java2d.x11 Reviewed-by: prr, jgodinez ! src/solaris/native/sun/java2d/x11/X11Renderer.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/java2d/x11/XRBackendNative.c ! src/solaris/native/sun/java2d/x11/XRSurfaceData.c Changeset: 8fd757f31470 Author: jchen Date: 2013-10-04 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8fd757f31470 8025940: Windows build fails after the fix for 8025280 Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/loops/MaskBlit.c Changeset: 727b60f9c09c Author: lana Date: 2013-10-08 14:37 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/727b60f9c09c Merge Changeset: c1ef9ebac26a Author: lana Date: 2013-10-08 14:53 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c1ef9ebac26a Merge ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java Changeset: 78b4dc33e6e6 Author: twisti Date: 2013-09-26 18:20 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/78b4dc33e6e6 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName() Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MemberName.java Changeset: eb2c81533876 Author: weijun Date: 2013-09-27 15:25 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/eb2c81533876 8024861: Incomplete token triggers GSS-API NullPointerException Reviewed-by: mullan ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java + test/sun/security/jgss/spnego/MechTokenMissing.java Changeset: 95f609fcb639 Author: ehelin Date: 2013-09-26 16:23 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/95f609fcb639 8025502: Exclude tests due to JDK-8025427 Reviewed-by: ksrini ! test/ProblemList.txt Changeset: 914f8d4570df Author: mduigou Date: 2013-09-27 10:21 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/914f8d4570df 8025595: Remove alt-rt.jar, used by +AggressiveOps (jdk repo portion of JDK-8024826) Reviewed-by: alanb, chegar, dholmes, ksrini ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/Profiles.gmk ! makefiles/profile-includes.txt ! test/java/util/TreeMap/Clone.java Changeset: fbe6f5dbb24f Author: mduigou Date: 2013-09-27 13:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/fbe6f5dbb24f 8023339: Refined Collection.removeIf UOE conditions Reviewed-by: mduigou Contributed-by: paul.sandoz at oracle.com ! src/share/classes/java/util/Collection.java ! test/java/util/Collection/MOAT.java Changeset: 91222be67b27 Author: mduigou Date: 2013-09-27 13:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/91222be67b27 8023340: Clarify that unmodifiable List.replaceAll() may not throw UOE if there are no items to be replaced. Reviewed-by: psandoz, jjg ! src/share/classes/java/util/List.java Changeset: 754db1268be1 Author: dxu Date: 2013-09-27 17:09 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/754db1268be1 8025128: File.createTempFile fails if prefix is absolute path Summary: Use only the file name from the supplied prefix for backward compatibility Reviewed-by: alanb, chegar ! src/share/classes/java/io/File.java ! test/java/io/File/createTempFile/SpecialTempFile.java Changeset: d921ce805abe Author: mduigou Date: 2013-09-27 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d921ce805abe 8025610: Add explicit @throws NPE documentation to Optional constructor and Optional.of Reviewed-by: briangoetz, chegar, alanb ! src/share/classes/java/util/Optional.java Changeset: 0b535e920dd5 Author: lana Date: 2013-09-27 18:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0b535e920dd5 Merge Changeset: 15955d335cd0 Author: jfranck Date: 2013-09-30 11:18 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/15955d335cd0 8007072: Update Core Reflection for Type Annotations to match latest spec 8022324: j.l.Class.getAnnotatedInterfaces() for array type returns wrong value 8024915: j.l.r.Executable.getAnnotatedReceiverType() should return null for static methods Summary: Update javadoc and implementation of reflection for type annotations to match latest spec Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/AnnotatedArrayType.java ! src/share/classes/java/lang/reflect/AnnotatedParameterizedType.java ! src/share/classes/java/lang/reflect/AnnotatedType.java ! src/share/classes/java/lang/reflect/AnnotatedTypeVariable.java ! src/share/classes/java/lang/reflect/AnnotatedWildcardType.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java + test/java/lang/annotation/typeAnnotations/GetAnnotatedInterfaces.java + test/java/lang/annotation/typeAnnotations/GetAnnotatedReceiverType.java ! test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java Changeset: 89174cddaec8 Author: jfranck Date: 2013-09-30 12:19 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/89174cddaec8 8009719: core reflection should get type annotation data from the VM lazily Summary: Remove typeAnnotations field from Method, Constructor, and Field, update Executable and Field to fetch data on demand. Reviewed-by: darcy, erikj ! make/java/java/FILES_c.gmk ! make/java/java/mapfile-vers ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/reflect/Executable.c + src/share/native/java/lang/reflect/Field.c Changeset: cceaad499685 Author: sla Date: 2013-09-30 12:58 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/cceaad499685 8023492: jfr.jar gets loaded even though it's not used Reviewed-by: erikj, mgronlun ! make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java Changeset: ede1fd12e0da Author: allwin Date: 2013-09-30 14:28 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ede1fd12e0da 8012923: [parfait] File Descriptor Leak in jdk/src/windows/demo/jvmti/hprof/hprof_md.c Reviewed-by: chegar, sla, sspitsyn, mgronlun ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: d0de46a2cbd0 Author: ascarpino Date: 2013-09-19 11:59 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d0de46a2cbd0 7122707: Security Providers need to have their version numbers updated for JDK8 Reviewed-by: xuelei ! src/macosx/classes/apple/security/AppleProvider.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/com/sun/security/sasl/Provider.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java ! src/share/classes/sun/security/ec/SunEC.java ! src/share/classes/sun/security/jgss/SunProvider.java ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/VerificationProvider.java ! src/share/classes/sun/security/rsa/SunRsaSign.java ! src/share/classes/sun/security/smartcardio/SunPCSC.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java + test/java/security/Provider/ProviderVersionCheck.java Changeset: 2434e79fc41f Author: ascarpino Date: 2013-09-18 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2434e79fc41f 8004283: test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failing intermittently Reviewed-by: vinnie ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh Changeset: e4c897b33cb7 Author: ascarpino Date: 2013-09-02 09:52 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e4c897b33cb7 8009438: sun/security/pkcs11/Secmod tests failing on Ubuntu 12.04 Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/Secmod.java Changeset: b4c259743371 Author: naoto Date: 2013-09-30 16:15 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b4c259743371 8016110: Japanese char (MS932) 0x5C cannot be used as an argument when quoted Reviewed-by: ksrini, akhil ! src/windows/bin/cmdtoargs.c + test/tools/launcher/I18NArgTest.java Changeset: f8b3ab514564 Author: psandoz Date: 2013-10-01 12:19 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f8b3ab514564 8024408: Specifications for Collection/List/Set/SortedSet.spliterator() need to document if all the (subclass) instances are required to return SIZED spliterators Reviewed-by: alanb ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedSet.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java Changeset: bf52ea6bd9eb Author: aefimov Date: 2013-10-01 17:15 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bf52ea6bd9eb 8024707: TransformerException : item() return null with node list of length != 1 Reviewed-by: joehw, lancea + test/javax/xml/jaxp/parsers/8024707/TestFunc.java + test/javax/xml/jaxp/parsers/8024707/XSLT.java + test/javax/xml/jaxp/parsers/8024707/in.xml + test/javax/xml/jaxp/parsers/8024707/test.xsl Changeset: 8cfb2bddd95e Author: mduigou Date: 2013-09-30 15:50 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8cfb2bddd95e 7057785: Add note about optional support of recursive methods for self-referential Collection/Map Reviewed-by: scolebourne, darcy, mduigou Contributed-by: Stephen Colebourne ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Map.java Changeset: f2e2326f787b Author: mduigou Date: 2013-10-01 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f2e2326f787b 8025067: Unconditionally throw NPE if null op provided to Arrays.parallelPrefix Reviewed-by: henryjen, chegar, psandoz ! src/share/classes/java/util/Arrays.java ! test/java/util/Arrays/ParallelPrefix.java Changeset: c32ab940a183 Author: mduigou Date: 2013-10-01 10:37 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c32ab940a183 8025686: Update jdk repo netbeans projects to support NetBeans 7.4 for Java 8 support Reviewed-by: lancea, chegar ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent Changeset: 5a7bd9825c01 Author: vlivanov Date: 2013-09-23 19:51 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5a7bd9825c01 8001107: @Stable annotation for constant folding of lazily evaluated variables Reviewed-by: twisti, kvn, rbackman Contributed-by: john.r.rose at oracle.com, vladimir.x.ivanov at oracle.com ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java + src/share/classes/java/lang/invoke/Stable.java Changeset: 1ed675532589 Author: vlivanov Date: 2013-09-18 20:12 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1ed675532589 8024616: JSR292: lazily initialize core NamedFunctions used for bootstrapping Reviewed-by: jrose ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java Changeset: bf1118ab775b Author: emc Date: 2013-10-01 17:35 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bf1118ab775b 8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null Summary: Fixed issue with type annotation reflection framework that would cause getType of AnnotatedTypes to be null if no annotations were present. Reviewed-by: darcy, jfranck ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java + test/java/lang/reflect/Parameter/GetAnnotatedTypeTest.java Changeset: 84e7f6685319 Author: ksrini Date: 2013-10-01 15:40 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/84e7f6685319 8025342: NLS: unsupported translation format in jar/pack/DriverResource.java Reviewed-by: naoto, mfang ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/DriverResource.java Changeset: d90928a89af5 Author: drchase Date: 2013-09-27 13:32 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d90928a89af5 8022701: Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError Summary: Inserted code to convert specific exceptions, case-by-case, plus a test. Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + test/java/lang/invoke/8022701/BogoLoader.java + test/java/lang/invoke/8022701/InvokeSeveralWays.java + test/java/lang/invoke/8022701/Invoker.java + test/java/lang/invoke/8022701/MHIllegalAccess.java + test/java/lang/invoke/8022701/MethodSupplier.java Changeset: 3fca37c636be Author: xuelei Date: 2013-10-01 20:25 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3fca37c636be 8025123: SNI support in Kerberos cipher suites Reviewed-by: weijun, xuelei Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! test/sun/security/krb5/auto/SSL.java Changeset: 914c29c10bce Author: okutsu Date: 2013-10-02 15:31 +0900 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/914c29c10bce 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010 Reviewed-by: peytoia ! src/share/classes/java/util/GregorianCalendar.java + test/java/util/Calendar/Bug6902861.java Changeset: 368172cb6dc5 Author: coffeys Date: 2013-10-02 09:21 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/368172cb6dc5 8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl Reviewed-by: chegar ! src/windows/classes/java/net/PlainSocketImpl.java + test/java/net/PlainSocketImpl/CustomSocketImplFactory.java Changeset: 82e3150778e0 Author: okutsu Date: 2013-10-02 17:57 +0900 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/82e3150778e0 8022666: java.util.Calendar.set(int,int,int,int,int,int) documentation typo Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java Changeset: e1b04fd49204 Author: psandoz Date: 2013-10-01 18:20 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e1b04fd49204 8025535: Unsafe typecast in java.util.stream.SortedOps Reviewed-by: mduigou, chegar ! src/share/classes/java/util/stream/SortedOps.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java Changeset: 3bb89c509d59 Author: egahlin Date: 2013-10-01 17:48 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3bb89c509d59 6696975: JTop plugin fails if connected readonly to target JVM Reviewed-by: mchung, jbachorik, sla, sjiang ! src/share/demo/management/JTop/JTop.java Changeset: a6ac824b463d Author: wetmore Date: 2013-10-02 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a6ac824b463d 8025694: Rename getStrongSecureRandom based on feedback 8014838: getStrongSecureRandom() should require at least one implementation Reviewed-by: mullan, darcy ! src/share/classes/java/security/SecureRandom.java ! src/share/lib/security/java.security-windows ! test/sun/security/provider/SecureRandom/StrongSecureRandom.java Changeset: cb8946eda85b Author: emc Date: 2013-10-02 19:13 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/cb8946eda85b 8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions Summary: Fix behavior of parameter reflection API for malformed class files. Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java + src/share/classes/java/lang/reflect/MalformedParametersException.java ! src/share/classes/java/lang/reflect/Parameter.java + test/java/lang/reflect/Parameter/BadClassFiles.java Changeset: 811c35a6a58f Author: psandoz Date: 2013-10-02 16:34 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/811c35a6a58f 8025534: Unsafe typecast in java.util.stream.Streams.Nodes 8025538: Unsafe typecast in java.util.stream.SpinedBuffer 8025533: Unsafe typecast in java.util.stream.Streams.RangeIntSpliterator.splitPoint() 8025525: Unsafe typecast in java.util.stream.Node.OfPrimitive.asArray() Reviewed-by: chegar ! src/share/classes/java/util/stream/Node.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/SortedOps.java ! src/share/classes/java/util/stream/SpinedBuffer.java ! src/share/classes/java/util/stream/Streams.java Changeset: c55a7941050c Author: psandoz Date: 2013-10-03 10:59 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c55a7941050c 8025567: Mark relevant public stream tests as serialization hostile Reviewed-by: alanb ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java Changeset: 5d6dc0cba08f Author: dsamersoff Date: 2013-10-03 16:54 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5d6dc0cba08f 8009213: sun/management/jdp/JdpTest.sh fails with exit code 1 Summary: There's no guarantee that the java process has executed far enough to be found by jps when we try to obtain it's pid. Reviewed-by: sla ! test/sun/management/jdp/JdpTest.sh Changeset: 9c32a9490eac Author: kizune Date: 2013-10-03 17:40 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9c32a9490eac 8025738: locale related test fails on langtools mac 10.7 test host Reviewed-by: ksrini ! test/tools/launcher/DiacriticTest.java Changeset: 8d8b809dd294 Author: rfield Date: 2013-10-03 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8d8b809dd294 8010433: Remove lambda metafactory work-around to JDK-8005119 Summary: Restore invokespecial to lambda metafactory Reviewed-by: ksrini ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java Changeset: 1b3616c4a836 Author: rfield Date: 2013-10-03 11:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1b3616c4a836 8020849: jdk/lambda/vm/DefaultMethodsTest.java Summary: Bridge generation has been removed from the VM. Fix is to remove tests that no longer make sense. Reviewed-by: ksrini ! test/jdk/lambda/vm/DefaultMethodsTest.java Changeset: 01b8604e8268 Author: rriggs Date: 2013-08-22 10:01 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/01b8604e8268 8024896: Refactor java.time serialization tests into separate subpackage Summary: Move serialization tests to .serial subpackage Reviewed-by: sherman Contributed-by: paul.rank at oracle.com ! test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKPeriod.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java + test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDate.java + test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java + test/java/time/tck/java/time/serial/TCKDuration.java + test/java/time/tck/java/time/serial/TCKInstant.java + test/java/time/tck/java/time/serial/TCKLocalDate.java + test/java/time/tck/java/time/serial/TCKLocalDateTime.java + test/java/time/tck/java/time/serial/TCKLocalTime.java + test/java/time/tck/java/time/serial/TCKMonthDay.java + test/java/time/tck/java/time/serial/TCKOffsetDateTime.java + test/java/time/tck/java/time/serial/TCKOffsetTime.java + test/java/time/tck/java/time/serial/TCKPeriod.java + test/java/time/tck/java/time/serial/TCKYear.java + test/java/time/tck/java/time/serial/TCKYearMonth.java + test/java/time/tck/java/time/serial/TCKZoneId.java + test/java/time/tck/java/time/serial/TCKZoneOffset.java + test/java/time/tck/java/time/serial/TCKZonedDateTime.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java + test/java/time/tck/java/time/temporal/serial/TCKWeekFields.java ! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/TCKZoneRules.java + test/java/time/tck/java/time/zone/serial/TCKFixedZoneRules.java + test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransition.java + test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRule.java + test/java/time/tck/java/time/zone/serial/TCKZoneRules.java Changeset: e813b58bd6db Author: rriggs Date: 2013-10-03 15:16 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e813b58bd6db 8024427: Missing java.time.chrono serialization tests Summary: Add tests and cleanup existing serialization tests Reviewed-by: sherman ! src/share/classes/java/time/temporal/ValueRange.java ! test/java/time/tck/java/time/AbstractTCKTest.java ! test/java/time/tck/java/time/TCKClock_Fixed.java ! test/java/time/tck/java/time/TCKClock_Offset.java ! test/java/time/tck/java/time/TCKClock_System.java ! test/java/time/tck/java/time/TCKClock_Tick.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronology.java ! test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java < test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTimeSerialization.java < test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/serial/TCKChronoZonedDateTimeSerialization.java ! test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java + test/java/time/tck/java/time/chrono/serial/TCKCopticSerialization.java + test/java/time/tck/java/time/chrono/serial/TCKEraSerialization.java + test/java/time/tck/java/time/serial/TCKClockSerialization.java ! test/java/time/tck/java/time/serial/TCKDurationSerialization.java < test/java/time/tck/java/time/serial/TCKDuration.java ! test/java/time/tck/java/time/serial/TCKInstantSerialization.java < test/java/time/tck/java/time/serial/TCKInstant.java ! test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java < test/java/time/tck/java/time/serial/TCKLocalDate.java ! test/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKLocalDateTime.java ! test/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java < test/java/time/tck/java/time/serial/TCKLocalTime.java ! test/java/time/tck/java/time/serial/TCKMonthDaySerialization.java < test/java/time/tck/java/time/serial/TCKMonthDay.java ! test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKOffsetDateTime.java ! test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java < test/java/time/tck/java/time/serial/TCKOffsetTime.java ! test/java/time/tck/java/time/serial/TCKPeriodSerialization.java < test/java/time/tck/java/time/serial/TCKPeriod.java ! test/java/time/tck/java/time/serial/TCKYearMonthSerialization.java < test/java/time/tck/java/time/serial/TCKYearMonth.java ! test/java/time/tck/java/time/serial/TCKYearSerialization.java < test/java/time/tck/java/time/serial/TCKYear.java ! test/java/time/tck/java/time/serial/TCKZoneIdSerialization.java < test/java/time/tck/java/time/serial/TCKZoneId.java ! test/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java < test/java/time/tck/java/time/serial/TCKZoneOffset.java ! test/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKZonedDateTime.java ! test/java/time/tck/java/time/temporal/TCKJulianFields.java + test/java/time/tck/java/time/temporal/serial/TCKChronoFieldSerialization.java + test/java/time/tck/java/time/temporal/serial/TCKChronoUnitSerialization.java + test/java/time/tck/java/time/temporal/serial/TCKJulianFieldsSerialization.java + test/java/time/tck/java/time/temporal/serial/TCKValueRangeSerialization.java ! test/java/time/tck/java/time/temporal/serial/TCKWeekFieldsSerialization.java < test/java/time/tck/java/time/temporal/serial/TCKWeekFields.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/serial/TCKFixedZoneRulesSerialization.java < test/java/time/tck/java/time/zone/serial/TCKFixedZoneRules.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java < test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java < test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java < test/java/time/tck/java/time/zone/serial/TCKZoneRules.java ! test/java/time/test/java/time/AbstractTest.java ! test/java/time/test/java/time/TestDuration.java ! test/java/time/test/java/time/temporal/TestDateTimeValueRange.java Changeset: 77ba1e67707c Author: allwin Date: 2013-10-04 15:00 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/77ba1e67707c 8025829: Add java/lang/instrument/RetransformBigClass.sh to problemlist Reviewed-by: sla, jbachorik ! test/ProblemList.txt Changeset: b5aad88cbf12 Author: vinnie Date: 2013-10-04 16:05 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b5aad88cbf12 8008296: keytool utility doesn't support '-importpassword' command Reviewed-by: weijun ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/tools/keytool/Resources.java + test/sun/security/tools/keytool/StorePasswords.java + test/sun/security/tools/keytool/StorePasswordsByShell.sh Changeset: 1de0fac9b962 Author: rriggs Date: 2013-08-29 20:38 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1de0fac9b962 8023764: Optimize Period addition Summary: Optimise plus/minus for common cases Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/ZonedDateTime.java Changeset: 356df1b99976 Author: rriggs Date: 2013-08-30 11:43 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/356df1b99976 8023763: Rename ChronoDateImpl Summary: Rename ChronoDateImpl to ChronoLocalDateImpl Reviewed-by: sherman Contributed-by: scolebourne at joda.org - src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java + src/share/classes/java/time/chrono/ChronoLocalDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java Changeset: 5d73f7a2db51 Author: rriggs Date: 2013-09-04 15:18 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5d73f7a2db51 8023762: Add ChronoPeriod interface and bind period to Chronology Summary: Make Period ISO-only, adding a Chronology-specific period concept Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java + src/share/classes/java/time/chrono/ChronoPeriod.java + src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/Ser.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/temporal/Temporal.java ! test/java/time/tck/java/time/TCKPeriod.java + test/java/time/tck/java/time/chrono/TCKChronoPeriod.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java Changeset: 79077f1641cc Author: rriggs Date: 2013-09-14 22:46 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/79077f1641cc 8024835: Change until() to accept any compatible temporal Summary: Method until(Temporal,TemporalUnit) now uses from() to convert; Enhance from() methods where necessary Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/temporal/TCKIsoFields.java Changeset: 14a187dc4ffe Author: rriggs Date: 2013-10-04 12:01 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/14a187dc4ffe 8024999: Instant.Parse typo in example Summary: javadoc only fix to correct example to use "." and "Z" Reviewed-by: sherman ! src/share/classes/java/time/Instant.java Changeset: f9c701ba04e7 Author: rriggs Date: 2013-09-14 22:50 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f9c701ba04e7 8024807: Add getChronlogy() to CLDT/CZDT Summary: Alternative to method is clunky and hard to find Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java Changeset: e12b912ab98e Author: rriggs Date: 2013-09-14 22:54 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e12b912ab98e 8024834: Better return type for TemporalField resolve Summary: Allow resolve method to return more than just ChronoLocalDate Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/TemporalField.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java Changeset: 7736abdf0805 Author: rfield Date: 2013-10-04 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7736abdf0805 8021186: jdk/lambda/vm/DefaultMethodsTest.java fails Summary: remove DefaultMethodsTest from jdk/test/problemList.txt Reviewed-by: mduigou ! test/ProblemList.txt Changeset: 66181f7991bd Author: bpatel Date: 2013-10-04 15:25 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/66181f7991bd 8025741: Fix jdk/make/docs/Makefile to point to correct docs URL for JDK 8. Reviewed-by: tbell ! make/docs/Makefile Changeset: 7d2112abbb1d Author: coffeys Date: 2013-10-04 16:27 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7d2112abbb1d 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash Reviewed-by: mkos, chegar + test/javax/xml/ws/clientjar/TestService.java + test/javax/xml/ws/clientjar/TestWsImport.java Changeset: 44da760eed4b Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/44da760eed4b 8024761: JSR 292 improve performance of generic invocation Summary: use a per-MH one element cache for MH.asType to speed up MH.invoke; also cache enough MH constants to cache LMF.metafactory Reviewed-by: twisti ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java - src/share/classes/java/lang/invoke/InvokeGeneric.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java Changeset: 97d5cc1e7586 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/97d5cc1e7586 8001105: findVirtual of Object[].clone produces internal error Summary: Replicate JVM logic for access control that makes Object.clone appear public when applied to an array type. Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 91535ade7349 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/91535ade7349 8019417: JSR 292 javadoc should clarify method handle arity limits Summary: clarification of erroneous reading of spec. that led to 7194534 Reviewed-by: twisti, darcy ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/BigArityTest.java Changeset: d391e062b983 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d391e062b983 8001109: arity mismatch on a call to spreader method handle should elicit IllegalArgumentException Summary: Document error conditions that may occur when calling a "spreader" method handle. Use IAE in all cases. Reviewed-by: twisti, vlivanov ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/JavaDocExamplesTest.java Changeset: acdf5bf1a918 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/acdf5bf1a918 8001108: an attempt to use "" as a method name should elicit NoSuchMethodException Summary: add an explicit check for leading "<", upgrade the unit tests Reviewed-by: twisti, darcy ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: df6236da299d Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/df6236da299d 8024599: JSR 292 direct method handles need to respect initialization rules for static members Summary: Align MH semantic with bytecode behavior of constructor and static member accesses, regarding invocation. Reviewed-by: twisti, darcy, abuckley, vlivanov ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/CallStaticInitOrder.java Changeset: eb3cfc69c16e Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/eb3cfc69c16e 8001110: method handles should have a collectArguments transform, generalizing asCollector Summary: promote an existing private method; make unit tests on all argument positions to arity 10 with mixed types Reviewed-by: twisti, vlivanov ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: b670477bff8f Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b670477bff8f 8025112: JSR 292 spec updates for security manager and caller sensitivity Summary: align CONSTANT_MethodHandle and Lookup.find* API calls, clarify security manager & @CallerSensitive interactions Reviewed-by: mchung, twisti ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/TestPrivateMember.java Changeset: 6623c675e734 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6623c675e734 8024438: JSR 292 API specification maintenance for JDK 8 Summary: add wildcard to unreflectConstructor, various clarifications and minor edits Reviewed-by: mchung, darcy, twisti ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/sun/invoke/WrapperInstance.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/RevealDirectTest.java Changeset: 0ac9dc315071 Author: alanb Date: 2013-10-07 11:48 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0ac9dc315071 8025983: Typo in Javadoc of Files.isRegularFile() Reviewed-by: mchung, chegar ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java Changeset: f0ad3e2918b4 Author: henryjen Date: 2013-10-07 11:25 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f0ad3e2918b4 8025968: Integrate test improvements made in lambda repo Reviewed-by: psandoz ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java Changeset: 0cffe1dab0bf Author: henryjen Date: 2013-10-07 15:18 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0cffe1dab0bf 8026009: Changes for 8025968 break all stream tests Reviewed-by: mduigou ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java Changeset: 0d5f4f1782e8 Author: xuelei Date: 2013-10-07 18:46 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0d5f4f1782e8 6956398: make ephemeral DH key match the length of the certificate key Reviewed-by: weijun ! src/share/classes/sun/security/ssl/ServerHandshaker.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java Changeset: b90dcd1a71bf Author: psandoz Date: 2013-10-08 11:17 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b90dcd1a71bf 8025136: SplittableRandom enchancements Reviewed-by: psandoz, martin Contributed-by: Doug Lea
, Guy Steele ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/SplittableRandom.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java Changeset: 95bb56c61276 Author: alanb Date: 2013-10-08 10:49 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/95bb56c61276 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers Reviewed-by: chegar ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java Changeset: 748207aa9620 Author: lana Date: 2013-10-08 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/748207aa9620 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: 575d4bc3bcae Author: lana Date: 2013-10-11 03:06 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/575d4bc3bcae Merge ! makefiles/CreateJars.gmk - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: f65895a2959e Author: lana Date: 2013-10-11 14:19 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f65895a2959e Merge - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java - test/java/util/regex/PatternTest.java From lana.steuck at oracle.com Fri Oct 11 16:48:42 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 23:48:42 +0000 Subject: hg: jdk8/awt/langtools: 64 new changesets Message-ID: <20131011235355.CBFBC62FB7@hg.openjdk.java.net> Changeset: 8ecfe6a3ba4c Author: cl Date: 2013-09-19 09:37 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/8ecfe6a3ba4c Added tag jdk8-b108 for changeset 252f872b8a2f ! .hgtags Changeset: 985abf1cd327 Author: tbell Date: 2013-09-25 12:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/985abf1cd327 8025411: JPRT to switch to the new Win platforms for JDK8 builds this week Reviewed-by: ksrini, katleman ! make/jprt.properties Changeset: 6f11dc295641 Author: cl Date: 2013-09-26 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/6f11dc295641 Added tag jdk8-b109 for changeset 985abf1cd327 ! .hgtags Changeset: fdfbc5f0c4ed Author: jjg Date: 2013-09-17 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/fdfbc5f0c4ed 8024538: -Xdoclint + -Xprefer:source + incremental compilation == FAIL Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java + test/tools/javac/doclint/implicitSource/ImplicitSourceTest.java + test/tools/javac/doclint/implicitSource/Other.java Changeset: ac6ec071c2b2 Author: alundblad Date: 2013-09-18 14:39 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/ac6ec071c2b2 8024127: javac, Code_attribute.exception_table_langth should be Code_attribute.exception_table_length Summary: exception_table_langth renamed to exception_table_length Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! test/tools/javac/T7093325.java ! test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java ! test/tools/javac/multicatch/Pos05.java Changeset: a2a5ad0853ed Author: bpatel Date: 2013-09-18 17:13 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/a2a5ad0853ed 8015249: javadoc fails to document static final fields in annotation types Reviewed-by: jjg + src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeFieldWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeFieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java + test/com/sun/javadoc/testAnnotationTypes/pkg/AnnotationTypeField.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java Changeset: 8df12c315ea3 Author: bpatel Date: 2013-09-18 22:47 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/8df12c315ea3 8024096: some javadoc tests may contain false positive results Reviewed-by: jjg ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testDocFileDir/TestDocFileDir.java ! test/com/sun/javadoc/testEncoding/EncodeTest.java ! test/com/sun/javadoc/testEncoding/TestEncoding.java ! test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java Changeset: 36e342dd57e2 Author: kizune Date: 2013-09-19 17:05 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/36e342dd57e2 8017248: Compiler Diacritics Issue Reviewed-by: naoto ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java Changeset: 8d1c48de706d Author: jlahoda Date: 2013-09-19 17:05 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/8d1c48de706d 8022567: Javac Should Generate Warnings For Raw Array Type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/warnings/6747671/T6747671.java ! test/tools/javac/warnings/6747671/T6747671.out Changeset: 0cfd5baa7154 Author: ohrstrom Date: 2013-09-19 08:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/0cfd5baa7154 8024609: sjavac assertion fails during call to BuildState.collectArtifacts Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/BuildState.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java Changeset: 2375ce96e80d Author: vromero Date: 2013-09-19 20:57 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/2375ce96e80d 8024437: Inferring the exception thrown: sometimes fails to compile Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/T8024437/ExceptionInferenceFromClassFileTest.java Changeset: 9a75bdb249a2 Author: jjg Date: 2013-09-19 19:18 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/9a75bdb249a2 8025110: TreeCopier does not correctly copy LabeledStatementTree Reviewed-by: jjg Contributed-by: Werner Dietl ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java Changeset: 41599b57d262 Author: jlahoda Date: 2013-09-20 16:33 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/41599b57d262 8023835: TreeMaker.QualIdent() too leafy Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/tree/MakeQualIdent.java + test/tools/javac/tree/ScopeTest.java Changeset: 571f8ebc2d51 Author: vromero Date: 2013-09-22 12:53 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/571f8ebc2d51 8024696: Missing null check in bound method reference capture Reviewed-by: jjg, briangoetz ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! test/tools/javac/lambda/8023558/T8023558a.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceNullCheckTest.java Changeset: 86dd72166267 Author: lana Date: 2013-09-20 19:16 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/86dd72166267 Merge Changeset: 20b72bae83d7 Author: lana Date: 2013-09-22 20:20 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/20b72bae83d7 Merge Changeset: 1fe358ea75ff Author: alundblad Date: 2013-09-23 10:10 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/1fe358ea75ff 8024988: javac, LVT test harness should generate tests .class files in the scratch folder Summary: Set the CLASS_OUTPUT location to the scratch directory. Changed the argument to checkClassFile accordingly. Reviewed-by: jjg, vromero ! test/tools/javac/flow/LVTHarness.java Changeset: 5f915a0c9615 Author: alundblad Date: 2013-09-23 10:42 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/5f915a0c9615 6386236: Please rename com.sun.tools.javac.util.ListBuffer.lb() Summary: Static factory method ListBuffer.lb removed. Replaced by constructor calls. Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/util/GraphUtils.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java ! test/tools/javac/scope/7017664/CompoundScopeTest.java ! test/tools/javac/types/TypeHarness.java Changeset: 809a50f24d6f Author: kizune Date: 2013-09-23 17:27 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/809a50f24d6f 7154966: CRs found to be in Fixed state with no test and no noreg- keyword. Reviewed-by: ksrini + test/tools/javac/T7090499.java + test/tools/javac/T7090499.out + test/tools/javac/T7120463.java + test/tools/javac/T7120463.out + test/tools/javac/T7126754.java Changeset: 64e79d38bd07 Author: kizune Date: 2013-09-23 18:29 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/64e79d38bd07 4881267: improve diagnostic for "instanceof T" for type parameter T Reviewed-by: vromero, jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T4881267.java + test/tools/javac/T4881267.out Changeset: 09301757bb32 Author: emc Date: 2013-09-23 15:37 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/09301757bb32 6499673: Assertion check for TypeVariable.getUpperBound() fails. Summary: Fix TypeVariable.getUpperBound to return results as specified Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/cast/intersection/model/ModelChecker.java + test/tools/javac/processing/model/type/BoundsTest.java + test/tools/javac/processing/model/type/IntersectionPropertiesTest.java Changeset: 96dcb66e6b0a Author: jjg Date: 2013-09-24 10:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/96dcb66e6b0a 8025050: Doclint doesn't recognize tag Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! test/tools/doclint/html/InlineTagsTest.java Changeset: 503338f16d2b Author: jjg Date: 2013-09-24 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/503338f16d2b 8025246: [doclint] doclint is showing error on anchor already defined when it's not Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/anchorTests/p/Test.java + test/tools/doclint/anchorTests/p/Test.javac.out + test/tools/doclint/anchorTests/p/Test.out + test/tools/doclint/anchorTests/p/package-info.java + test/tools/doclint/anchorTests/p/package-info.javac.out + test/tools/doclint/anchorTests/p/package-info.out Changeset: 6a05a713450d Author: jjg Date: 2013-09-24 11:46 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/6a05a713450d 8025272: doclint needs to check for valid usage of @value tag Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/ValueTest.java + test/tools/doclint/ValueTest.out Changeset: 3ae62331a56f Author: jjg Date: 2013-09-24 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/3ae62331a56f 8002154: [doclint] doclint should check for issues which are errors in javadoc Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! test/tools/doclint/ReferenceTest.java ! test/tools/doclint/ReferenceTest.out Changeset: 184c0d6698c3 Author: bpatel Date: 2013-09-24 16:12 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/184c0d6698c3 8016328: Regression : Javadoc i18n regression caused by fix for 8012375 Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testUseOption/TestUseOption.java Changeset: 5043e7056be8 Author: jjg Date: 2013-09-25 11:07 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/5043e7056be8 8025407: TypeAnnotations does not use Context Reviewed-by: jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java Changeset: 1332a99572c5 Author: mfang Date: 2013-09-24 14:20 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/1332a99572c5 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties ! src/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties ! src/share/classes/com/sun/tools/javap/resources/javap_ja.properties ! src/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties Changeset: daa3bfb82e58 Author: mfang Date: 2013-09-24 14:35 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/daa3bfb82e58 Merge Changeset: 6b702ace3e45 Author: mfang Date: 2013-09-25 07:36 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/6b702ace3e45 Merge Changeset: 68292726000e Author: mfang Date: 2013-09-25 14:02 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/68292726000e Merge Changeset: 3d61984b077c Author: jjg Date: 2013-09-25 14:04 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/3d61984b077c 8025412: Add legal header and comments to test/tools/doclint/tidy/util/Main.java Reviewed-by: bpatel ! test/tools/doclint/tidy/util/Main.java ! test/tools/doclint/tidy/util/tidy.sh Changeset: 9e884d3ddb0b Author: bpatel Date: 2013-09-25 22:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/9e884d3ddb0b 8004825: javadoc crash DocletAbortException Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java ! test/com/sun/javadoc/testValueTag/pkg1/Class1.java Changeset: 9235ae08a449 Author: jlahoda Date: 2013-09-26 20:07 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/9235ae08a449 8025491: Javac regression test tools/javac/T8003967/DetectMutableStaticFields.java failing Summary: Making HtmlTree.NONENCODING_CHARS final Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java Changeset: 13eba2e322e6 Author: vromero Date: 2013-09-26 19:06 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/13eba2e322e6 8025139: javac patch for using bootstrap compiler for debugging is not working properly Reviewed-by: jjg ! make/netbeans/langtools/build.xml ! make/tools/anttasks/SelectToolTask.java Changeset: 17653c4c22ec Author: sogoel Date: 2013-09-26 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/17653c4c22ec 8011738: Write test to check for bootstrap attributes for lambda expressions in class file Reviewed-by: mcimadamore + test/tools/javac/lambda/ByteCodeTest.java Changeset: 41541097533a Author: lana Date: 2013-09-26 17:23 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/41541097533a Merge Changeset: af6244ba81b6 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/af6244ba81b6 Added tag jdk8-b110 for changeset 41541097533a ! .hgtags Changeset: a0e8fd2464d6 Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/a0e8fd2464d6 Added tag jdk8-b111 for changeset af6244ba81b6 ! .hgtags Changeset: 16194509e483 Author: vromero Date: 2013-09-27 10:24 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/16194509e483 8024497: crash returning this-referencing lambda from default method Reviewed-by: jjg, rfield ! src/share/classes/com/sun/tools/javac/code/Symbol.java + test/tools/javac/lambda/8024497/CrashUsingReturningThisRefLambdaFromDefaultMetTest.java Changeset: b7d8b71e1658 Author: jlahoda Date: 2013-09-27 17:28 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/b7d8b71e1658 8022765: Compiler crashes with exception on wrong usage of an annotation. Summary: Error recovery for incorrect annotation attribute values - ensure the values are always attributed appropriately Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/annotations/neg/8022765/T8022765.java + test/tools/javac/annotations/neg/8022765/T8022765.out + test/tools/javac/annotations/neg/8022765/VerifyAnnotationsAttributed.java Changeset: 2c24a04ebfb4 Author: kizune Date: 2013-09-27 21:20 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/2c24a04ebfb4 6978886: javadoc shows stacktrace after print error resulting from disk full Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java Changeset: 699b86e82656 Author: sogoel Date: 2013-09-27 10:39 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/699b86e82656 8025537: Convert 2 javac/enumdeclarations tests in jtreg for regression ws Reviewed-by: jjg + test/tools/javac/enum/EnumAsIdentifier.java + test/tools/javac/enum/EnumAsIdentifier.out + test/tools/javac/enum/EnumAsIdentifier4.out + test/tools/javac/enum/EnumAsIdentifier5.out + test/tools/javac/enum/EnumMembersOrder.java + test/tools/javac/enum/EnumMembersOrder.out Changeset: 4ed8565fa536 Author: mduigou Date: 2013-09-27 11:34 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/4ed8565fa536 8024842: Define ABS_TEST_OUTPUT_DIR via TEST_OUTPUT_DIR Reviewed-by: ihse, erikj, vromero ! test/Makefile Changeset: dee28dd47e12 Author: rfield Date: 2013-09-27 13:06 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/dee28dd47e12 8025548: langtools test tools/javac/lambda/methodReference/BridgeMethod.java incorrectly assumes no other methods generated in lambda class Reviewed-by: vromero ! test/tools/javac/lambda/methodReference/BridgeMethod.java Changeset: 82044fe8c7f7 Author: ksrini Date: 2013-09-27 16:05 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/82044fe8c7f7 8015073: c.s.t.javac.api.JavacTool.getTask() - more informative exception Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! test/tools/javac/api/TestJavacTask.java Changeset: 34223fc58c1a Author: lana Date: 2013-09-27 18:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/34223fc58c1a Merge Changeset: 84161510f257 Author: emc Date: 2013-09-28 13:46 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/84161510f257 8025413: NPE in Type.java due to recent change Summary: isCompound throws a NPE for noType and other types. Made it return a reasonable result instead. Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java + test/tools/javac/processing/model/type/InheritedAP.java Changeset: 1a3e8347f3dd Author: kizune Date: 2013-10-01 17:03 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/1a3e8347f3dd 7118749: NPE in CreateSymbols caused by bad diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java Changeset: de1c5dbe6c28 Author: emc Date: 2013-10-01 17:41 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/de1c5dbe6c28 8021339: Compile-time error during casting array to intersection Summary: Add ability to have arrays in intersection types. Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/ArraysInIntersections.java + test/tools/javac/InferArraysInIntersections.java ! test/tools/javac/generics/typevars/6680106/T6680106.out Changeset: 1e6088da1740 Author: vromero Date: 2013-10-02 17:04 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/1e6088da1740 8023679: Improve error message for '_' used as a lambda parameter name Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/UnderscoreInLambdaExpression.java Changeset: c13305cf8528 Author: jlahoda Date: 2013-10-04 08:29 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/c13305cf8528 8025118: Annotation processing api returns default modifier for interface without default methods Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java + test/tools/javac/processing/model/element/TestTypeElement.java Changeset: c0d44b1e6b6a Author: kizune Date: 2013-10-04 19:38 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/c0d44b1e6b6a 7096170: should remove unused support for enabling javac logging Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 379c04c090cf Author: darcy Date: 2013-10-04 10:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/379c04c090cf 8025913: Rename jdk.Supported to jdk.Exported Reviewed-by: psandoz, forax, lancea, alanb, mchung, jjg ! src/share/classes/com/sun/source/doctree/AttributeTree.java ! src/share/classes/com/sun/source/doctree/AuthorTree.java ! src/share/classes/com/sun/source/doctree/BlockTagTree.java ! src/share/classes/com/sun/source/doctree/CommentTree.java ! src/share/classes/com/sun/source/doctree/DeprecatedTree.java ! src/share/classes/com/sun/source/doctree/DocCommentTree.java ! src/share/classes/com/sun/source/doctree/DocRootTree.java ! src/share/classes/com/sun/source/doctree/DocTree.java ! src/share/classes/com/sun/source/doctree/DocTreeVisitor.java ! src/share/classes/com/sun/source/doctree/EndElementTree.java ! src/share/classes/com/sun/source/doctree/EntityTree.java ! src/share/classes/com/sun/source/doctree/ErroneousTree.java ! src/share/classes/com/sun/source/doctree/IdentifierTree.java ! src/share/classes/com/sun/source/doctree/InheritDocTree.java ! src/share/classes/com/sun/source/doctree/InlineTagTree.java ! src/share/classes/com/sun/source/doctree/LinkTree.java ! src/share/classes/com/sun/source/doctree/LiteralTree.java ! src/share/classes/com/sun/source/doctree/ParamTree.java ! src/share/classes/com/sun/source/doctree/ReferenceTree.java ! src/share/classes/com/sun/source/doctree/ReturnTree.java ! src/share/classes/com/sun/source/doctree/SeeTree.java ! src/share/classes/com/sun/source/doctree/SerialDataTree.java ! src/share/classes/com/sun/source/doctree/SerialFieldTree.java ! src/share/classes/com/sun/source/doctree/SerialTree.java ! src/share/classes/com/sun/source/doctree/SinceTree.java ! src/share/classes/com/sun/source/doctree/StartElementTree.java ! src/share/classes/com/sun/source/doctree/TextTree.java ! src/share/classes/com/sun/source/doctree/ThrowsTree.java ! src/share/classes/com/sun/source/doctree/UnknownBlockTagTree.java ! src/share/classes/com/sun/source/doctree/UnknownInlineTagTree.java ! src/share/classes/com/sun/source/doctree/ValueTree.java ! src/share/classes/com/sun/source/doctree/VersionTree.java ! src/share/classes/com/sun/source/doctree/package-info.java ! src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/AnnotationTree.java ! src/share/classes/com/sun/source/tree/ArrayAccessTree.java ! src/share/classes/com/sun/source/tree/ArrayTypeTree.java ! src/share/classes/com/sun/source/tree/AssertTree.java ! src/share/classes/com/sun/source/tree/AssignmentTree.java ! src/share/classes/com/sun/source/tree/BinaryTree.java ! src/share/classes/com/sun/source/tree/BlockTree.java ! src/share/classes/com/sun/source/tree/BreakTree.java ! src/share/classes/com/sun/source/tree/CaseTree.java ! src/share/classes/com/sun/source/tree/CatchTree.java ! src/share/classes/com/sun/source/tree/ClassTree.java ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/CompoundAssignmentTree.java ! src/share/classes/com/sun/source/tree/ConditionalExpressionTree.java ! src/share/classes/com/sun/source/tree/ContinueTree.java ! src/share/classes/com/sun/source/tree/DoWhileLoopTree.java ! src/share/classes/com/sun/source/tree/EmptyStatementTree.java ! src/share/classes/com/sun/source/tree/EnhancedForLoopTree.java ! src/share/classes/com/sun/source/tree/ErroneousTree.java ! src/share/classes/com/sun/source/tree/ExpressionStatementTree.java ! src/share/classes/com/sun/source/tree/ExpressionTree.java ! src/share/classes/com/sun/source/tree/ForLoopTree.java ! src/share/classes/com/sun/source/tree/IdentifierTree.java ! src/share/classes/com/sun/source/tree/IfTree.java ! src/share/classes/com/sun/source/tree/ImportTree.java ! src/share/classes/com/sun/source/tree/InstanceOfTree.java ! src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/LabeledStatementTree.java ! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/LineMap.java ! src/share/classes/com/sun/source/tree/LiteralTree.java ! src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/MemberSelectTree.java ! src/share/classes/com/sun/source/tree/MethodInvocationTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/ModifiersTree.java ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/tree/NewClassTree.java ! src/share/classes/com/sun/source/tree/ParameterizedTypeTree.java ! src/share/classes/com/sun/source/tree/ParenthesizedTree.java ! src/share/classes/com/sun/source/tree/PrimitiveTypeTree.java ! src/share/classes/com/sun/source/tree/ReturnTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/tree/StatementTree.java ! src/share/classes/com/sun/source/tree/SwitchTree.java ! src/share/classes/com/sun/source/tree/SynchronizedTree.java ! src/share/classes/com/sun/source/tree/ThrowTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/tree/TypeCastTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/tree/UnaryTree.java ! src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/tree/WhileLoopTree.java ! src/share/classes/com/sun/source/tree/WildcardTree.java ! src/share/classes/com/sun/source/tree/package-info.java ! src/share/classes/com/sun/source/util/DocSourcePositions.java ! src/share/classes/com/sun/source/util/DocTreePath.java ! src/share/classes/com/sun/source/util/DocTreePathScanner.java ! src/share/classes/com/sun/source/util/DocTreeScanner.java ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/SourcePositions.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TaskListener.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/source/util/TreePathScanner.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/source/util/package-info.java ! src/share/classes/com/sun/tools/javac/Main.java + src/share/classes/jdk/Exported.java - src/share/classes/jdk/Supported.java Changeset: 6e186ca11ec0 Author: bpatel Date: 2013-10-04 13:32 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/6e186ca11ec0 8008164: Invisible table captions in javadoc-generated html Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css + test/com/sun/javadoc/testHtmlTableStyles/TestHtmlTableStyles.java + test/com/sun/javadoc/testHtmlTableStyles/pkg1/TestTable.java + test/com/sun/javadoc/testHtmlTableStyles/pkg2/TestUse.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: 3344ea7404b1 Author: bpatel Date: 2013-10-04 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/3344ea7404b1 8024756: method grouping tabs are not selectable Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/JavascriptWinTitle/JavascriptWinTitle.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java Changeset: 2fa6ced325cc Author: jjg Date: 2013-10-04 13:59 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/2fa6ced325cc 8022163: javac exits with 0 status and no messages on error to construct an ann-procesor Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/errors/TestBadProcessor.java Changeset: 515d54c1b063 Author: jjg Date: 2013-10-04 14:46 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/515d54c1b063 6525408: DiagnosticListener should receive MANDATORY_WARNING in standard compiler mode Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/javax/tools/Diagnostic.java Changeset: 3e3c321710be Author: jjg Date: 2013-10-04 15:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/3e3c321710be 8025970: Spurious characters in JavaCompiler Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: bb87db832b31 Author: ksrini Date: 2013-10-04 16:08 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/bb87db832b31 8003537: javap use internal class name when printing bound of type variable Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/ClassWriter.java + test/tools/javap/BoundsTypeVariableTest.java Changeset: 15651a673358 Author: ksrini Date: 2013-10-04 16:23 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/15651a673358 8005542: jtreg test OverrideBridge.java contains @ignore Reviewed-by: jjg Contributed-by: steve.sides at oracle.com - test/tools/javac/generics/OverrideBridge.java Changeset: 4dd7ffbf01fb Author: darcy Date: 2013-10-07 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/4dd7ffbf01fb 8026017: Make history of AnnotatedConstruct methods in jx.l.m.e.Element clearer Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/Element.java Changeset: 4dfcf3a6902f Author: lana Date: 2013-10-08 14:59 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/4dfcf3a6902f Merge - src/share/classes/jdk/Supported.java - test/tools/javac/generics/OverrideBridge.java Changeset: 2f43529df42f Author: lana Date: 2013-10-11 03:09 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/2f43529df42f Merge - src/share/classes/jdk/Supported.java - test/tools/javac/generics/OverrideBridge.java From weijun.wang at oracle.com Fri Oct 11 17:49:37 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 12 Oct 2013 08:49:37 +0800 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard Message-ID: <52589CA1.4080503@oracle.com> Hi All Please review the fix at http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ The fix includes porting PolicyTool from AWT to Swing, defining mnemonics for menu items and buttons, and adding keyboard shortcuts for the File -> New/Open/Save items. Several tests are updated also. Thanks Max From yuri.nesterenko at oracle.com Mon Oct 14 00:48:49 2013 From: yuri.nesterenko at oracle.com (yuri.nesterenko at oracle.com) Date: Mon, 14 Oct 2013 07:48:49 +0000 Subject: hg: jdk8/awt/jdk: 8025824: [cleanup] Fix tidy errors and warnings in preformatted HTML files related to 2d/awt/swing Message-ID: <20131014075013.6DA266235D@hg.openjdk.java.net> Changeset: d874963706dc Author: yan Date: 2013-10-14 11:47 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d874963706dc 8025824: [cleanup] Fix tidy errors and warnings in preformatted HTML files related to 2d/awt/swing Reviewed-by: anthony, alexsch ! src/macosx/classes/com/apple/eawt/event/package.html ! src/macosx/classes/com/apple/eawt/package.html ! src/share/classes/java/awt/color/package.html ! src/share/classes/java/awt/datatransfer/package.html ! src/share/classes/java/awt/dnd/package.html ! src/share/classes/java/awt/doc-files/AWTThreadIssues.html ! src/share/classes/java/awt/doc-files/DesktopProperties.html ! src/share/classes/java/awt/doc-files/FocusSpec.html ! src/share/classes/java/awt/doc-files/Modality.html ! src/share/classes/java/awt/event/package.html ! src/share/classes/java/awt/font/package.html ! src/share/classes/java/awt/geom/package.html ! src/share/classes/java/awt/image/package.html ! src/share/classes/java/awt/image/renderable/package.html ! src/share/classes/java/awt/package.html ! src/share/classes/java/awt/print/package.html ! src/share/classes/javax/print/attribute/package.html ! src/share/classes/javax/print/attribute/standard/package.html ! src/share/classes/javax/print/event/package.html ! src/share/classes/javax/print/package.html ! src/share/classes/javax/swing/border/package.html ! src/share/classes/javax/swing/colorchooser/package.html ! src/share/classes/javax/swing/event/package.html ! src/share/classes/javax/swing/filechooser/package.html ! src/share/classes/javax/swing/plaf/basic/package.html ! src/share/classes/javax/swing/plaf/metal/package.html ! src/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html ! src/share/classes/javax/swing/plaf/multi/package.html ! src/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html ! src/share/classes/javax/swing/plaf/nimbus/package.html ! src/share/classes/javax/swing/plaf/package.html ! src/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html ! src/share/classes/javax/swing/plaf/synth/package.html ! src/share/classes/javax/swing/table/package.html ! src/share/classes/javax/swing/text/html/package.html ! src/share/classes/javax/swing/text/html/parser/package.html ! src/share/classes/javax/swing/text/package.html ! src/share/classes/javax/swing/text/rtf/package.html ! src/share/classes/javax/swing/tree/package.html ! src/share/classes/javax/swing/undo/package.html From sergey.malenkov at oracle.com Mon Oct 14 02:27:57 2013 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Mon, 14 Oct 2013 09:27:57 +0000 Subject: hg: jdk8/awt/jdk: 7165112: Incomprehensible garbage in doc for RootPaneContainer Message-ID: <20131014093056.4F52362362@hg.openjdk.java.net> Changeset: 69a17384fe22 Author: malenkov Date: 2013-10-14 13:22 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/69a17384fe22 7165112: Incomprehensible garbage in doc for RootPaneContainer Reviewed-by: alexsch ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/RootPaneContainer.java From sergey.malenkov at oracle.com Mon Oct 14 03:01:50 2013 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Mon, 14 Oct 2013 10:01:50 +0000 Subject: hg: jdk8/awt/jdk: 7016396: (spec) JCK test mentioned in 6735293 is still failing Message-ID: <20131014100303.121AF6236D@hg.openjdk.java.net> Changeset: 9f49b055e983 Author: malenkov Date: 2013-10-14 13:59 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9f49b055e983 7016396: (spec) JCK test mentioned in 6735293 is still failing Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/CompositeView.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/View.java From sergey.malenkov at oracle.com Mon Oct 14 03:15:58 2013 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Mon, 14 Oct 2013 10:15:58 +0000 Subject: hg: jdk8/awt/jdk: 7035495: javax.swing.ImageIcon spec should be clarified Message-ID: <20131014101618.C90AC6236E@hg.openjdk.java.net> Changeset: 54a6e22b749c Author: malenkov Date: 2013-10-14 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/54a6e22b749c 7035495: javax.swing.ImageIcon spec should be clarified Reviewed-by: alexsch ! src/share/classes/javax/swing/ImageIcon.java From artem.ananiev at oracle.com Mon Oct 14 06:45:27 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 14 Oct 2013 17:45:27 +0400 Subject: [8] Review request for 8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: <52581E15.20108@oracle.com> References: <52581E15.20108@oracle.com> Message-ID: <525BF577.80101@oracle.com> Hi, Anton, thanks for details description of the bug and suggested fix. It helped a lot. My understanding is that the problem is not with step 2, but step 3. Generating "drag entered" events on mouse press looks incompatible, I can't predict side effects of such a change. Fixing step 3, so we don't assume drag entered events already sent, looks more correct. What do you think? Thanks, Artem On 10/11/2013 7:49 PM, anton nashatyrev wrote: > Hello, > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~mcherkas/anton/8024061/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8024061 > > Problem: when doing quick drag'n'drop in X11 the incorrect > behavior appears in the different forms. One is the exception when > trying to get 'local Jvm' Transferable from DropTargetListener. > > Reason: on quick drag the following sequence of events may appear: > (1) mouse pressed on source -> (2) mouse moved to target in a single > X11 event -> (3) mouse released. What's happening in that case: on event > (2) only a drag gesture is recognized and no drag enter is generated > yet. On event (3) the XDragSourceContextPeer assumes that entered event > (if it happened) was already generated and the 'local JVM' transferable > had been already captured by SunDropTargetContextPeer from the static > field currentJVMLocalSourceTransferable. Thus on event (3) the > XDragSourceContextPeer posts the additional mouseMove event (which turns > into DragEnter later) and initiates the cleanup which then resets the > currentJVMLocalSourceTransferable to null. Thus on DragEnter the > currentJVMLocalSourceTransferable is already null and the > SunDropTargetContextPeer appears in the inconsistent state. > > Solution: the event (2) from the example above should not only > initiate the DnD operation but also be a part of that operation, i.e. > this event should also appear as a drag motion. For that I propose to > keep a track of the XMotionEvents in the XDragSourceContextPeer to catch > the mouse event which initiated the DnD and when a startDrag() is called > process this event as the first drag motion event. > > Thanks! > Anton. From anthony.petrov at oracle.com Mon Oct 14 10:50:37 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 14 Oct 2013 17:50:37 +0000 Subject: [8] Review Request: 8019591 JCK: testICSEthrowing_fullScreen fails: no ICSE thrown In-Reply-To: <525806E4.2010607@oracle.com> References: <525806E4.2010607@oracle.com> Message-ID: <525C2EED.3090900@oracle.com> Hi Sergey, The fix looks good to me. -- best regards, Anthony On 10/11/2013 02:10 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 8. The problem is in inconsistent state of > the GraphicsDevice, Window and Peer. > We update GraphicsDevice synchronously in setFullScreenWindow(), we > update peer's coordinate a little bit later in the native call back, and > we update state of the window much later on EDT. > In the fix I try to update GraphicsDevice and Window.gc, so they points > to each other. > All attempts to do the same things synchronously from the native > callback deadlocked. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8019591 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8019591/webrev.00 > From artem.ananiev at oracle.com Mon Oct 14 06:57:54 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 14 Oct 2013 17:57:54 +0400 Subject: [8] Review Request: 8019591 JCK: testICSEthrowing_fullScreen fails: no ICSE thrown In-Reply-To: <525806E4.2010607@oracle.com> References: <525806E4.2010607@oracle.com> Message-ID: <525BF862.2050803@oracle.com> Hi, Sergey, the fix looks acceptable (I can't say "fine", because I can't predict side effects). That's why could you also add the following information to bug comments: 1. Current fix 2. Alternative fix, when we asynchronously update GD's full screen window Thanks, Artem On 10/11/2013 6:10 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 8. The problem is in inconsistent state of > the GraphicsDevice, Window and Peer. > We update GraphicsDevice synchronously in setFullScreenWindow(), we > update peer's coordinate a little bit later in the native call back, and > we update state of the window much later on EDT. > In the fix I try to update GraphicsDevice and Window.gc, so they points > to each other. > All attempts to do the same things synchronously from the native > callback deadlocked. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8019591 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8019591/webrev.00 > From alexandr.scherbatiy at oracle.com Mon Oct 14 07:20:03 2013 From: alexandr.scherbatiy at oracle.com (alexandr.scherbatiy at oracle.com) Date: Mon, 14 Oct 2013 14:20:03 +0000 Subject: hg: jdk8/awt/jdk: 8005391: Floating behavior of HTMLEditorKit parser Message-ID: <20131014142047.96E246237F@hg.openjdk.java.net> Changeset: 5e0ed469c36a Author: alexsch Date: 2013-10-14 18:19 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5e0ed469c36a 8005391: Floating behavior of HTMLEditorKit parser Reviewed-by: malenkov, leonidr Contributed-by: Alexander Shusherov ! src/share/classes/javax/swing/text/SimpleAttributeSet.java + test/javax/swing/text/html/8005391/bug8005391.java From anton.nashatyrev at oracle.com Mon Oct 14 07:26:54 2013 From: anton.nashatyrev at oracle.com (anton nashatyrev) Date: Mon, 14 Oct 2013 18:26:54 +0400 Subject: [8] Review request for 8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: <525BF577.80101@oracle.com> References: <52581E15.20108@oracle.com> <525BF577.80101@oracle.com> Message-ID: <525BFF2E.8040008@oracle.com> Hi Artem, with the fix the 'drag entered' event is actually generated on the mouse move event (step 2). Currently this first move event is 'consumed' by the MouseGestureRecognizer and is not treated as the part of a drag operation, while this move could be important (as in our case). During the process I've created a couple of fixes which tried to address the step 3, but all of them seemed to me rather like hacks than fixes. BTW, I've run the regression DnD tests (from test/closed/java/awt/dnd + test/java/awt/dnd, totally about 75 tests) - all went fine. Thanks! Anton. On 14.10.2013 17:45, Artem Ananiev wrote: > Hi, Anton, > > thanks for details description of the bug and suggested fix. It helped > a lot. > > My understanding is that the problem is not with step 2, but step 3. > Generating "drag entered" events on mouse press looks incompatible, I > can't predict side effects of such a change. Fixing step 3, so we > don't assume drag entered events already sent, looks more correct. > What do you think? > > Thanks, > > Artem > > On 10/11/2013 7:49 PM, anton nashatyrev wrote: >> Hello, >> could you please review the following fix: >> >> fix: http://cr.openjdk.java.net/~mcherkas/anton/8024061/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8024061 >> >> Problem: when doing quick drag'n'drop in X11 the incorrect >> behavior appears in the different forms. One is the exception when >> trying to get 'local Jvm' Transferable from DropTargetListener. >> >> Reason: on quick drag the following sequence of events may appear: >> (1) mouse pressed on source -> (2) mouse moved to target in a single >> X11 event -> (3) mouse released. What's happening in that case: on event >> (2) only a drag gesture is recognized and no drag enter is generated >> yet. On event (3) the XDragSourceContextPeer assumes that entered event >> (if it happened) was already generated and the 'local JVM' transferable >> had been already captured by SunDropTargetContextPeer from the static >> field currentJVMLocalSourceTransferable. Thus on event (3) the >> XDragSourceContextPeer posts the additional mouseMove event (which turns >> into DragEnter later) and initiates the cleanup which then resets the >> currentJVMLocalSourceTransferable to null. Thus on DragEnter the >> currentJVMLocalSourceTransferable is already null and the >> SunDropTargetContextPeer appears in the inconsistent state. >> >> Solution: the event (2) from the example above should not only >> initiate the DnD operation but also be a part of that operation, i.e. >> this event should also appear as a drag motion. For that I propose to >> keep a track of the XMotionEvents in the XDragSourceContextPeer to catch >> the mouse event which initiated the DnD and when a startDrag() is called >> process this event as the first drag motion event. >> >> Thanks! >> Anton. From alexandr.scherbatiy at oracle.com Mon Oct 14 07:56:46 2013 From: alexandr.scherbatiy at oracle.com (alexandr.scherbatiy at oracle.com) Date: Mon, 14 Oct 2013 14:56:46 +0000 Subject: hg: jdk8/awt/jdk: 8020708: NLS mnemonics missing in SwingSet2/JInternalFrame demo Message-ID: <20131014145727.2ADD862382@hg.openjdk.java.net> Changeset: 24fd0716d8d6 Author: alexsch Date: 2013-10-14 18:52 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/24fd0716d8d6 8020708: NLS mnemonics missing in SwingSet2/JInternalFrame demo Reviewed-by: malenkov, leonidr ! src/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java + test/javax/swing/JInternalFrame/8020708/bug8020708.java From sergey.bylokhov at oracle.com Mon Oct 14 09:13:52 2013 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Mon, 14 Oct 2013 16:13:52 +0000 Subject: hg: jdk8/awt/jdk: 8019591: JCK: testICSEthrowing_fullScreen fails: no ICSE thrown Message-ID: <20131014161413.9E80862384@hg.openjdk.java.net> Changeset: 9546631f14ca Author: serb Date: 2013-10-14 20:11 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9546631f14ca 8019591: JCK: testICSEthrowing_fullScreen fails: no ICSE thrown Reviewed-by: art, anthony ! src/share/classes/java/awt/GraphicsDevice.java + test/java/awt/Window/WindowGCInFullScreen/WindowGCInFullScreen.java From srikalyan.chandrashekar at oracle.com Mon Oct 14 13:46:14 2013 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Mon, 14 Oct 2013 13:46:14 -0700 Subject: [OpenJDK 2D-Dev] [8] Review request for JDK-8025684 - Fix Raw and unchecked warnings java.awt.image classes In-Reply-To: <524C9AA7.6010500@oracle.com> References: <524B43EF.4080603@oracle.com> <524BEF41.2000304@oracle.com> <524C9AA7.6010500@oracle.com> Message-ID: <525C5816.5010909@oracle.com> Hi Jim, Thanks for reviewing and apologies for the delayed response, I have made sure to set the properties type as String -> Object but mostly the public constructor(OR) setter method enforces where being too loose is guaranteed to not break at runtime but is brittle and may break at runtime . But as you said if it is documented then having this hole should be OK. I have updated the webrev and is available in same location . -- Thanks kalyan On 10/2/13 3:13 PM, Jim Graham wrote: > I'm not the greatest expert on generics (in particular, in terms of > issues of retrofitting generics into existing public code without > breaking compatibility), but I'll note that the properties on an image > were always "documented" to be String->Object, but that was well > before generics and so we just accepted bare hash tables everywhere. > Is it possible to have at least some of the declarations of various > properties objects to be declared as even though we > are loose on the acceptance criteria in various constructors - or > would that just completely break compatibility. I know that we use > type erasure so we would never break binary compatibility, but there > may be some places where we can have them more strongly typed > internally for now, but more accepting at the external API level and > then possibly consider improving the externally-visible typing in > future versions when a source incompatibility is more appropriate? > > (I'm asking because I don't understand all of the compatibility issues > that this might cause...) > > ...jim > > On 10/2/13 3:02 AM, Artem Ananiev wrote: >> >> java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to >> CC. Please, wait for at least one approval from Java2D team. >> >> For easier review, I put the webrev here: >> >> http://cr.openjdk.java.net/~art/srikalyc/8025684.00/ >> >> It looks fine to me. There is one "unchecked" warning still left, at >> BufferedImage.java:645, it can be fixed by introducing a local variable >> and @SuppressWarnings("unchecked"), but I'm not sure it's worth doing. >> >> Thanks, >> >> Artem >> >> On 10/2/2013 1:51 AM, srikalyan chandrashekar wrote: >>> Hi team , could someone review the fix >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8025684 >>> Webrev : >>> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.image.raw_unchecked_webrev.zip >>> >>> >>> >>> Fix : Raw and unchecked warnings in AWT image classes fixed >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131014/78c8bd65/attachment.html From james.graham at oracle.com Mon Oct 14 15:50:07 2013 From: james.graham at oracle.com (Jim Graham) Date: Mon, 14 Oct 2013 15:50:07 -0700 Subject: [OpenJDK 2D-Dev] [8] Review request for JDK-8025684 - Fix Raw and unchecked warnings java.awt.image classes In-Reply-To: <525C5816.5010909@oracle.com> References: <524B43EF.4080603@oracle.com> <524BEF41.2000304@oracle.com> <524C9AA7.6010500@oracle.com> <525C5816.5010909@oracle.com> Message-ID: <525C751F.8020504@oracle.com> Thanks Kalyan, I'll leave the review and approval to someone else because, as I said, I was asking an idle question from a limited understanding of the compatibility issues of generifying code, and a bit of historical perspective from the origin of the APIs... ...jim On 10/14/13 1:46 PM, srikalyan chandrashekar wrote: > Hi Jim, Thanks for reviewing and apologies for the delayed response, I > have made sure to set the properties type as String -> Object but mostly > the public constructor(OR) setter method enforces where Object> being too loose is guaranteed to not break at runtime but > is brittle and may break at runtime . But as you said > if it is documented then having this hole should be OK. I have updated > the webrev and is available in same location > . > > -- > Thanks > kalyan > > On 10/2/13 3:13 PM, Jim Graham wrote: >> I'm not the greatest expert on generics (in particular, in terms of >> issues of retrofitting generics into existing public code without >> breaking compatibility), but I'll note that the properties on an image >> were always "documented" to be String->Object, but that was well >> before generics and so we just accepted bare hash tables everywhere. >> Is it possible to have at least some of the declarations of various >> properties objects to be declared as even though we >> are loose on the acceptance criteria in various constructors - or >> would that just completely break compatibility. I know that we use >> type erasure so we would never break binary compatibility, but there >> may be some places where we can have them more strongly typed >> internally for now, but more accepting at the external API level and >> then possibly consider improving the externally-visible typing in >> future versions when a source incompatibility is more appropriate? >> >> (I'm asking because I don't understand all of the compatibility issues >> that this might cause...) >> >> ...jim >> >> On 10/2/13 3:02 AM, Artem Ananiev wrote: >>> >>> java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to >>> CC. Please, wait for at least one approval from Java2D team. >>> >>> For easier review, I put the webrev here: >>> >>> http://cr.openjdk.java.net/~art/srikalyc/8025684.00/ >>> >>> It looks fine to me. There is one "unchecked" warning still left, at >>> BufferedImage.java:645, it can be fixed by introducing a local variable >>> and @SuppressWarnings("unchecked"), but I'm not sure it's worth doing. >>> >>> Thanks, >>> >>> Artem >>> >>> On 10/2/2013 1:51 AM, srikalyan chandrashekar wrote: >>>> Hi team , could someone review the fix >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8025684 >>>> Webrev : >>>> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.image.raw_unchecked_webrev.zip >>>> >>>> >>>> >>>> Fix : Raw and unchecked warnings in AWT image classes fixed >>>> > From david.holmes at oracle.com Tue Oct 15 00:38:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Oct 2013 17:38:30 +1000 Subject: RFR: 8026404 - Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") In-Reply-To: <525C43B2.6000007@oracle.com> References: <525C43B2.6000007@oracle.com> Message-ID: <525CF0F6.9090904@oracle.com> On 15/10/2013 5:19 AM, Daniel Fuchs wrote: > Adding awt-dev... > >> The change looks okay to me but I would suggest sending to awt-dev so >> that the folks that maintain this area know about it. >> >> On the test then does initializing SunToolkit cause AWT to be >> initialized? I just wonder if this test will run headless. >> >> -Alan. > > > Hi, > > Please find below a fix for: > > 8026404: Logging in Applet can trigger ACE: > access denied ("java.lang.RuntimePermission" > "modifyThreadGroup") > > In some circumstances the call to JavaAWTAccess.getAppletContext() > will trigger a call to ecx.threadGroup.getParent() == null > The trouble is that this call will require a "modifyThreadGroup" > permission if it happens that ecx.threadGroup.getParent() is > the root thread group. > > The fix for that is simple - the call to > ecx.threadGroup.getParent() == null > needs to be done within a doPrivileged: Doesn't the absence of the permission indicate that this can't be the mainAppContext? Just wondering if catching the security exception was an alternative - not that I see any issue with the doPrivileged in this case. > > > The reg test fails without the fix and passes with it. Test nit: while(rootTG <- need a space after while Thanks for keeping TEST.groups up to date! David > best regards, > > -- daniel From artem.ananiev at oracle.com Tue Oct 15 03:23:09 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 15 Oct 2013 14:23:09 +0400 Subject: [OpenJDK 2D-Dev] [8] Review request for JDK-8025684 - Fix Raw and unchecked warnings java.awt.image classes In-Reply-To: <525C5816.5010909@oracle.com> References: <524B43EF.4080603@oracle.com> <524BEF41.2000304@oracle.com> <524C9AA7.6010500@oracle.com> <525C5816.5010909@oracle.com> Message-ID: <525D178D.9030301@oracle.com> On 10/15/2013 12:46 AM, srikalyan chandrashekar wrote: > Hi Jim, Thanks for reviewing and apologies for the delayed response, I > have made sure to set the properties type as String -> Object but mostly > the public constructor(OR) setter method enforces where Object> being too loose is guaranteed to not break at runtime but > is brittle and may break at runtime . But as you said > if it is documented then having this hole should be OK. I have updated > the webrev and is available in same location > . The new version is uploaded here: http://cr.openjdk.java.net/~art/srikalyc/8025684.02/ Thanks, Artem > -- > Thanks > kalyan > > On 10/2/13 3:13 PM, Jim Graham wrote: >> I'm not the greatest expert on generics (in particular, in terms of >> issues of retrofitting generics into existing public code without >> breaking compatibility), but I'll note that the properties on an image >> were always "documented" to be String->Object, but that was well >> before generics and so we just accepted bare hash tables everywhere. >> Is it possible to have at least some of the declarations of various >> properties objects to be declared as even though we >> are loose on the acceptance criteria in various constructors - or >> would that just completely break compatibility. I know that we use >> type erasure so we would never break binary compatibility, but there >> may be some places where we can have them more strongly typed >> internally for now, but more accepting at the external API level and >> then possibly consider improving the externally-visible typing in >> future versions when a source incompatibility is more appropriate? >> >> (I'm asking because I don't understand all of the compatibility issues >> that this might cause...) >> >> ...jim >> >> On 10/2/13 3:02 AM, Artem Ananiev wrote: >>> >>> java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to >>> CC. Please, wait for at least one approval from Java2D team. >>> >>> For easier review, I put the webrev here: >>> >>> http://cr.openjdk.java.net/~art/srikalyc/8025684.00/ >>> >>> It looks fine to me. There is one "unchecked" warning still left, at >>> BufferedImage.java:645, it can be fixed by introducing a local variable >>> and @SuppressWarnings("unchecked"), but I'm not sure it's worth doing. >>> >>> Thanks, >>> >>> Artem >>> >>> On 10/2/2013 1:51 AM, srikalyan chandrashekar wrote: >>>> Hi team , could someone review the fix >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8025684 >>>> Webrev : >>>> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.image.raw_unchecked_webrev.zip >>>> >>>> >>>> >>>> Fix : Raw and unchecked warnings in AWT image classes fixed >>>> > From daniel.fuchs at oracle.com Mon Oct 14 12:19:14 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 14 Oct 2013 21:19:14 +0200 Subject: RFR: 8026404 - Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") Message-ID: <525C43B2.6000007@oracle.com> Adding awt-dev... > The change looks okay to me but I would suggest sending to awt-dev so that the folks that maintain this area know about it. > > On the test then does initializing SunToolkit cause AWT to be initialized? I just wonder if this test will run headless. > > -Alan. Hi, Please find below a fix for: 8026404: Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") In some circumstances the call to JavaAWTAccess.getAppletContext() will trigger a call to ecx.threadGroup.getParent() == null The trouble is that this call will require a "modifyThreadGroup" permission if it happens that ecx.threadGroup.getParent() is the root thread group. The fix for that is simple - the call to ecx.threadGroup.getParent() == null needs to be done within a doPrivileged: The reg test fails without the fix and passes with it. best regards, -- daniel From daniel.fuchs at oracle.com Tue Oct 15 01:55:32 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 15 Oct 2013 10:55:32 +0200 Subject: RFR: 8026404 - Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") In-Reply-To: <525CF0F6.9090904@oracle.com> References: <525C43B2.6000007@oracle.com> <525CF0F6.9090904@oracle.com> Message-ID: <525D0304.5060305@oracle.com> Hi David, On 10/15/13 9:38 AM, David Holmes wrote: > On 15/10/2013 5:19 AM, Daniel Fuchs wrote: >> Adding awt-dev... >> >>> The change looks okay to me but I would suggest sending to awt-dev so >>> that the folks that maintain this area know about it. >>> >>> On the test then does initializing SunToolkit cause AWT to be >>> initialized? I just wonder if this test will run headless. >>> >>> -Alan. >> >> >> Hi, >> >> Please find below a fix for: >> >> 8026404: Logging in Applet can trigger ACE: >> access denied ("java.lang.RuntimePermission" >> "modifyThreadGroup") >> >> In some circumstances the call to JavaAWTAccess.getAppletContext() >> will trigger a call to ecx.threadGroup.getParent() == null >> The trouble is that this call will require a "modifyThreadGroup" >> permission if it happens that ecx.threadGroup.getParent() is >> the root thread group. >> >> The fix for that is simple - the call to >> ecx.threadGroup.getParent() == null >> needs to be done within a doPrivileged: > > Doesn't the absence of the permission indicate that this can't be the > mainAppContext? Just wondering if catching the security exception was an > alternative - not that I see any issue with the doPrivileged in this case. Well, yes and no. The exception will not be raised if there is only trusted code in the stack trace - so we can't really take that to ascertain whether this is the main app context. >> >> >> The reg test fails without the fix and passes with it. > > Test nit: while(rootTG <- need a space after while Thanks for spotting that. I will fix it before pushing! > Thanks for keeping TEST.groups up to date! I almost forgot ;-) -- daniel > > David > >> best regards, >> >> -- daniel From anthony.petrov at oracle.com Tue Oct 15 04:02:04 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 15 Oct 2013 15:02:04 +0400 Subject: [8] Review request for 8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: <525BFF2E.8040008@oracle.com> References: <52581E15.20108@oracle.com> <525BF577.80101@oracle.com> <525BFF2E.8040008@oracle.com> Message-ID: <525D20AC.6020808@oracle.com> Hi Anton, The analysis of the problem looks good. Please clarify one point: "(2) mouse moved to target in a single X11 event" Is the "single event" the one from (1) or from (3) ? IOW, are the (1) and (2) a single event, or the (2) and (3) ? Anyway, I have two concerns regarding the fix: 1. In startDrag() you now call the setNativeContext() and setCurrentJVMLocalSourceTransferable() under the awtLock, whereas previously these calls were preformed w/o the lock. This seems a bit risky as potentially this may cause some deadlocks. We should possibly rearrange the calls so that processMouseMove() is called before the above two calls, and the two calls remain outside the lock. Alternatively, we could acquire the lock again just for the sake of a call to processMouseMove(). 2. It looks suspicious that we call processMouseMove() unconditionally. The dragGestureMouseMotion could be stale, or uninitialized yet. Also, the event might actually be processed twice because doProcessEvent() returns false in that case. -- best regards, Anthony On 10/14/2013 06:26 PM, anton nashatyrev wrote: > Hi Artem, > > with the fix the 'drag entered' event is actually generated on the > mouse move event (step 2). Currently this first move event is 'consumed' > by the MouseGestureRecognizer and is not treated as the part of a drag > operation, while this move could be important (as in our case). > During the process I've created a couple of fixes which tried to > address the step 3, but all of them seemed to me rather like hacks than > fixes. > > BTW, I've run the regression DnD tests (from > test/closed/java/awt/dnd + test/java/awt/dnd, totally about 75 tests) - > all went fine. > > Thanks! > Anton. > > On 14.10.2013 17:45, Artem Ananiev wrote: >> Hi, Anton, >> >> thanks for details description of the bug and suggested fix. It helped >> a lot. >> >> My understanding is that the problem is not with step 2, but step 3. >> Generating "drag entered" events on mouse press looks incompatible, I >> can't predict side effects of such a change. Fixing step 3, so we >> don't assume drag entered events already sent, looks more correct. >> What do you think? >> >> Thanks, >> >> Artem >> >> On 10/11/2013 7:49 PM, anton nashatyrev wrote: >>> Hello, >>> could you please review the following fix: >>> >>> fix: http://cr.openjdk.java.net/~mcherkas/anton/8024061/webrev.00/ >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8024061 >>> >>> Problem: when doing quick drag'n'drop in X11 the incorrect >>> behavior appears in the different forms. One is the exception when >>> trying to get 'local Jvm' Transferable from DropTargetListener. >>> >>> Reason: on quick drag the following sequence of events may appear: >>> (1) mouse pressed on source -> (2) mouse moved to target in a single >>> X11 event -> (3) mouse released. What's happening in that case: on event >>> (2) only a drag gesture is recognized and no drag enter is generated >>> yet. On event (3) the XDragSourceContextPeer assumes that entered event >>> (if it happened) was already generated and the 'local JVM' transferable >>> had been already captured by SunDropTargetContextPeer from the static >>> field currentJVMLocalSourceTransferable. Thus on event (3) the >>> XDragSourceContextPeer posts the additional mouseMove event (which turns >>> into DragEnter later) and initiates the cleanup which then resets the >>> currentJVMLocalSourceTransferable to null. Thus on DragEnter the >>> currentJVMLocalSourceTransferable is already null and the >>> SunDropTargetContextPeer appears in the inconsistent state. >>> >>> Solution: the event (2) from the example above should not only >>> initiate the DnD operation but also be a part of that operation, i.e. >>> this event should also appear as a drag motion. For that I propose to >>> keep a track of the XMotionEvents in the XDragSourceContextPeer to catch >>> the mouse event which initiated the DnD and when a startDrag() is called >>> process this event as the first drag motion event. >>> >>> Thanks! >>> Anton. > From anthony.petrov at oracle.com Tue Oct 15 05:08:44 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 15 Oct 2013 16:08:44 +0400 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <52589CA1.4080503@oracle.com> References: <52589CA1.4080503@oracle.com> Message-ID: <525D304C.9090304@oracle.com> Hi Max, I don't have expertise in this code so I haven't reviewed the fix thoroughly. I'd like to point out one thing though: unlike AWT, Swing is a single-threaded GUI toolkit. While in AWT you can create components/windows and call APIs on any thread, in Swing everything GUI-related must be performed on the Event Dispatch Thread (EDT) only. Any long, non-GUI-related operations (like I/O, computations, etc.) should be dispatched on other threads (with a SwingWorker, for example). I don't see a single SwingUtilities.invokeLater/invokeAndWait() call in PolicyTool.java, so I thought I'd ask whether you're aware of the threading limitations imposed by Swing and how those are going to be addressed? -- best regards, Anthony On 10/12/2013 04:49 AM, Weijun Wang wrote: > Hi All > > Please review the fix at > > http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ > > The fix includes porting PolicyTool from AWT to Swing, defining > mnemonics for menu items and buttons, and adding keyboard shortcuts for > the File -> New/Open/Save items. Several tests are updated also. > > Thanks > Max From weijun.wang at oracle.com Tue Oct 15 07:13:09 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 15 Oct 2013 22:13:09 +0800 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <525D304C.9090304@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> Message-ID: <525D4D75.3090200@oracle.com> Policy Tool is a GUI editor for the plain text policy file. The only I/O is loading the policy file from disk and it should be quite small, so I think there won't be a problem here. Thanks Max On 10/15/13 8:08 PM, Anthony Petrov wrote: > Hi Max, > > I don't have expertise in this code so I haven't reviewed the fix > thoroughly. I'd like to point out one thing though: unlike AWT, Swing is > a single-threaded GUI toolkit. While in AWT you can create > components/windows and call APIs on any thread, in Swing everything > GUI-related must be performed on the Event Dispatch Thread (EDT) only. > Any long, non-GUI-related operations (like I/O, computations, etc.) > should be dispatched on other threads (with a SwingWorker, for example). > > I don't see a single SwingUtilities.invokeLater/invokeAndWait() call in > PolicyTool.java, so I thought I'd ask whether you're aware of the > threading limitations imposed by Swing and how those are going to be > addressed? > > -- > best regards, > Anthony > > On 10/12/2013 04:49 AM, Weijun Wang wrote: >> Hi All >> >> Please review the fix at >> >> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >> >> The fix includes porting PolicyTool from AWT to Swing, defining >> mnemonics for menu items and buttons, and adding keyboard shortcuts for >> the File -> New/Open/Save items. Several tests are updated also. >> >> Thanks >> Max From anthony.petrov at oracle.com Tue Oct 15 09:43:29 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 15 Oct 2013 20:43:29 +0400 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <525D4D75.3090200@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> <525D4D75.3090200@oracle.com> Message-ID: <525D70B1.4020603@oracle.com> Well, performing I/O or other blocking operations on EDT can only freeze the app's GUI for the period of blocking. If developers/users are OK with that, this is fine with me too. However, you should still call all Swing APIs (including creating your components/windows) on the EDT. And I don't see this is being done in your current code. As a minimum, the displayToolWindow() method should be dispatched on the event thread. I haven't examined the code closely, but if there are any other GUI updates from separate threads, those should also be moved to the EDT. See the following tutorial for details: http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html -- best regards, Anthony On 10/15/2013 06:13 PM, Weijun Wang wrote: > Policy Tool is a GUI editor for the plain text policy file. The only I/O > is loading the policy file from disk and it should be quite small, so I > think there won't be a problem here. > > Thanks > Max > > On 10/15/13 8:08 PM, Anthony Petrov wrote: >> Hi Max, >> >> I don't have expertise in this code so I haven't reviewed the fix >> thoroughly. I'd like to point out one thing though: unlike AWT, Swing is >> a single-threaded GUI toolkit. While in AWT you can create >> components/windows and call APIs on any thread, in Swing everything >> GUI-related must be performed on the Event Dispatch Thread (EDT) only. >> Any long, non-GUI-related operations (like I/O, computations, etc.) >> should be dispatched on other threads (with a SwingWorker, for example). >> >> I don't see a single SwingUtilities.invokeLater/invokeAndWait() call in >> PolicyTool.java, so I thought I'd ask whether you're aware of the >> threading limitations imposed by Swing and how those are going to be >> addressed? >> >> -- >> best regards, >> Anthony >> >> On 10/12/2013 04:49 AM, Weijun Wang wrote: >>> Hi All >>> >>> Please review the fix at >>> >>> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >>> >>> The fix includes porting PolicyTool from AWT to Swing, defining >>> mnemonics for menu items and buttons, and adding keyboard shortcuts for >>> the File -> New/Open/Save items. Several tests are updated also. >>> >>> Thanks >>> Max From sergey.bylokhov at oracle.com Tue Oct 15 09:42:56 2013 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Tue, 15 Oct 2013 16:42:56 +0000 Subject: hg: jdk8/awt/jdk: 2 new changesets Message-ID: <20131015164339.306C9623F8@hg.openjdk.java.net> Changeset: f9548641d699 Author: serb Date: 2013-10-15 20:37 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f9548641d699 7059886: 6 JCK manual awt/Desktop tests fail with GTKLookAndFeel - GTK intialization issue Reviewed-by: anthony, art Contributed-by: alexander.zvegintsev at oracle.com + src/solaris/classes/sun/misc/GThreadHelper.java ! src/solaris/native/sun/awt/awt_UNIXToolkit.c ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/xawt/awt_Desktop.c Changeset: 89546b9be510 Author: serb Date: 2013-10-15 20:40 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/89546b9be510 8025225: Window.setAlwaysOnTop documentation should be updated Reviewed-by: anthony, art Contributed-by: alexander.zvegintsev at oracle.com ! src/share/classes/java/awt/Window.java From alexander.potochkin at oracle.com Tue Oct 15 09:56:41 2013 From: alexander.potochkin at oracle.com (alexander potochkin) Date: Tue, 15 Oct 2013 09:56:41 -0700 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <525D70B1.4020603@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> <525D4D75.3090200@oracle.com> <525D70B1.4020603@oracle.com> Message-ID: <525D73C9.2090702@oracle.com> Hello > Well, performing I/O or other blocking operations on EDT can only > freeze the app's GUI for the period of blocking. If developers/users > are OK with that, this is fine with me too. > I don't think an I/O blocking operation on EDT is acceptable. It can freeze the whole application and give a bad experience to the users. Please consider using the SwingWorker API http://docs.oracle.com/javase/tutorial/uiswing/concurrency/worker.html > However, you should still call all Swing APIs (including creating your > components/windows) on the EDT. And I don't see this is being done in > your current code. As a minimum, the displayToolWindow() method should > be dispatched on the event thread. I haven't examined the code > closely, but if there are any other GUI updates from separate threads, > those should also be moved to the EDT. See the following tutorial for > details: > > http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html > Indeed, rewriting an AWT app as a Swing app is not only about changing Labels to JLabels Please make sure that all Swing code are used on the event dispatching thread only. Thanks alexp > -- > best regards, > Anthony > > On 10/15/2013 06:13 PM, Weijun Wang wrote: >> Policy Tool is a GUI editor for the plain text policy file. The only I/O >> is loading the policy file from disk and it should be quite small, so I >> think there won't be a problem here. >> >> Thanks >> Max >> >> On 10/15/13 8:08 PM, Anthony Petrov wrote: >>> Hi Max, >>> >>> I don't have expertise in this code so I haven't reviewed the fix >>> thoroughly. I'd like to point out one thing though: unlike AWT, >>> Swing is >>> a single-threaded GUI toolkit. While in AWT you can create >>> components/windows and call APIs on any thread, in Swing everything >>> GUI-related must be performed on the Event Dispatch Thread (EDT) only. >>> Any long, non-GUI-related operations (like I/O, computations, etc.) >>> should be dispatched on other threads (with a SwingWorker, for >>> example). >>> >>> I don't see a single SwingUtilities.invokeLater/invokeAndWait() call in >>> PolicyTool.java, so I thought I'd ask whether you're aware of the >>> threading limitations imposed by Swing and how those are going to be >>> addressed? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/12/2013 04:49 AM, Weijun Wang wrote: >>>> Hi All >>>> >>>> Please review the fix at >>>> >>>> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >>>> >>>> The fix includes porting PolicyTool from AWT to Swing, defining >>>> mnemonics for menu items and buttons, and adding keyboard shortcuts >>>> for >>>> the File -> New/Open/Save items. Several tests are updated also. >>>> >>>> Thanks >>>> Max From leif.samuelsson at oracle.com Tue Oct 15 10:00:45 2013 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Tue, 15 Oct 2013 10:00:45 -0700 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <525D73C9.2090702@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> <525D4D75.3090200@oracle.com> <525D70B1.4020603@oracle.com> <525D73C9.2090702@oracle.com> Message-ID: <525D74BD.6070707@oracle.com> Thanks for the good feedback. We will make sure to move to move the GUI instantiation to the EDT and the file I/O to a worker thread. All other operations are event driven and therefore occur directly on the EDT. Leif On 2013-10-15 09:56, alexander potochkin wrote: > Hello > >> Well, performing I/O or other blocking operations on EDT can only freeze the app's GUI for the period of blocking. If developers/users are OK with that, this is fine with me too. >> > > I don't think an I/O blocking operation on EDT is acceptable. It can freeze the whole application and give a bad experience to the users. > Please consider using the SwingWorker API > http://docs.oracle.com/javase/tutorial/uiswing/concurrency/worker.html > > >> However, you should still call all Swing APIs (including creating your components/windows) on the EDT. And I don't see this is being done in your current code. As a minimum, the displayToolWindow() method should be dispatched on the event thread. I haven't examined the code closely, but if there are any other GUI updates from separate threads, those should also be moved to the EDT. See the following tutorial for details: >> >> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html >> > > Indeed, rewriting an AWT app as a Swing app is not only about changing Labels to JLabels > Please make sure that all Swing code are used on the event dispatching thread only. > > Thanks > alexp > >> -- >> best regards, >> Anthony >> >> On 10/15/2013 06:13 PM, Weijun Wang wrote: >>> Policy Tool is a GUI editor for the plain text policy file. The only I/O >>> is loading the policy file from disk and it should be quite small, so I >>> think there won't be a problem here. >>> >>> Thanks >>> Max >>> >>> On 10/15/13 8:08 PM, Anthony Petrov wrote: >>>> Hi Max, >>>> >>>> I don't have expertise in this code so I haven't reviewed the fix >>>> thoroughly. I'd like to point out one thing though: unlike AWT, Swing is >>>> a single-threaded GUI toolkit. While in AWT you can create >>>> components/windows and call APIs on any thread, in Swing everything >>>> GUI-related must be performed on the Event Dispatch Thread (EDT) only. >>>> Any long, non-GUI-related operations (like I/O, computations, etc.) >>>> should be dispatched on other threads (with a SwingWorker, for example). >>>> >>>> I don't see a single SwingUtilities.invokeLater/invokeAndWait() call in >>>> PolicyTool.java, so I thought I'd ask whether you're aware of the >>>> threading limitations imposed by Swing and how those are going to be >>>> addressed? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/12/2013 04:49 AM, Weijun Wang wrote: >>>>> Hi All >>>>> >>>>> Please review the fix at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >>>>> >>>>> The fix includes porting PolicyTool from AWT to Swing, defining >>>>> mnemonics for menu items and buttons, and adding keyboard shortcuts for >>>>> the File -> New/Open/Save items. Several tests are updated also. >>>>> >>>>> Thanks >>>>> Max > From philip.race at oracle.com Tue Oct 15 15:48:46 2013 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Oct 2013 15:48:46 -0700 Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: <523A27A8.404@oracle.com> <523B01DF.1030902@oracle.com> Message-ID: <525DC64E.3060404@oracle.com> Hello Volker, I just remembered & got back to these changes - my email inbox isn't a very good reminder system. I am OK with everything I see in the client areas except as below :- /* Very basic start for AIX - feel free to complete .. 169 */ We should remove this comment. If that means first getting any necessary completion from IBM folks, please ask them. Given the lack of fontconfig on AIX as standard its probably more important for AIX than any other OS so I suggest the latter. > * insted it has to be installed from the "AIX Toolbox for Linux Applications" insted -> instead X11SurfaceData.c: #ifndef MAX and #ifndef MIN I found that re-definition warnings are seen at least on 64 bit linux. Maybe you should rename these too generically named macros to XSD_MAX and XSD_MIN. > extern int dladdr(void *addr, Dl_info *info); // use the HotSpot implementation from libjvm.so Did you ever get an opinion on this from the libraries or hotspot teams ? -phil. On 9/19/2013 7:28 AM, Volker Simonis wrote: > Hi Phil, > > I'm open to any good ideas. > > The current solution is pragmatic, simple and it has no impact on > existing platforms. > > The other possibility I see is to put the 'dladdr' implantation into > its own library (something equivalent to "libjli") and link that > library to "libawt". But I currently don't see any existing library I > could put the implementation into. > > Notice that the change I propose already contains an extra > implementation of 'dladdr' for AIX in > "src/solaris/demo/jvmti/hprof/hprof_md.c" because "libhprof" is not > linked against libjvm and we therefore can not use the 'extern'-trick > there. > > Of course it would be nice if there would be a small library which > contains 'dladdr' and which could be linked against both, "libawt" and > "libhprof". But I think that would require bigger shared changes (with > possible empty implementations on the current platforms). > > What do other think? > > Regards, > Volker > > > On Thu, Sep 19, 2013 at 3:53 PM, Phil Race wrote: >> Hi, >> >> w.r.t the one issue below : is the awt load library code the only place you >> need/are doing this ? If someone else (hotspot, core-libs) already assented >> to this >> then I guess I could too but I'd like to hear for sure that hotspot and >> core-libs >> teams both agree to this approach and whether there is an alternative. >> >> -phil. >> >> >> On 9/19/13 4:29 AM, Volker Simonis wrote: >> >> Hi Phil, >> >> thank you for looking at the changes. Please find my answers inline: >> >> >>> /* AIX does not provide the 'dladdr' function. But fortunately, we've >>> >>> 42 * already implemented it in the HotSpot, because we need it there as >>> 43 * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}). >>> >>> Whilst this is in "ifdef AIX" this reliance on an exported hotspot >>> function sounds hacky. What actual requirement is there that the >>> AIX class libraries be so tightly-coupled with that VM? >>> There is no contract there. >>> >> You're right, there is no contract. It's just pragmatic solution and I think >> it should always work because the libjvm will always be loaded at the point >> in AWT where it is used. Another solution would be to re-implement the >> functionality in the class library and I don't like code duplication either. >> >>> -phil. >>> >>> From oleg.pekhovskiy at oracle.com Wed Oct 16 03:31:38 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Wed, 16 Oct 2013 14:31:38 +0400 Subject: [8] Review request for 2228674: Fix failed for CR 7162144 Message-ID: <525E6B0A.5080200@oracle.com> Hi all, please review the fix http://cr.openjdk.java.net/~bagiras/2228674.1/ for https://bugs.openjdk.java.net/browse/JDK-2228674 The fix covers two scenarios: 1. User code calls EventDispatchThread.interrupt() and then EventDispatchThread.interrupted() which clears interrupted state and EDT doesn't stop. 2. EventDispatchThread.interrupt() is called without clearing the interrupted state (e.g. invocation of AppContext.dispose()) that makes EDT terminate. The other scenario, in which AppContext.dispose() is called from the thread other than EDT and after that EventDispatchThread.interrupted() is called from EDT preventing EDT from termination, is treated like an architecture bug. Some dead code was also removed because detaching of EDT is always forced. Thanks, Oleg From anton.nashatyrev at oracle.com Wed Oct 16 04:26:51 2013 From: anton.nashatyrev at oracle.com (anton nashatyrev) Date: Wed, 16 Oct 2013 15:26:51 +0400 Subject: [8] Review request for 8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: <525D20AC.6020808@oracle.com> References: <52581E15.20108@oracle.com> <525BF577.80101@oracle.com> <525BFF2E.8040008@oracle.com> <525D20AC.6020808@oracle.com> Message-ID: <525E77FB.3030108@oracle.com> Hello Anthony, thanks for having a look at the fix! See comments inlined: On 15.10.2013 15:02, Anthony Petrov wrote: > The analysis of the problem looks good. Please clarify one point: > > "(2) mouse moved to target in a single X11 event" > > Is the "single event" the one from (1) or from (3) ? IOW, are the (1) > and (2) a single event, or the (2) and (3) ? No, each step is a separate X event: (1) ButtonPress, (2) MotionNotify, (3) ButtonRelease > > Anyway, I have two concerns regarding the fix: > > 1. In startDrag() you now call the setNativeContext() and > setCurrentJVMLocalSourceTransferable() under the awtLock, whereas > previously these calls were preformed w/o the lock. This seems a bit > risky as potentially this may cause some deadlocks. We should possibly > rearrange the calls so that processMouseMove() is called before the > above two calls, and the two calls remain outside the lock. > Alternatively, we could acquire the lock again just for the sake of a > call to processMouseMove(). Agree, this would be safer. > > 2. It looks suspicious that we call processMouseMove() > unconditionally. The dragGestureMouseMotion could be stale, or > uninitialized yet. I'm assuming that startDrag may occur only in response to MotionNotify event, which should initialize the field and additionally we are synchronizing on awtLock (startDrag() is invoked on the EDT) so it looks like there is no need to check for initialization. Anyway if you think this is the right thing there is no problem to add an additional check. > Also, the event might actually be processed twice because > doProcessEvent() returns false in that case. Good point... Do you see any potential problem with that? The field dragGestureMouseMotion is accessed under awtLock in both places, so it would be either initialized on the first doProcessEvent call or if the second call occurs it might be rewritten with the same value (if dnd is still not started). Thanks! Anton. > > -- > best regards, > Anthony > > On 10/14/2013 06:26 PM, anton nashatyrev wrote: >> Hi Artem, >> >> with the fix the 'drag entered' event is actually generated on the >> mouse move event (step 2). Currently this first move event is 'consumed' >> by the MouseGestureRecognizer and is not treated as the part of a drag >> operation, while this move could be important (as in our case). >> During the process I've created a couple of fixes which tried to >> address the step 3, but all of them seemed to me rather like hacks than >> fixes. >> >> BTW, I've run the regression DnD tests (from >> test/closed/java/awt/dnd + test/java/awt/dnd, totally about 75 tests) - >> all went fine. >> >> Thanks! >> Anton. >> >> On 14.10.2013 17:45, Artem Ananiev wrote: >>> Hi, Anton, >>> >>> thanks for details description of the bug and suggested fix. It helped >>> a lot. >>> >>> My understanding is that the problem is not with step 2, but step 3. >>> Generating "drag entered" events on mouse press looks incompatible, I >>> can't predict side effects of such a change. Fixing step 3, so we >>> don't assume drag entered events already sent, looks more correct. >>> What do you think? >>> >>> Thanks, >>> >>> Artem >>> >>> On 10/11/2013 7:49 PM, anton nashatyrev wrote: >>>> Hello, >>>> could you please review the following fix: >>>> >>>> fix: http://cr.openjdk.java.net/~mcherkas/anton/8024061/webrev.00/ >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8024061 >>>> >>>> Problem: when doing quick drag'n'drop in X11 the incorrect >>>> behavior appears in the different forms. One is the exception when >>>> trying to get 'local Jvm' Transferable from DropTargetListener. >>>> >>>> Reason: on quick drag the following sequence of events may >>>> appear: >>>> (1) mouse pressed on source -> (2) mouse moved to target in a single >>>> X11 event -> (3) mouse released. What's happening in that case: on >>>> event >>>> (2) only a drag gesture is recognized and no drag enter is generated >>>> yet. On event (3) the XDragSourceContextPeer assumes that entered >>>> event >>>> (if it happened) was already generated and the 'local JVM' >>>> transferable >>>> had been already captured by SunDropTargetContextPeer from the static >>>> field currentJVMLocalSourceTransferable. Thus on event (3) the >>>> XDragSourceContextPeer posts the additional mouseMove event (which >>>> turns >>>> into DragEnter later) and initiates the cleanup which then resets the >>>> currentJVMLocalSourceTransferable to null. Thus on DragEnter the >>>> currentJVMLocalSourceTransferable is already null and the >>>> SunDropTargetContextPeer appears in the inconsistent state. >>>> >>>> Solution: the event (2) from the example above should not only >>>> initiate the DnD operation but also be a part of that operation, i.e. >>>> this event should also appear as a drag motion. For that I propose to >>>> keep a track of the XMotionEvents in the XDragSourceContextPeer to >>>> catch >>>> the mouse event which initiated the DnD and when a startDrag() is >>>> called >>>> process this event as the first drag motion event. >>>> >>>> Thanks! >>>> Anton. >> From anthony.petrov at oracle.com Wed Oct 16 04:29:55 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 16 Oct 2013 15:29:55 +0400 Subject: [8] Review request for 2228674: Fix failed for CR 7162144 In-Reply-To: <525E6B0A.5080200@oracle.com> References: <525E6B0A.5080200@oracle.com> Message-ID: <525E78B3.6040301@oracle.com> Hi Oleg, The fix looks good to me. However, I don't recall all details about this machinery, and removing a call to peekEvent() in EventQueue.detachDispatchThread() looks a bit scary. Could Artem or you clarify if AWTAutoShutdown() recreates the EDT if there are still events in the queue, or we simply don't care about them? -- best regards, Anthony On 10/16/2013 02:31 PM, Oleg Pekhovskiy wrote: > Hi all, > > please review the fix > http://cr.openjdk.java.net/~bagiras/2228674.1/ > for > https://bugs.openjdk.java.net/browse/JDK-2228674 > > The fix covers two scenarios: > 1. User code calls EventDispatchThread.interrupt() and then > EventDispatchThread.interrupted() which clears interrupted state and > EDT doesn't stop. > > 2. EventDispatchThread.interrupt() is called without clearing the > interrupted state (e.g. invocation of AppContext.dispose()) that makes > EDT terminate. > > The other scenario, in which AppContext.dispose() is called from the > thread other than EDT and after that EventDispatchThread.interrupted() > is called from EDT preventing EDT from termination, is treated like an > architecture bug. > > Some dead code was also removed because detaching of EDT is always forced. > > Thanks, > Oleg From anthony.petrov at oracle.com Wed Oct 16 04:41:27 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 16 Oct 2013 15:41:27 +0400 Subject: [8] Review request for 8024061: Exception thrown when drag and drop between two components is executed quickly In-Reply-To: <525E77FB.3030108@oracle.com> References: <52581E15.20108@oracle.com> <525BF577.80101@oracle.com> <525BFF2E.8040008@oracle.com> <525D20AC.6020808@oracle.com> <525E77FB.3030108@oracle.com> Message-ID: <525E7B67.2090403@oracle.com> Hi Anton, On 10/16/2013 03:26 PM, anton nashatyrev wrote: > On 15.10.2013 15:02, Anthony Petrov wrote: >> The analysis of the problem looks good. Please clarify one point: >> >> "(2) mouse moved to target in a single X11 event" >> >> Is the "single event" the one from (1) or from (3) ? IOW, are the (1) >> and (2) a single event, or the (2) and (3) ? > No, each step is a separate X event: (1) ButtonPress, (2) MotionNotify, > (3) ButtonRelease Please clarify what exactly do you mean by "mouse moved to target in a single X11 event"? Do I understand correctly that the real problem we're trying to fix here is the absence of a subsequent MotionNotify before the final ButtonRelease gets processed? >> Anyway, I have two concerns regarding the fix: >> >> 1. In startDrag() you now call the setNativeContext() and >> setCurrentJVMLocalSourceTransferable() under the awtLock, whereas >> previously these calls were preformed w/o the lock. This seems a bit >> risky as potentially this may cause some deadlocks. We should possibly >> rearrange the calls so that processMouseMove() is called before the >> above two calls, and the two calls remain outside the lock. >> Alternatively, we could acquire the lock again just for the sake of a >> call to processMouseMove(). > > Agree, this would be safer. > >> >> 2. It looks suspicious that we call processMouseMove() >> unconditionally. The dragGestureMouseMotion could be stale, or >> uninitialized yet. > > I'm assuming that startDrag may occur only in response to MotionNotify > event, which should initialize the field and additionally we are > synchronizing on awtLock (startDrag() is invoked on the EDT) so it looks > like there is no need to check for initialization. Anyway if you think > this is the right thing there is no problem to add an additional check. I think this assumption needs to be documented then. Please check all possible code paths leading to startDrag(). If it's only called in response to the MotionNotify event, then please add a comment about that to the code (right before the startDrag() definition seems to be the best place). In that case, no additional checks are needed. >> Also, the event might actually be processed twice because >> doProcessEvent() returns false in that case. > > Good point... Do you see any potential problem with that? > The field dragGestureMouseMotion is accessed under awtLock in both > places, so it would be either initialized on the first doProcessEvent > call or if the second call occurs it might be rewritten with the same > value (if dnd is still not started). I don't know if this is a problem or not, but this is a change in the (long-standing) behavior and some legacy apps may not be ready to handle that. Perhaps we could suppress handling of the mouse event somehow if we know startDrag() will process it anyway? -- best regards, Anthony > > Thanks! > Anton. > >> >> -- >> best regards, >> Anthony >> >> On 10/14/2013 06:26 PM, anton nashatyrev wrote: >>> Hi Artem, >>> >>> with the fix the 'drag entered' event is actually generated on the >>> mouse move event (step 2). Currently this first move event is 'consumed' >>> by the MouseGestureRecognizer and is not treated as the part of a drag >>> operation, while this move could be important (as in our case). >>> During the process I've created a couple of fixes which tried to >>> address the step 3, but all of them seemed to me rather like hacks than >>> fixes. >>> >>> BTW, I've run the regression DnD tests (from >>> test/closed/java/awt/dnd + test/java/awt/dnd, totally about 75 tests) - >>> all went fine. >>> >>> Thanks! >>> Anton. >>> >>> On 14.10.2013 17:45, Artem Ananiev wrote: >>>> Hi, Anton, >>>> >>>> thanks for details description of the bug and suggested fix. It helped >>>> a lot. >>>> >>>> My understanding is that the problem is not with step 2, but step 3. >>>> Generating "drag entered" events on mouse press looks incompatible, I >>>> can't predict side effects of such a change. Fixing step 3, so we >>>> don't assume drag entered events already sent, looks more correct. >>>> What do you think? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 10/11/2013 7:49 PM, anton nashatyrev wrote: >>>>> Hello, >>>>> could you please review the following fix: >>>>> >>>>> fix: http://cr.openjdk.java.net/~mcherkas/anton/8024061/webrev.00/ >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8024061 >>>>> >>>>> Problem: when doing quick drag'n'drop in X11 the incorrect >>>>> behavior appears in the different forms. One is the exception when >>>>> trying to get 'local Jvm' Transferable from DropTargetListener. >>>>> >>>>> Reason: on quick drag the following sequence of events may >>>>> appear: >>>>> (1) mouse pressed on source -> (2) mouse moved to target in a single >>>>> X11 event -> (3) mouse released. What's happening in that case: on >>>>> event >>>>> (2) only a drag gesture is recognized and no drag enter is generated >>>>> yet. On event (3) the XDragSourceContextPeer assumes that entered >>>>> event >>>>> (if it happened) was already generated and the 'local JVM' >>>>> transferable >>>>> had been already captured by SunDropTargetContextPeer from the static >>>>> field currentJVMLocalSourceTransferable. Thus on event (3) the >>>>> XDragSourceContextPeer posts the additional mouseMove event (which >>>>> turns >>>>> into DragEnter later) and initiates the cleanup which then resets the >>>>> currentJVMLocalSourceTransferable to null. Thus on DragEnter the >>>>> currentJVMLocalSourceTransferable is already null and the >>>>> SunDropTargetContextPeer appears in the inconsistent state. >>>>> >>>>> Solution: the event (2) from the example above should not only >>>>> initiate the DnD operation but also be a part of that operation, i.e. >>>>> this event should also appear as a drag motion. For that I propose to >>>>> keep a track of the XMotionEvents in the XDragSourceContextPeer to >>>>> catch >>>>> the mouse event which initiated the DnD and when a startDrag() is >>>>> called >>>>> process this event as the first drag motion event. >>>>> >>>>> Thanks! >>>>> Anton. >>> > From oleg.pekhovskiy at oracle.com Wed Oct 16 06:00:52 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Wed, 16 Oct 2013 17:00:52 +0400 Subject: [8] Review request for 2228674: Fix failed for CR 7162144 In-Reply-To: <525E78B3.6040301@oracle.com> References: <525E6B0A.5080200@oracle.com> <525E78B3.6040301@oracle.com> Message-ID: <525E8E04.2030505@oracle.com> Hi Anthony, thank you for the review. As for your question I could just refer to your fix for JDK 7 where the following changes we made in src/share/classes/java/awt/EventDispatchThread.java: @@ -100,7 +94,12 @@ class EventDispatchThread extends Thread } }); } finally { - if(getEventQueue().detachDispatchThread(this, shutdown)) { + // 7189350: doDispatch is reset from stopDispatching(), + // on InterruptedException, or ThreadDeath. Either way, + // this indicates that we must force shutting down. + if (getEventQueue().detachDispatchThread(this, + !doDispatch || isInterrupted())) + { break; } } Condition "!doDispatch || isInterrupted()" is always true and as a result forced detach is always performed. That's why in EventQueue.detachDispatchThread() method in condition "!forceDetach && (peekEvent() != null)" we never reach "peekEvent() != null" and therefore we could simply remove it. Thanks, Oleg On 16.10.2013 15:29, Anthony Petrov wrote: > Hi Oleg, > > The fix looks good to me. However, I don't recall all details about this > machinery, and removing a call to peekEvent() in > EventQueue.detachDispatchThread() looks a bit scary. > > Could Artem or you clarify if AWTAutoShutdown() recreates the EDT if > there are still events in the queue, or we simply don't care about them? > > -- > best regards, > Anthony > > On 10/16/2013 02:31 PM, Oleg Pekhovskiy wrote: >> Hi all, >> >> please review the fix >> http://cr.openjdk.java.net/~bagiras/2228674.1/ >> for >> https://bugs.openjdk.java.net/browse/JDK-2228674 >> >> The fix covers two scenarios: >> 1. User code calls EventDispatchThread.interrupt() and then >> EventDispatchThread.interrupted() which clears interrupted state and >> EDT doesn't stop. >> >> 2. EventDispatchThread.interrupt() is called without clearing the >> interrupted state (e.g. invocation of AppContext.dispose()) that makes >> EDT terminate. >> >> The other scenario, in which AppContext.dispose() is called from the >> thread other than EDT and after that EventDispatchThread.interrupted() >> is called from EDT preventing EDT from termination, is treated like an >> architecture bug. >> >> Some dead code was also removed because detaching of EDT is always >> forced. >> >> Thanks, >> Oleg From artem.ananiev at oracle.com Wed Oct 16 06:24:04 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 16 Oct 2013 17:24:04 +0400 Subject: [8] Review request for 2228674: Fix failed for CR 7162144 In-Reply-To: <525E78B3.6040301@oracle.com> References: <525E6B0A.5080200@oracle.com> <525E78B3.6040301@oracle.com> Message-ID: <525E9374.4000900@oracle.com> On 10/16/2013 3:29 PM, Anthony Petrov wrote: > Hi Oleg, > > The fix looks good to me. However, I don't recall all details about this > machinery, and removing a call to peekEvent() in > EventQueue.detachDispatchThread() looks a bit scary. > > Could Artem or you clarify if AWTAutoShutdown() recreates the EDT if > there are still events in the queue, or we simply don't care about them? EQ.detachDispatchThread() is called in two cases: when we caught ThreadDeath or InterruptedExceptions, and when EDT is interrupted (and the interrupted flag is not cleared). If this happens, when the current AppContext is disposed, we simply don't care if any events are pending. If the thread is interrupted for another reason, it will die anyway, but the very next incoming event will re-create EDT. In this case, thread interruption is considered an application bug. Thanks, Artem > -- > best regards, > Anthony > > On 10/16/2013 02:31 PM, Oleg Pekhovskiy wrote: >> Hi all, >> >> please review the fix >> http://cr.openjdk.java.net/~bagiras/2228674.1/ >> for >> https://bugs.openjdk.java.net/browse/JDK-2228674 >> >> The fix covers two scenarios: >> 1. User code calls EventDispatchThread.interrupt() and then >> EventDispatchThread.interrupted() which clears interrupted state and >> EDT doesn't stop. >> >> 2. EventDispatchThread.interrupt() is called without clearing the >> interrupted state (e.g. invocation of AppContext.dispose()) that makes >> EDT terminate. >> >> The other scenario, in which AppContext.dispose() is called from the >> thread other than EDT and after that EventDispatchThread.interrupted() >> is called from EDT preventing EDT from termination, is treated like an >> architecture bug. >> >> Some dead code was also removed because detaching of EDT is always >> forced. >> >> Thanks, >> Oleg From artem.ananiev at oracle.com Wed Oct 16 06:24:50 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 16 Oct 2013 17:24:50 +0400 Subject: [8] Review request for 2228674: Fix failed for CR 7162144 In-Reply-To: <525E6B0A.5080200@oracle.com> References: <525E6B0A.5080200@oracle.com> Message-ID: <525E93A2.2070405@oracle.com> Hi, Oleg, as we discussed this fix earlier, it looks fine. Thanks, Artem On 10/16/2013 2:31 PM, Oleg Pekhovskiy wrote: > Hi all, > > please review the fix > http://cr.openjdk.java.net/~bagiras/2228674.1/ > for > https://bugs.openjdk.java.net/browse/JDK-2228674 > > The fix covers two scenarios: > 1. User code calls EventDispatchThread.interrupt() and then > EventDispatchThread.interrupted() which clears interrupted state and > EDT doesn't stop. > > 2. EventDispatchThread.interrupt() is called without clearing the > interrupted state (e.g. invocation of AppContext.dispose()) that makes > EDT terminate. > > The other scenario, in which AppContext.dispose() is called from the > thread other than EDT and after that EventDispatchThread.interrupted() > is called from EDT preventing EDT from termination, is treated like an > architecture bug. > > Some dead code was also removed because detaching of EDT is always forced. > > Thanks, > Oleg From Sergey.Bylokhov at oracle.com Wed Oct 16 07:00:22 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 Oct 2013 18:00:22 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError Message-ID: <525E9BF6.9040602@oracle.com> Hello. Please review the fix for jdk 8. The fix has two parts - Repaint method in the peer now paint the component in place if it was called on EDT only. - Most of setters were changed to stop recursion if they were called on EDT. Bug: https://bugs.openjdk.java.net/browse/JDK-7090424 Webrev can be found at: http://cr.openjdk.java.net/~serb/7090424/webrev.00 -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Oct 16 07:55:11 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 Oct 2013 18:55:11 +0400 Subject: [8] Review Request: 8026356 [macosx] Found one Java-level deadlock:"AWT-EventQueue-0" && main Message-ID: <525EA8CF.7000307@oracle.com> Hello. Please review the fix for jdk 8. In the fix, synchronization on "this" under awttreelock was removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8026356 Webrev can be found at: http://cr.openjdk.java.net/~serb/8026356/webrev.00 -- Best regards, Sergey. From oleg.pekhovskiy at oracle.com Wed Oct 16 08:05:21 2013 From: oleg.pekhovskiy at oracle.com (oleg.pekhovskiy at oracle.com) Date: Wed, 16 Oct 2013 15:05:21 +0000 Subject: hg: jdk8/awt/jdk: 2228674: Fix failed for CR 7162144 Message-ID: <20131016150651.F0A3362462@hg.openjdk.java.net> Changeset: 229b10e97bd2 Author: bagiras Date: 2013-10-16 19:02 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/229b10e97bd2 2228674: Fix failed for CR 7162144 Reviewed-by: art, anthony ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java From Sergey.Bylokhov at oracle.com Wed Oct 16 09:03:20 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 Oct 2013 20:03:20 +0400 Subject: [8] Review Request: 8022657 Add FunctionalInterface annotation to awt interfaces Message-ID: <525EB8C8.5090504@oracle.com> Hello. Please review the fix for jdk 8. Some of the classes in awt were marked as FunctionalInterface. List of all suggested classes http://mail.openjdk.java.net/pipermail/awt-dev/2013-February/004213.html Bug: https://bugs.openjdk.java.net/browse/JDK-8022657 Webrev can be found at: http://cr.openjdk.java.net/~serb/8022657/webrev.00 -- Best regards, Sergey. From leonid.romanov at oracle.com Wed Oct 16 09:53:26 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 16 Oct 2013 20:53:26 +0400 Subject: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" (plan B) Message-ID: <74C28886-331D-4199-947E-9E2747E86AC1@oracle.com> Hello, This is plan B version of the fix for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS". The previous, proper version of the fix has been reviewed here: http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005441.html Unfortunately, I can't proceed with that version because there are some difficulties with submitting private JDK 8 build to Apple for approval. Since we are short on time and I want to fix this bug in JDK 8, I've had to use a workaround. Bug: https://bugs.openjdk.java.net/browse/JDK-8020209 webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.02/ Thanks, Leonid. From anthony.petrov at oracle.com Wed Oct 16 10:06:06 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 16 Oct 2013 21:06:06 +0400 Subject: [8] Review request for 2228674: Fix failed for CR 7162144 In-Reply-To: <525E9374.4000900@oracle.com> References: <525E6B0A.5080200@oracle.com> <525E78B3.6040301@oracle.com> <525E9374.4000900@oracle.com> Message-ID: <525EC77E.6090708@oracle.com> This indeed makes things clearer. Thanks for the explanation, Artem. I'm fine with the fix then (although I've noticed Oleg has already pushed it...) -- best regards, Anthony On 10/16/2013 05:24 PM, Artem Ananiev wrote: > > On 10/16/2013 3:29 PM, Anthony Petrov wrote: >> Hi Oleg, >> >> The fix looks good to me. However, I don't recall all details about this >> machinery, and removing a call to peekEvent() in >> EventQueue.detachDispatchThread() looks a bit scary. >> >> Could Artem or you clarify if AWTAutoShutdown() recreates the EDT if >> there are still events in the queue, or we simply don't care about them? > > EQ.detachDispatchThread() is called in two cases: when we caught > ThreadDeath or InterruptedExceptions, and when EDT is interrupted (and > the interrupted flag is not cleared). If this happens, when the current > AppContext is disposed, we simply don't care if any events are pending. > If the thread is interrupted for another reason, it will die anyway, but > the very next incoming event will re-create EDT. In this case, thread > interruption is considered an application bug. > > Thanks, > > Artem > >> -- >> best regards, >> Anthony >> >> On 10/16/2013 02:31 PM, Oleg Pekhovskiy wrote: >>> Hi all, >>> >>> please review the fix >>> http://cr.openjdk.java.net/~bagiras/2228674.1/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-2228674 >>> >>> The fix covers two scenarios: >>> 1. User code calls EventDispatchThread.interrupt() and then >>> EventDispatchThread.interrupted() which clears interrupted state and >>> EDT doesn't stop. >>> >>> 2. EventDispatchThread.interrupt() is called without clearing the >>> interrupted state (e.g. invocation of AppContext.dispose()) that makes >>> EDT terminate. >>> >>> The other scenario, in which AppContext.dispose() is called from the >>> thread other than EDT and after that EventDispatchThread.interrupted() >>> is called from EDT preventing EDT from termination, is treated like an >>> architecture bug. >>> >>> Some dead code was also removed because detaching of EDT is always >>> forced. >>> >>> Thanks, >>> Oleg From anthony.petrov at oracle.com Wed Oct 16 10:17:19 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 16 Oct 2013 21:17:19 +0400 Subject: [8] Review Request: 8026356 [macosx] Found one Java-level deadlock:"AWT-EventQueue-0" && main In-Reply-To: <525EA8CF.7000307@oracle.com> References: <525EA8CF.7000307@oracle.com> Message-ID: <525ECA1F.9030508@oracle.com> Looks fine. -- best regards, Anthony On 10/16/2013 06:55 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 8. > In the fix, synchronization on "this" under awttreelock was removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026356 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8026356/webrev.00 > From anthony.petrov at oracle.com Wed Oct 16 10:18:49 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 16 Oct 2013 21:18:49 +0400 Subject: [8] Review Request: 8022657 Add FunctionalInterface annotation to awt interfaces In-Reply-To: <525EB8C8.5090504@oracle.com> References: <525EB8C8.5090504@oracle.com> Message-ID: <525ECA79.60405@oracle.com> Looks fine. -- best regards, Anthony On 10/16/2013 08:03 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 8. > Some of the classes in awt were marked as FunctionalInterface. > > List of all suggested classes > http://mail.openjdk.java.net/pipermail/awt-dev/2013-February/004213.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8022657 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8022657/webrev.00 > From anthony.petrov at oracle.com Wed Oct 16 10:37:34 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 16 Oct 2013 21:37:34 +0400 Subject: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" (plan B) In-Reply-To: <74C28886-331D-4199-947E-9E2747E86AC1@oracle.com> References: <74C28886-331D-4199-947E-9E2747E86AC1@oracle.com> Message-ID: <525ECEDE.10503@oracle.com> Hi Leonid, The problem with overriding NSApplication -sendEvent: is that you can't be sure AWT is running with the NSApplicationAWT instance. If using SWT, FX, or otherwise embedding AWT into another application, the NSApp will point to an instance of another application class, and your sendEvent: will never be called. I'd suggest to avoid using this method altogether if possible. I see that webrev.01 also includes the changes in NSApplicationAWT.m. Is this really necessary for that version of the fix? I recall in your original review request you stated that the code currently consists of multiple workarounds, and adding another one could just bring more regressions or unexpected behaviors. So I'd actually prefer the version .01. Anyway, here's a couple of comments regarding the new fix: src/macosx/native/sun/awt/AWTView.m > 313 NSUInteger modFlags = [event modifierFlags] & > 314 (NSCommandKeyMask | NSAlternateKeyMask | NSShiftKeyMask | NSControlKeyMask); > 315 if (modFlags == NSCommandKeyMask) { Do I understand correctly that OS X is fine with e.g. Shift+Cmd+'+', and only Cmd+'+' is causing a problem? > 311 // Workaround for 8020209: special case for "Cmd =" and "Cmd ." > 312 // because Cocoa calls performKeyEquivalent twice for these keystrokes Interesting that you say that Cocoa sends multiple events and I'd guess one wants to filter some events out. However, at line 320 you call performKeyEquivalent yourself. Is this like the third call or something? Or the comment seems to be misleading otherwise. -- best regards, Anthony On 10/16/2013 08:53 PM, Leonid Romanov wrote: > Hello, > This is plan B version of the fix for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS". The previous, proper version of the fix has been reviewed here: > http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005441.html > Unfortunately, I can't proceed with that version because there are some difficulties with submitting private JDK 8 build to Apple for approval. Since we are short on time and I want to fix this bug in JDK 8, I've had to use a workaround. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8020209 > webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.02/ > > Thanks, > Leonid. > > > From leonid.romanov at oracle.com Wed Oct 16 16:19:58 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 17 Oct 2013 03:19:58 +0400 Subject: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" (plan B) In-Reply-To: <525ECEDE.10503@oracle.com> References: <74C28886-331D-4199-947E-9E2747E86AC1@oracle.com> <525ECEDE.10503@oracle.com> Message-ID: <3DC9E5AA-4E33-4E5F-BA97-862514346C10@oracle.com> On Oct 16, 2013, at 9:37 PM, Anthony Petrov wrote: > Hi Leonid, > > The problem with overriding NSApplication -sendEvent: is that you can't be sure AWT is running with the NSApplicationAWT instance. If using SWT, FX, or otherwise embedding AWT into another application, the NSApp will point to an instance of another application class, and your sendEvent: will never be called. I'd suggest to avoid using this method altogether if possible. Do I understand you correctly that in case of AWT embedding NSApp could be some NSApplication subclass other than NSApplicationAWT? If so, then this hypothetical subclass might have the very same code I've added to NSApplicationAWT since it's the most common approach for solving the problem of missing NSKeyUp events. In this case, our attempt to solve it in some other way will only make things worse: we might end up with duplicate NSKeyUp events. So, my suggestions is to leave that code as it is and if embedders complain about aforementioned problem, tell them to fix it on theirs app level, as we've done it in our NSApplicationAWT. > > I see that webrev.01 also includes the changes in NSApplicationAWT.m. Is this really necessary for that version of the fix? > > I recall in your original review request you stated that the code currently consists of multiple workarounds, and adding another one could just bring more regressions or unexpected behaviors. So I'd actually prefer the version .01. So do I. There are circumstances beyond my control that prevent me from landing the fix into JDK 8 GA. However, I still see .01 as the definitive version of the fix, and planning to include it into JDK 8 Update 1/JDK 9 (I'll file a separate bug for it). Version .02 is a not a long term solution for me. > > Anyway, here's a couple of comments regarding the new fix: > > src/macosx/native/sun/awt/AWTView.m >> 313 NSUInteger modFlags = [event modifierFlags] & >> 314 (NSCommandKeyMask | NSAlternateKeyMask | NSShiftKeyMask | NSControlKeyMask); >> 315 if (modFlags == NSCommandKeyMask) { > > Do I understand correctly that OS X is fine with e.g. Shift+Cmd+'+', and only Cmd+'+' is causing a problem? Yep. > >> 311 // Workaround for 8020209: special case for "Cmd =" and "Cmd ." >> 312 // because Cocoa calls performKeyEquivalent twice for these keystrokes > > Interesting that you say that Cocoa sends multiple events and I'd guess one wants to filter some events out. However, at line 320 you call performKeyEquivalent yourself. Is this like the third call or something? Or the comment seems to be misleading otherwise. Ok, looks like I need to extend the comment. Cocoa calls -performKeyEquivalent twice only if we return NO from the first -performKeyEquivalent call. Normally, what happens when performKeyEquivalent returns NO is that Cocoa calls -performKeyEquivalent for the next responder in the responders chain, until it finds the one which would return YES. "Cmd =" and "Cmd ." key strokes, however, are really unusual: if we and all other responders in the chain return NO, then Cocoa will construct another NSEvent and call -performKeyEquivalent for that event. Returning YES from the -performKeyEquivalent prevents that. However, this means that Cocoa won't call -performKeyEquivalent for the menu bar, so we have to do it manually. > > -- > best regards, > Anthony > > On 10/16/2013 08:53 PM, Leonid Romanov wrote: >> Hello, >> This is plan B version of the fix for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS". The previous, proper version of the fix has been reviewed here: >> http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005441.html >> Unfortunately, I can't proceed with that version because there are some difficulties with submitting private JDK 8 build to Apple for approval. Since we are short on time and I want to fix this bug in JDK 8, I've had to use a workaround. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8020209 >> webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.02/ >> >> Thanks, >> Leonid. >> >> >> From anthony.petrov at oracle.com Thu Oct 17 10:48:22 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 17 Oct 2013 17:48:22 +0000 Subject: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" (plan B) In-Reply-To: <3DC9E5AA-4E33-4E5F-BA97-862514346C10@oracle.com> References: <74C28886-331D-4199-947E-9E2747E86AC1@oracle.com> <525ECEDE.10503@oracle.com> <3DC9E5AA-4E33-4E5F-BA97-862514346C10@oracle.com> Message-ID: <526022E6.20806@oracle.com> Thanks for the clarifications. They sound good to me. Regarding NSApp instance, your understanding is correct. Although I'm not sure if this is a good idea to tell embedders to fix their code in this case. But I'm sort of OK with the current approach for now. So, I'd like to see the final version of the fix with an updated comment, and then I approve it. -- best regards, Anthony On 10/16/2013 11:19 PM, Leonid Romanov wrote: > > On Oct 16, 2013, at 9:37 PM, Anthony Petrov wrote: > >> Hi Leonid, >> >> The problem with overriding NSApplication -sendEvent: is that you can't be sure AWT is running with the NSApplicationAWT instance. If using SWT, FX, or otherwise embedding AWT into another application, the NSApp will point to an instance of another application class, and your sendEvent: will never be called. I'd suggest to avoid using this method altogether if possible. > > Do I understand you correctly that in case of AWT embedding NSApp could be some NSApplication subclass other than NSApplicationAWT? If so, then this hypothetical subclass might have the very same code I've added to NSApplicationAWT since it's the most common approach for solving the problem of missing NSKeyUp events. In this case, our attempt to solve it in some other way will only make things worse: we might end up with duplicate NSKeyUp events. > So, my suggestions is to leave that code as it is and if embedders complain about aforementioned problem, tell them to fix it on theirs app level, as we've done it in our NSApplicationAWT. > >> >> I see that webrev.01 also includes the changes in NSApplicationAWT.m. Is this really necessary for that version of the fix? >> >> I recall in your original review request you stated that the code currently consists of multiple workarounds, and adding another one could just bring more regressions or unexpected behaviors. So I'd actually prefer the version .01. > > So do I. There are circumstances beyond my control that prevent me from landing the fix into JDK 8 GA. However, I still see .01 as the definitive version of the fix, and planning to include it into JDK 8 Update 1/JDK 9 (I'll file a separate bug for it). Version .02 is a not a long term solution for me. > > >> >> Anyway, here's a couple of comments regarding the new fix: >> >> src/macosx/native/sun/awt/AWTView.m >>> 313 NSUInteger modFlags = [event modifierFlags] & >>> 314 (NSCommandKeyMask | NSAlternateKeyMask | NSShiftKeyMask | NSControlKeyMask); >>> 315 if (modFlags == NSCommandKeyMask) { >> >> Do I understand correctly that OS X is fine with e.g. Shift+Cmd+'+', and only Cmd+'+' is causing a problem? > > Yep. > >> >>> 311 // Workaround for 8020209: special case for "Cmd =" and "Cmd ." >>> 312 // because Cocoa calls performKeyEquivalent twice for these keystrokes >> >> Interesting that you say that Cocoa sends multiple events and I'd guess one wants to filter some events out. However, at line 320 you call performKeyEquivalent yourself. Is this like the third call or something? Or the comment seems to be misleading otherwise. > > Ok, looks like I need to extend the comment. Cocoa calls -performKeyEquivalent twice only if we return NO from the first -performKeyEquivalent call. Normally, what happens when performKeyEquivalent returns NO is that Cocoa calls -performKeyEquivalent for the next responder in the responders chain, until it finds the one which would return YES. "Cmd =" and "Cmd ." key strokes, however, are really unusual: if we and all other responders in the chain return NO, then Cocoa will construct another NSEvent and call -performKeyEquivalent for that event. Returning YES from the -performKeyEquivalent prevents that. However, this means that Cocoa won't call -performKeyEquivalent for the menu bar, so we have to do it manually. > >> >> -- >> best regards, >> Anthony >> >> On 10/16/2013 08:53 PM, Leonid Romanov wrote: >>> Hello, >>> This is plan B version of the fix for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS". The previous, proper version of the fix has been reviewed here: >>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005441.html >>> Unfortunately, I can't proceed with that version because there are some difficulties with submitting private JDK 8 build to Apple for approval. Since we are short on time and I want to fix this bug in JDK 8, I've had to use a workaround. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8020209 >>> webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.02/ >>> >>> Thanks, >>> Leonid. >>> >>> >>> > From Sergey.Bylokhov at oracle.com Thu Oct 17 06:51:04 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Oct 2013 17:51:04 +0400 Subject: [8] Review Request: 7157680 XAWT: Native components should not paint native part on UPDATE event. Message-ID: <525FEB48.9070708@oracle.com> Hello. Please review the fix for jdk 8. This fix is for xawt, the same bug was already fixed in lwawt JDK-7125657. According of http://www.oracle.com/technetwork/java/painting-140037.html# update() can be used for Incremental painting. And as example this tutorial provide this this demo: http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/special_report/painting/UpdateDemo.java It accidentally work in a xawt, because XCanvasPeer.paintPeer() is noop, but if Canvas will be replaced by the Label in the demo, then incremental version of the demo does not work. Bug: https://bugs.openjdk.java.net/browse/JDK-7157680 Webrev can be found at: http://cr.openjdk.java.net/~serb/7157680/webrev.00 -- Best regards, Sergey. From volker.simonis at gmail.com Thu Oct 17 06:42:34 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 17 Oct 2013 15:42:34 +0200 Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX In-Reply-To: <525DC64E.3060404@oracle.com> References: <523A27A8.404@oracle.com> <523B01DF.1030902@oracle.com> <525DC64E.3060404@oracle.com> Message-ID: Hi Phil, thanks a lot for the review. Please see my comments inline: On Wed, Oct 16, 2013 at 12:48 AM, Phil Race wrote: > Hello Volker, > > I just remembered & got back to these changes - my email inbox isn't a very > good reminder system. > > I am OK with everything I see in the client areas except as below :- > > /* Very basic start for AIX - feel free to complete .. > 169 */ > > We should remove this comment. If that means first getting > any necessary completion from IBM folks, please ask them. > Given the lack of fontconfig on AIX as standard its probably > more important for AIX than any other OS so I suggest the latter. > I've just checked with a colleague and the two paths seem to be the correct (and only standard) locations for Type1 and TrueType fonts on AIX. So I'll remove the comment and change to code to: #elif defined(AIX) static char *fullAixFontPath[] = { "/usr/lpp/X11/lib/X11/fonts/Type1", /* from X11.fnt.iso_T1 */ "/usr/lpp/X11/lib/X11/fonts/TrueType", /* from X11.fnt.ucs.ttf */ NULL, /* terminates the list */ }; #endif because "/usr/lib/X11/fonts/" are actually just symlinks to the real location under "/usr/lpp". The comment also names the filesets (i.e. the default AIX packages) which contain the corresponding fonts. > >> > * insted it has to be installed from the "AIX Toolbox for Linux > Applications" > > insted -> instead > Fixed. > X11SurfaceData.c: > > #ifndef MAX > and > #ifndef MIN > > I found that re-definition warnings are seen at least on > 64 bit linux. Maybe you should rename these too generically > named macros to XSD_MAX and XSD_MIN. > That's a good idea. Done. > >> extern int dladdr(void *addr, Dl_info *info); // use the HotSpot >> implementation from libjvm.so > > Did you ever get an opinion on this from the libraries or hotspot teams ? > No, I didn't got any opinions on that topic. I'm currently preparing a new webrev for the second review round where we can then hopefully clarify that point. Thank you and best regards, Volker > -phil. > > > On 9/19/2013 7:28 AM, Volker Simonis wrote: >> >> Hi Phil, >> >> I'm open to any good ideas. >> >> The current solution is pragmatic, simple and it has no impact on >> existing platforms. >> >> The other possibility I see is to put the 'dladdr' implantation into >> its own library (something equivalent to "libjli") and link that >> library to "libawt". But I currently don't see any existing library I >> could put the implementation into. >> >> Notice that the change I propose already contains an extra >> implementation of 'dladdr' for AIX in >> "src/solaris/demo/jvmti/hprof/hprof_md.c" because "libhprof" is not >> linked against libjvm and we therefore can not use the 'extern'-trick >> there. >> >> Of course it would be nice if there would be a small library which >> contains 'dladdr' and which could be linked against both, "libawt" and >> "libhprof". But I think that would require bigger shared changes (with >> possible empty implementations on the current platforms). >> >> What do other think? >> >> Regards, >> Volker >> >> >> On Thu, Sep 19, 2013 at 3:53 PM, Phil Race wrote: >>> >>> Hi, >>> >>> w.r.t the one issue below : is the awt load library code the only place >>> you >>> need/are doing this ? If someone else (hotspot, core-libs) already >>> assented >>> to this >>> then I guess I could too but I'd like to hear for sure that hotspot and >>> core-libs >>> teams both agree to this approach and whether there is an alternative. >>> >>> -phil. >>> >>> >>> On 9/19/13 4:29 AM, Volker Simonis wrote: >>> >>> Hi Phil, >>> >>> thank you for looking at the changes. Please find my answers inline: >>> >>> >>>> /* AIX does not provide the 'dladdr' function. But fortunately, we've >>>> >>>> 42 * already implemented it in the HotSpot, because we need it there >>>> as >>>> 43 * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}). >>>> >>>> Whilst this is in "ifdef AIX" this reliance on an exported hotspot >>>> function sounds hacky. What actual requirement is there that the >>>> AIX class libraries be so tightly-coupled with that VM? >>>> There is no contract there. >>>> >>> You're right, there is no contract. It's just pragmatic solution and I >>> think >>> it should always work because the libjvm will always be loaded at the >>> point >>> in AWT where it is used. Another solution would be to re-implement the >>> functionality in the class library and I don't like code duplication >>> either. >>> >>>> -phil. >>>> >>>> > From artem.ananiev at oracle.com Thu Oct 17 07:10:51 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 17 Oct 2013 18:10:51 +0400 Subject: [8] Review Request: 8022657 Add FunctionalInterface annotation to awt interfaces In-Reply-To: <525EB8C8.5090504@oracle.com> References: <525EB8C8.5090504@oracle.com> Message-ID: <525FEFEB.5010903@oracle.com> Hi, Sergey, we have a number of listener interfaces in java.awt.event, some of them have a single method, others have multiple. For consistency, I would refrain from marking some of them as @FunctionalInterfaces (though it's technically possible). KeyEventDispatcher and KeyEventPostProcessor are fine. Thanks, Artem On 10/16/2013 8:03 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 8. > Some of the classes in awt were marked as FunctionalInterface. > > List of all suggested classes > http://mail.openjdk.java.net/pipermail/awt-dev/2013-February/004213.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8022657 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8022657/webrev.00 > From anthony.petrov at oracle.com Thu Oct 17 11:13:26 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 17 Oct 2013 18:13:26 +0000 Subject: [8] Review Request: 7157680 XAWT: Native components should not paint native part on UPDATE event. In-Reply-To: <525FEB48.9070708@oracle.com> References: <525FEB48.9070708@oracle.com> Message-ID: <526028C6.9090807@oracle.com> Hi Sergey, I believe this fix belongs to early builds of JDK 9. -- best regards, Anthony On 10/17/2013 01:51 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 8. > This fix is for xawt, the same bug was already fixed in lwawt JDK-7125657. > According of > http://www.oracle.com/technetwork/java/painting-140037.html# update() > can be used for Incremental painting. And as example this tutorial > provide this this demo: > http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/special_report/painting/UpdateDemo.java > > It accidentally work in a xawt, because XCanvasPeer.paintPeer() is noop, > but if Canvas will be replaced by the Label in the demo, then > incremental version of the demo does not work. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7157680 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7157680/webrev.00 > From artem.ananiev at oracle.com Thu Oct 17 07:12:31 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 17 Oct 2013 18:12:31 +0400 Subject: [8] Review Request: 8026356 [macosx] Found one Java-level deadlock:"AWT-EventQueue-0" && main In-Reply-To: <525EA8CF.7000307@oracle.com> References: <525EA8CF.7000307@oracle.com> Message-ID: <525FF04F.8050906@oracle.com> Looks fine. Thanks, Artem On 10/16/2013 6:55 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 8. > In the fix, synchronization on "this" under awttreelock was removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026356 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8026356/webrev.00 > From Sergey.Bylokhov at oracle.com Thu Oct 17 07:34:01 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Oct 2013 18:34:01 +0400 Subject: [8] Review Request: 8022657 Add FunctionalInterface annotation to awt interfaces In-Reply-To: <525FEFEB.5010903@oracle.com> References: <525EB8C8.5090504@oracle.com> <525FEFEB.5010903@oracle.com> Message-ID: <525FF559.2050506@oracle.com> Hi, Artem. Here is updated version. http://cr.openjdk.java.net/~serb/8022657/webrev.01 On 17.10.2013 18:10, Artem Ananiev wrote: > Hi, Sergey, > > we have a number of listener interfaces in java.awt.event, some of > them have a single method, others have multiple. For consistency, I > would refrain from marking some of them as @FunctionalInterfaces > (though it's technically possible). > > KeyEventDispatcher and KeyEventPostProcessor are fine. > > Thanks, > > Artem > > On 10/16/2013 8:03 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk 8. >> Some of the classes in awt were marked as FunctionalInterface. >> >> List of all suggested classes >> http://mail.openjdk.java.net/pipermail/awt-dev/2013-February/004213.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8022657 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8022657/webrev.00 >> -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Thu Oct 17 07:42:28 2013 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 17 Oct 2013 18:42:28 +0400 Subject: [8] Review request for 8026476: Choice does not get mouse events if it does not have enough place for popup menu Message-ID: <525FF754.4090708@oracle.com> Hello, please review fix: http://cr.openjdk.java.net/~serb/alexz/8026476/webrev.00/ for: https://bugs.openjdk.java.net/browse/JDK-8026476 This fix places a drop-down menu above a choice component if it is not enough space below this component. Since a choice component is unobscured by its drop-down menu it is able to receive mouse released and clicked events. -- Thanks, Alexander. From artem.ananiev at oracle.com Thu Oct 17 07:55:00 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 17 Oct 2013 18:55:00 +0400 Subject: [8] Review Request: 8022657 Add FunctionalInterface annotation to awt interfaces In-Reply-To: <525FF559.2050506@oracle.com> References: <525EB8C8.5090504@oracle.com> <525FEFEB.5010903@oracle.com> <525FF559.2050506@oracle.com> Message-ID: <525FFA44.8010100@oracle.com> Looks fine. Thanks, Artem On 10/17/2013 6:34 PM, Sergey Bylokhov wrote: > Hi, Artem. > Here is updated version. > http://cr.openjdk.java.net/~serb/8022657/webrev.01 > > On 17.10.2013 18:10, Artem Ananiev wrote: >> Hi, Sergey, >> >> we have a number of listener interfaces in java.awt.event, some of >> them have a single method, others have multiple. For consistency, I >> would refrain from marking some of them as @FunctionalInterfaces >> (though it's technically possible). >> >> KeyEventDispatcher and KeyEventPostProcessor are fine. >> >> Thanks, >> >> Artem >> >> On 10/16/2013 8:03 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk 8. >>> Some of the classes in awt were marked as FunctionalInterface. >>> >>> List of all suggested classes >>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-February/004213.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8022657 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8022657/webrev.00 >>> > > From artem.ananiev at oracle.com Thu Oct 17 08:04:11 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 17 Oct 2013 19:04:11 +0400 Subject: [8] Review request for JDK-8026071 - Fix raw warnings in java AWT geometry package In-Reply-To: <5255A97E.2040902@oracle.com> References: <5255A97E.2040902@oracle.com> Message-ID: <525FFC6B.4070703@oracle.com> Hi, Kalyan, it seems that the webrev doesn't correspond to 8026071, but to another bug about javac warnings. Thanks, Artem On 10/9/2013 11:07 PM, srikalyan chandrashekar wrote: > Hi team , could someone review the fix > Bug : https://bugs.openjdk.java.net/browse/JDK-8026071 > Webrev : > https://github.com/srikalyc/JDKfixes/blob/master/java.awt.geom.raw.webrev.zip > Fix : Raw warnings in AWT geom classes fixed > > *NOTE*: In java.awt.geom.Area.java , the inner class AreaIterator's > public constructor's signature has been changed and is only indirectly > exposed through a public method "PathIterator > getPathIterator(AffineTransform at)" which is harmless . > > -- > > -- > Thanks > kalyan > From leif.samuelsson at oracle.com Thu Oct 17 09:57:55 2013 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Thu, 17 Oct 2013 09:57:55 -0700 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <525D74BD.6070707@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> <525D4D75.3090200@oracle.com> <525D70B1.4020603@oracle.com> <525D73C9.2090702@oracle.com> <525D74BD.6070707@oracle.com> Message-ID: <52601713.5020202@oracle.com> Hi All, A new webrev is available at: http://cr.openjdk.java.net/~weijun/7025699/webrev.01/ The following new changes were made: 1. Added call to SwingUtilities.invokeLater() in main() to run the GUI initialization on the Event Dispatch Thread. 2. Minor corrections to initial size and placement of the main window. 3. More mnemonics defined for buttons and labeled fields on the Policy Entry and KeyStore dialogs. Note that we have decided to not implement the use of SwingWorker for File I/O in this release. The main reasons are that it is not covered in the scope of the bug report, the blocking can not actually be considered a regression compared to the AWT version, and it would require enough refactoring of the code to risk affecting the general logic and cause new bugs. I am the Contributor for this bug fix, and Max (Weijun) will be the Committer. Thanks, Leif On 2013-10-15 10:00, Leif Samuelsson wrote: > Thanks for the good feedback. We will make sure to move to move the > GUI instantiation to the EDT and the file I/O to a worker thread. > > All other operations are event driven and therefore occur directly > on the EDT. > > Leif > > > On 2013-10-15 09:56, alexander potochkin wrote: >> Hello >> >>> Well, performing I/O or other blocking operations on EDT can only freeze the app's GUI for the period of blocking. If developers/users are OK with that, this is fine with me too. >>> >> >> I don't think an I/O blocking operation on EDT is acceptable. It can freeze the whole application and give a bad experience to the users. >> Please consider using the SwingWorker API >> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/worker.html >> >> >>> However, you should still call all Swing APIs (including creating your components/windows) on the EDT. And I don't see this is being done in your current code. As a minimum, the displayToolWindow() method should be dispatched on the event thread. I haven't examined the code closely, but if there are any other GUI updates from separate threads, those should also be moved to the EDT. See the following tutorial for details: >>> >>> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html >>> >> >> Indeed, rewriting an AWT app as a Swing app is not only about changing Labels to JLabels >> Please make sure that all Swing code are used on the event dispatching thread only. >> >> Thanks >> alexp >> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/15/2013 06:13 PM, Weijun Wang wrote: >>>> Policy Tool is a GUI editor for the plain text policy file. The only I/O >>>> is loading the policy file from disk and it should be quite small, so I >>>> think there won't be a problem here. >>>> >>>> Thanks >>>> Max >>>> >>>> On 10/15/13 8:08 PM, Anthony Petrov wrote: >>>>> Hi Max, >>>>> >>>>> I don't have expertise in this code so I haven't reviewed the fix >>>>> thoroughly. I'd like to point out one thing though: unlike AWT, Swing is >>>>> a single-threaded GUI toolkit. While in AWT you can create >>>>> components/windows and call APIs on any thread, in Swing everything >>>>> GUI-related must be performed on the Event Dispatch Thread (EDT) only. >>>>> Any long, non-GUI-related operations (like I/O, computations, etc.) >>>>> should be dispatched on other threads (with a SwingWorker, for example). >>>>> >>>>> I don't see a single SwingUtilities.invokeLater/invokeAndWait() call in >>>>> PolicyTool.java, so I thought I'd ask whether you're aware of the >>>>> threading limitations imposed by Swing and how those are going to be >>>>> addressed? >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 10/12/2013 04:49 AM, Weijun Wang wrote: >>>>>> Hi All >>>>>> >>>>>> Please review the fix at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >>>>>> >>>>>> The fix includes porting PolicyTool from AWT to Swing, defining >>>>>> mnemonics for menu items and buttons, and adding keyboard shortcuts for >>>>>> the File -> New/Open/Save items. Several tests are updated also. >>>>>> >>>>>> Thanks >>>>>> Max >> From andrei.eremeev at oracle.com Thu Oct 17 09:59:37 2013 From: andrei.eremeev at oracle.com (Andrei Eremeev) Date: Thu, 17 Oct 2013 09:59:37 -0700 (PDT) Subject: [8] Review Request: JDK-7002846 Fix for 6989505 may be incomplete Message-ID: <43c0c47a-8e4d-4d58-a015-36aa57699979@default> Hi, I am waiting for a second reviewer. Anthony's remark can be easily fixed. If there are no objections, I will fix bug id in the comment and commit fix. Andrei ----- ???????? ????????? ----- ??: anthony.petrov at oracle.com ????: andrei.eremeev at oracle.com ?????: artem.ananiev at oracle.com, sergey.bylokhov at oracle.com, awt-dev at openjdk.java.net ????????????: ???????, 11 ??????? 2013 ? 16:41:47 GMT +04:00 ???-????, ?????? ????: Re: [8] Review Request: JDK-7002846 Fix for 6989505 may be incomplete Hi Andrei, src/windows/classes/sun/awt/windows/WRobotPeer.java > 59 // See 6989505: that's ineffective, but works correctly with non-opaque windows It'd be more correct to mention 7002846 instead of 6989505 in this comment. The fix looks fine to me otherwise. -- best regards, Anthony On 10/10/2013 03:05 PM, andrei eremeev wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-7002846 > The fix is available at: > http://cr.openjdk.java.net/~yan/jdk-7002846/webrev.00/ > > The problem: WinAPI's function GetPixel returns incorrect value of not > fully opaque pixel on Intel graphic card. > The idea of the fix is to use getPixels(x, y, 1, 1)[0] which gets pixels > correctly. But this solution is 2 times slower than we had. From sergey.bylokhov at oracle.com Thu Oct 17 09:58:05 2013 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Thu, 17 Oct 2013 16:58:05 +0000 Subject: hg: jdk8/awt/jdk: 8022657: Add FunctionalInterface annotation to awt interfaces Message-ID: <20131017170026.45621624C3@hg.openjdk.java.net> Changeset: 70242d821c66 Author: serb Date: 2013-10-17 20:54 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/70242d821c66 8022657: Add FunctionalInterface annotation to awt interfaces Reviewed-by: anthony, art ! src/share/classes/java/awt/KeyEventDispatcher.java ! src/share/classes/java/awt/KeyEventPostProcessor.java From Sergey.Bylokhov at oracle.com Thu Oct 17 10:10:16 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Oct 2013 21:10:16 +0400 Subject: [8] Review request for 8026476: Choice does not get mouse events if it does not have enough place for popup menu In-Reply-To: <525FF754.4090708@oracle.com> References: <525FF754.4090708@oracle.com> Message-ID: <526019F8.1050407@oracle.com> Hi, Alexander. The fix looks good. On 17.10.2013 18:42, Alexander Zvegintsev wrote: > Hello, > > please review fix: > http://cr.openjdk.java.net/~serb/alexz/8026476/webrev.00/ > for: > https://bugs.openjdk.java.net/browse/JDK-8026476 > > This fix places a drop-down menu above a choice component if it is not > enough space below this component. > Since a choice component is unobscured by its drop-down menu it is > able to receive mouse released and clicked events. > -- Best regards, Sergey. From alexander.potochkin at oracle.com Thu Oct 17 10:11:12 2013 From: alexander.potochkin at oracle.com (alexander potochkin) Date: Thu, 17 Oct 2013 10:11:12 -0700 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <52601713.5020202@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> <525D4D75.3090200@oracle.com> <525D70B1.4020603@oracle.com> <525D73C9.2090702@oracle.com> <525D74BD.6070707@oracle.com> <52601713.5020202@oracle.com> Message-ID: <52601A30.8030401@oracle.com> Hello Leif Looks good to me I had a look at the PolicyTool code and indeed it is better to leave the IO processing as is at this moment. Thanks alexp > Hi All, > > A new webrev is available at: > > http://cr.openjdk.java.net/~weijun/7025699/webrev.01/ > > The following new changes were made: > > 1. Added call to SwingUtilities.invokeLater() in main() to run the GUI > initialization on the Event Dispatch Thread. > > 2. Minor corrections to initial size and placement of the main window. > > 3. More mnemonics defined for buttons and labeled fields on the Policy > Entry and KeyStore dialogs. > > Note that we have decided to not implement the use of SwingWorker for > File I/O in this release. The main reasons are that it is not covered > in the scope of the bug report, the blocking can not actually be > considered a regression compared to the AWT version, and it would > require enough refactoring of the code to risk affecting the general > logic and cause new bugs. > > I am the Contributor for this bug fix, and Max (Weijun) will be the > Committer. > > Thanks, > Leif > > > > On 2013-10-15 10:00, Leif Samuelsson wrote: >> Thanks for the good feedback. We will make sure to move to move the >> GUI instantiation to the EDT and the file I/O to a worker thread. >> >> All other operations are event driven and therefore occur directly >> on the EDT. >> >> Leif >> >> >> On 2013-10-15 09:56, alexander potochkin wrote: >>> Hello >>> >>>> Well, performing I/O or other blocking operations on EDT can only >>>> freeze the app's GUI for the period of blocking. If >>>> developers/users are OK with that, this is fine with me too. >>>> >>> >>> I don't think an I/O blocking operation on EDT is acceptable. It can >>> freeze the whole application and give a bad experience to the users. >>> Please consider using the SwingWorker API >>> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/worker.html >>> >>> >>>> However, you should still call all Swing APIs (including creating >>>> your components/windows) on the EDT. And I don't see this is being >>>> done in your current code. As a minimum, the displayToolWindow() >>>> method should be dispatched on the event thread. I haven't examined >>>> the code closely, but if there are any other GUI updates from >>>> separate threads, those should also be moved to the EDT. See the >>>> following tutorial for details: >>>> >>>> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html >>>> >>>> >>> >>> Indeed, rewriting an AWT app as a Swing app is not only about >>> changing Labels to JLabels >>> Please make sure that all Swing code are used on the event >>> dispatching thread only. >>> >>> Thanks >>> alexp >>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/15/2013 06:13 PM, Weijun Wang wrote: >>>>> Policy Tool is a GUI editor for the plain text policy file. The >>>>> only I/O >>>>> is loading the policy file from disk and it should be quite small, >>>>> so I >>>>> think there won't be a problem here. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> On 10/15/13 8:08 PM, Anthony Petrov wrote: >>>>>> Hi Max, >>>>>> >>>>>> I don't have expertise in this code so I haven't reviewed the fix >>>>>> thoroughly. I'd like to point out one thing though: unlike AWT, >>>>>> Swing is >>>>>> a single-threaded GUI toolkit. While in AWT you can create >>>>>> components/windows and call APIs on any thread, in Swing everything >>>>>> GUI-related must be performed on the Event Dispatch Thread (EDT) >>>>>> only. >>>>>> Any long, non-GUI-related operations (like I/O, computations, etc.) >>>>>> should be dispatched on other threads (with a SwingWorker, for >>>>>> example). >>>>>> >>>>>> I don't see a single SwingUtilities.invokeLater/invokeAndWait() >>>>>> call in >>>>>> PolicyTool.java, so I thought I'd ask whether you're aware of the >>>>>> threading limitations imposed by Swing and how those are going to be >>>>>> addressed? >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 10/12/2013 04:49 AM, Weijun Wang wrote: >>>>>>> Hi All >>>>>>> >>>>>>> Please review the fix at >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >>>>>>> >>>>>>> The fix includes porting PolicyTool from AWT to Swing, defining >>>>>>> mnemonics for menu items and buttons, and adding keyboard >>>>>>> shortcuts for >>>>>>> the File -> New/Open/Save items. Several tests are updated also. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>> From sergey.bylokhov at oracle.com Thu Oct 17 10:23:57 2013 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Thu, 17 Oct 2013 17:23:57 +0000 Subject: hg: jdk8/awt/jdk: 8026356: [macosx] Found one Java-level deadlock:"AWT-EventQueue-0" && main Message-ID: <20131017172424.6F8C0624C8@hg.openjdk.java.net> Changeset: 3c2d4569a6a3 Author: serb Date: 2013-10-17 21:22 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3c2d4569a6a3 8026356: [macosx] Found one Java-level deadlock:"AWT-EventQueue-0" && main Reviewed-by: anthony, art ! src/share/classes/java/awt/Component.java From Sergey.Bylokhov at oracle.com Thu Oct 17 10:49:41 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Oct 2013 21:49:41 +0400 Subject: [8] Review Request: 7157680 XAWT: Native components should not paint native part on UPDATE event. In-Reply-To: <526028C6.9090807@oracle.com> References: <525FEB48.9070708@oracle.com> <526028C6.9090807@oracle.com> Message-ID: <52602335.3030104@oracle.com> I guess at that time it will be a feature. On 17.10.2013 22:13, Anthony Petrov wrote: > Hi Sergey, > > I believe this fix belongs to early builds of JDK 9. > > -- > best regards, > Anthony > > On 10/17/2013 01:51 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk 8. >> This fix is for xawt, the same bug was already fixed in lwawt >> JDK-7125657. >> According of >> http://www.oracle.com/technetwork/java/painting-140037.html# update() >> can be used for Incremental painting. And as example this tutorial >> provide this this demo: >> http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/special_report/painting/UpdateDemo.java >> >> >> It accidentally work in a xawt, because XCanvasPeer.paintPeer() is noop, >> but if Canvas will be replaced by the Label in the demo, then >> incremental version of the demo does not work. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-7157680 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7157680/webrev.00 >> -- Best regards, Sergey. From srikalyan.chandrashekar at oracle.com Thu Oct 17 12:14:25 2013 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Thu, 17 Oct 2013 12:14:25 -0700 Subject: [8] Review request for JDK-8026071 - Fix raw warnings in java AWT geometry package In-Reply-To: <525FFC6B.4070703@oracle.com> References: <5255A97E.2040902@oracle.com> <525FFC6B.4070703@oracle.com> Message-ID: <52603711.9030005@oracle.com> Hi Artem, i just verified and that it indeed corresponds to 8026071 but you might also be looking at its parent umbrella JDK-7196567 which entails this bug 8026071 . --- Thanks kalyan On 10/17/2013 8:04 AM, Artem Ananiev wrote: > Hi, Kalyan, > > it seems that the webrev doesn't correspond to 8026071, but to another > bug about javac warnings. > > Thanks, > > Artem > > On 10/9/2013 11:07 PM, srikalyan chandrashekar wrote: >> Hi team , could someone review the fix >> Bug : https://bugs.openjdk.java.net/browse/JDK-8026071 >> Webrev : >> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.geom.raw.webrev.zip >> >> Fix : Raw warnings in AWT geom classes fixed >> >> *NOTE*: In java.awt.geom.Area.java , the inner class AreaIterator's >> public constructor's signature has been changed and is only indirectly >> exposed through a public method "PathIterator >> getPathIterator(AffineTransform at)" which is harmless . >> >> -- >> >> -- >> Thanks >> kalyan >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131017/c15521bf/attachment.html From anthony.petrov at oracle.com Thu Oct 17 13:21:52 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 18 Oct 2013 00:21:52 +0400 Subject: [8] Review Request: 8022657 Add FunctionalInterface annotation to awt interfaces In-Reply-To: <525FFA44.8010100@oracle.com> References: <525EB8C8.5090504@oracle.com> <525FEFEB.5010903@oracle.com> <525FF559.2050506@oracle.com> <525FFA44.8010100@oracle.com> Message-ID: <526046E0.3010601@oracle.com> +1 -- best regards, Anthony On 10/17/2013 06:55 PM, Artem Ananiev wrote: > > Looks fine. > > Thanks, > > Artem > > On 10/17/2013 6:34 PM, Sergey Bylokhov wrote: >> Hi, Artem. >> Here is updated version. >> http://cr.openjdk.java.net/~serb/8022657/webrev.01 >> >> On 17.10.2013 18:10, Artem Ananiev wrote: >>> Hi, Sergey, >>> >>> we have a number of listener interfaces in java.awt.event, some of >>> them have a single method, others have multiple. For consistency, I >>> would refrain from marking some of them as @FunctionalInterfaces >>> (though it's technically possible). >>> >>> KeyEventDispatcher and KeyEventPostProcessor are fine. >>> >>> Thanks, >>> >>> Artem >>> >>> On 10/16/2013 8:03 PM, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for jdk 8. >>>> Some of the classes in awt were marked as FunctionalInterface. >>>> >>>> List of all suggested classes >>>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-February/004213.html >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8022657 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/8022657/webrev.00 >>>> >> >> From anthony.petrov at oracle.com Thu Oct 17 13:28:24 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 18 Oct 2013 00:28:24 +0400 Subject: [8] Review request for 8026476: Choice does not get mouse events if it does not have enough place for popup menu In-Reply-To: <526019F8.1050407@oracle.com> References: <525FF754.4090708@oracle.com> <526019F8.1050407@oracle.com> Message-ID: <52604868.6040803@oracle.com> +1 -- best regards, Anthony On 10/17/2013 09:10 PM, Sergey Bylokhov wrote: > Hi, Alexander. > The fix looks good. > > On 17.10.2013 18:42, Alexander Zvegintsev wrote: >> Hello, >> >> please review fix: >> http://cr.openjdk.java.net/~serb/alexz/8026476/webrev.00/ >> for: >> https://bugs.openjdk.java.net/browse/JDK-8026476 >> >> This fix places a drop-down menu above a choice component if it is not >> enough space below this component. >> Since a choice component is unobscured by its drop-down menu it is >> able to receive mouse released and clicked events. >> > > From Sergey.Bylokhov at oracle.com Thu Oct 17 14:38:52 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 18 Oct 2013 01:38:52 +0400 Subject: [8] Review Request: 7157680 XAWT: Native components should not paint native part on UPDATE event. In-Reply-To: <52602335.3030104@oracle.com> References: <525FEB48.9070708@oracle.com> <526028C6.9090807@oracle.com> <52602335.3030104@oracle.com> Message-ID: <526058EC.10909@oracle.com> Also i don't see a difference between jdk 8 and 9, in case our tests will not catch the problem. If some regression will be found, will means that our code on osx is incorrect also. On 17.10.2013 21:49, Sergey Bylokhov wrote: > I guess at that time it will be a feature. > > On 17.10.2013 22:13, Anthony Petrov wrote: >> Hi Sergey, >> >> I believe this fix belongs to early builds of JDK 9. >> >> -- >> best regards, >> Anthony >> >> On 10/17/2013 01:51 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk 8. >>> This fix is for xawt, the same bug was already fixed in lwawt >>> JDK-7125657. >>> According of >>> http://www.oracle.com/technetwork/java/painting-140037.html# update() >>> can be used for Incremental painting. And as example this tutorial >>> provide this this demo: >>> http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/special_report/painting/UpdateDemo.java >>> >>> >>> It accidentally work in a xawt, because XCanvasPeer.paintPeer() is >>> noop, >>> but if Canvas will be replaced by the Label in the demo, then >>> incremental version of the demo does not work. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-7157680 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7157680/webrev.00 >>> > > -- Best regards, Sergey. From artem.ananiev at oracle.com Fri Oct 18 03:03:29 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 18 Oct 2013 14:03:29 +0400 Subject: [8] Review Request: JDK-7002846 Fix for 6989505 may be incomplete In-Reply-To: <43c0c47a-8e4d-4d58-a015-36aa57699979@default> References: <43c0c47a-8e4d-4d58-a015-36aa57699979@default> Message-ID: <52610771.9040707@oracle.com> Is .00 the latest version of the webrev? It looks fine to me. Thanks, Artem On 10/17/2013 8:59 PM, Andrei Eremeev wrote: > Hi, > > I am waiting for a second reviewer. Anthony's remark can be easily fixed. > If there are no objections, I will fix bug id in the comment and commit fix. > > Andrei > > ----- ???????? ????????? ----- > ??: anthony.petrov at oracle.com > ????: andrei.eremeev at oracle.com > ?????: artem.ananiev at oracle.com, sergey.bylokhov at oracle.com, awt-dev at openjdk.java.net > ????????????: ???????, 11 ??????? 2013 ? 16:41:47 GMT +04:00 ???-????, ?????? > ????: Re: [8] Review Request: JDK-7002846 Fix for 6989505 may be incomplete > > Hi Andrei, > > src/windows/classes/sun/awt/windows/WRobotPeer.java >> 59 // See 6989505: that's ineffective, but works correctly with non-opaque windows > > It'd be more correct to mention 7002846 instead of 6989505 in this > comment. The fix looks fine to me otherwise. > > -- > best regards, > Anthony > > On 10/10/2013 03:05 PM, andrei eremeev wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-7002846 >> The fix is available at: >> http://cr.openjdk.java.net/~yan/jdk-7002846/webrev.00/ >> >> The problem: WinAPI's function GetPixel returns incorrect value of not >> fully opaque pixel on Intel graphic card. >> The idea of the fix is to use getPixels(x, y, 1, 1)[0] which gets pixels >> correctly. But this solution is 2 times slower than we had. From anthony.petrov at oracle.com Fri Oct 18 03:05:50 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 18 Oct 2013 14:05:50 +0400 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <52601A30.8030401@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> <525D4D75.3090200@oracle.com> <525D70B1.4020603@oracle.com> <525D73C9.2090702@oracle.com> <525D74BD.6070707@oracle.com> <52601713.5020202@oracle.com> <52601A30.8030401@oracle.com> Message-ID: <526107FE.8050301@oracle.com> +1 -- best regards, Anthony On 10/17/2013 09:11 PM, alexander potochkin wrote: > Hello Leif > > Looks good to me > > I had a look at the PolicyTool code > and indeed it is better to leave the IO processing as is at this moment. > > Thanks > alexp > >> Hi All, >> >> A new webrev is available at: >> >> http://cr.openjdk.java.net/~weijun/7025699/webrev.01/ >> >> The following new changes were made: >> >> 1. Added call to SwingUtilities.invokeLater() in main() to run the GUI >> initialization on the Event Dispatch Thread. >> >> 2. Minor corrections to initial size and placement of the main window. >> >> 3. More mnemonics defined for buttons and labeled fields on the Policy >> Entry and KeyStore dialogs. >> >> Note that we have decided to not implement the use of SwingWorker for >> File I/O in this release. The main reasons are that it is not covered >> in the scope of the bug report, the blocking can not actually be >> considered a regression compared to the AWT version, and it would >> require enough refactoring of the code to risk affecting the general >> logic and cause new bugs. >> >> I am the Contributor for this bug fix, and Max (Weijun) will be the >> Committer. >> >> Thanks, >> Leif >> >> >> >> On 2013-10-15 10:00, Leif Samuelsson wrote: >>> Thanks for the good feedback. We will make sure to move to move the >>> GUI instantiation to the EDT and the file I/O to a worker thread. >>> >>> All other operations are event driven and therefore occur directly >>> on the EDT. >>> >>> Leif >>> >>> >>> On 2013-10-15 09:56, alexander potochkin wrote: >>>> Hello >>>> >>>>> Well, performing I/O or other blocking operations on EDT can only >>>>> freeze the app's GUI for the period of blocking. If >>>>> developers/users are OK with that, this is fine with me too. >>>>> >>>> >>>> I don't think an I/O blocking operation on EDT is acceptable. It can >>>> freeze the whole application and give a bad experience to the users. >>>> Please consider using the SwingWorker API >>>> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/worker.html >>>> >>>> >>>>> However, you should still call all Swing APIs (including creating >>>>> your components/windows) on the EDT. And I don't see this is being >>>>> done in your current code. As a minimum, the displayToolWindow() >>>>> method should be dispatched on the event thread. I haven't examined >>>>> the code closely, but if there are any other GUI updates from >>>>> separate threads, those should also be moved to the EDT. See the >>>>> following tutorial for details: >>>>> >>>>> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html >>>>> >>>>> >>>> >>>> Indeed, rewriting an AWT app as a Swing app is not only about >>>> changing Labels to JLabels >>>> Please make sure that all Swing code are used on the event >>>> dispatching thread only. >>>> >>>> Thanks >>>> alexp >>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 10/15/2013 06:13 PM, Weijun Wang wrote: >>>>>> Policy Tool is a GUI editor for the plain text policy file. The >>>>>> only I/O >>>>>> is loading the policy file from disk and it should be quite small, >>>>>> so I >>>>>> think there won't be a problem here. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> On 10/15/13 8:08 PM, Anthony Petrov wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> I don't have expertise in this code so I haven't reviewed the fix >>>>>>> thoroughly. I'd like to point out one thing though: unlike AWT, >>>>>>> Swing is >>>>>>> a single-threaded GUI toolkit. While in AWT you can create >>>>>>> components/windows and call APIs on any thread, in Swing everything >>>>>>> GUI-related must be performed on the Event Dispatch Thread (EDT) >>>>>>> only. >>>>>>> Any long, non-GUI-related operations (like I/O, computations, etc.) >>>>>>> should be dispatched on other threads (with a SwingWorker, for >>>>>>> example). >>>>>>> >>>>>>> I don't see a single SwingUtilities.invokeLater/invokeAndWait() >>>>>>> call in >>>>>>> PolicyTool.java, so I thought I'd ask whether you're aware of the >>>>>>> threading limitations imposed by Swing and how those are going to be >>>>>>> addressed? >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 10/12/2013 04:49 AM, Weijun Wang wrote: >>>>>>>> Hi All >>>>>>>> >>>>>>>> Please review the fix at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >>>>>>>> >>>>>>>> The fix includes porting PolicyTool from AWT to Swing, defining >>>>>>>> mnemonics for menu items and buttons, and adding keyboard >>>>>>>> shortcuts for >>>>>>>> the File -> New/Open/Save items. Several tests are updated also. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>> > From anthony.petrov at oracle.com Fri Oct 18 04:17:43 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 18 Oct 2013 15:17:43 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError In-Reply-To: <525E9BF6.9040602@oracle.com> References: <525E9BF6.9040602@oracle.com> Message-ID: <526118D7.8040106@oracle.com> Hi Sergey, In XAWT, we usually use the StateLock to synchronize access to peer fields (such as background, label, etc.) I don't think that switching to volatile is a good idea since it prevents us from performing atomic read/writes to the fields. And this is exactly what we need for this fix, actually. In other words, the following pattern works perfectly: synchronized (lock) { if (a != b) { a = b; // do stuff, or set a flag to do it later w/o the lock } } whereas the following doesn't: volatile a; if (a != b) { a = b; // do stuff } The latter doesn't work because the value of 'a' may change from another thread after the if() statement in the first thread is executed. Please note that this is critical for AWT because it is a multi-threaded GUI toolkit. src/solaris/classes/sun/awt/X11/XListPeer.java > - target.paint(g); > + handleExposeEvent(target, 0, 0, getWidth(), getHeight()); (the same applies to XWindow.repaint): can you please rename XWindow.handleExposeEvent(Component...) to postPaintEvent() and make it final? A good javadoc for this method would also be appreciated, because currently seeing the name handle*() I'd think it needs to be done under the awtLock(). Also, for the corresponding changes in XWindow.repaint(), could you please elaborate a bit more? Looking at the code I see that XWindow.paint() calls paintPeer(). And in repaint(), you either call paint() or paintPeer() depending on the current thread. Why is it needed? Can we just call paintPeer() (or paint() for that matter) unconditionally since they both seem to result in the same call? Also, why don't we post an event if reapint() is invoked on the EDT? -- best regards, Anthony On 10/16/2013 06:00 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 8. > The fix has two parts > - Repaint method in the peer now paint the component in place if it > was called on EDT only. > - Most of setters were changed to stop recursion if they were called > on EDT. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7090424 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7090424/webrev.00 > From yuri.nesterenko at oracle.com Fri Oct 18 04:16:54 2013 From: yuri.nesterenko at oracle.com (yuri.nesterenko at oracle.com) Date: Fri, 18 Oct 2013 11:16:54 +0000 Subject: hg: jdk8/awt/jdk: 7002846: Fix for 6989505 may be incomplete Message-ID: <20131018111812.6ED3D62515@hg.openjdk.java.net> Changeset: 5334c651c7ba Author: yan Date: 2013-10-18 15:15 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5334c651c7ba 7002846: Fix for 6989505 may be incomplete Reviewed-by: anthony, art Contributed-by: Andrei Eremeev ! src/windows/classes/sun/awt/windows/WRobotPeer.java ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Robot.h From Sergey.Bylokhov at oracle.com Fri Oct 18 04:47:05 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 18 Oct 2013 15:47:05 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError In-Reply-To: <526118D7.8040106@oracle.com> References: <525E9BF6.9040602@oracle.com> <526118D7.8040106@oracle.com> Message-ID: <52611FB9.9080605@oracle.com> Hi, Anthony. On 18.10.2013 15:17, Anthony Petrov wrote: > Hi Sergey, > > In XAWT, we usually use the StateLock to synchronize access to peer > fields (such as background, label, etc.) I don't think that switching > to volatile is a good idea since it prevents us from performing atomic > read/writes to the fields. And this is exactly what we need for this > fix, actually. In other words, the following pattern works perfectly: > > synchronized (lock) { > if (a != b) { > a = b; > // do stuff, or set a flag to do it later w/o the lock > } > } > > whereas the following doesn't: > > volatile a; > if (a != b) { > a = b; > // do stuff > } > > The latter doesn't work because the value of 'a' may change from > another thread after the if() statement in the first thread is executed. If it will be changed that's ok. It is safe in this context since there is no races. a will be the latest setted value and repaint action will be done after a was set. Non trivial setters(like setLabel/setText) are called under the locks in shared code. > > Please note that this is critical for AWT because it is a > multi-threaded GUI toolkit. > > src/solaris/classes/sun/awt/X11/XListPeer.java >> - target.paint(g); >> + handleExposeEvent(target, 0, 0, getWidth(), >> getHeight()); > > (the same applies to XWindow.repaint): can you please rename > XWindow.handleExposeEvent(Component...) to postPaintEvent() and make > it final? A good javadoc for this method would also be appreciated, > because currently seeing the name handle*() I'd think it needs to be > done under the awtLock(). Will do. > > Also, for the corresponding changes in XWindow.repaint(), could you > please elaborate a bit more? Looking at the code I see that > XWindow.paint() calls paintPeer(). And in repaint(), you either call > paint() or paintPeer() depending on the current thread. Why is it > needed? Can we just call paintPeer() (or paint() for that matter) > unconditionally since they both seem to result in the same call? paintPeer is used to draw the native part of the peer(text of the label, border of the button etc). paint is a part of Component.paintAll(). And as a result of it call it should paint the native part of the peer and it should call appropriate paint method from the target. > Also, why don't we post an event if reapint() is invoked on the EDT? We do this in osx, but in xawt there are "smart" caches, which are initialized during the paint of the peer. See XLabelPeer&cachedFontMetrics for example . Note that this cache is completely broken. > > -- > best regards, > Anthony > > On 10/16/2013 06:00 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk 8. >> The fix has two parts >> - Repaint method in the peer now paint the component in place if it >> was called on EDT only. >> - Most of setters were changed to stop recursion if they were called >> on EDT. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-7090424 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7090424/webrev.00 >> -- Best regards, Sergey. From sergey.bylokhov at oracle.com Fri Oct 18 09:37:24 2013 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Fri, 18 Oct 2013 16:37:24 +0000 Subject: hg: jdk8/awt/jdk: 8026476: Choice does not get mouse events if it does not have enough place for popup menu Message-ID: <20131018163807.43F8362536@hg.openjdk.java.net> Changeset: 84ae644933b6 Author: serb Date: 2013-10-18 20:35 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/84ae644933b6 8026476: Choice does not get mouse events if it does not have enough place for popup menu Reviewed-by: anthony, serb Contributed-by: alexander.zvegintsev at oracle.com ! src/solaris/classes/sun/awt/X11/XChoicePeer.java From david.dehaven at oracle.com Sun Oct 20 16:53:23 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Sun, 20 Oct 2013 16:53:23 -0700 Subject: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated Message-ID: CCing: build-dev, macosx-port-dev Request for review of JDK-8016096: https://bugs.openjdk.java.net/browse/JDK-8016096 Proposed changes: http://cr.openjdk.java.net/~ddehaven/8016096/ Significant build system changes for this one so feedback from build-dev is appreciated. Actual functional changes are just ported from the JDK7 changes I made several months ago, less the X11 dependency in jawt_md.h. The autoconf changes also trigger an update of generated-configure.sh in jdk/make/closed, that will need to be pushed too. Please note: These patches will not work alone! You must also apply the patches for 8025673, which I'm also submitting for review. Built and tested on Mac and Linux. I'm in the process of submitting JPRT runs. -DrD- From david.dehaven at oracle.com Sun Oct 20 16:56:13 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Sun, 20 Oct 2013 16:56:13 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit Message-ID: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> CCing: build-dev, macosx-port-dev, hotspot-dev Request for review of JDK-8025673: https://bugs.openjdk.java.net/browse/JDK-8025673 Proposed changes: http://cr.openjdk.java.net/~ddehaven/8025673/ This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. Significant build system changes, build-dev guys are encouraged to comment... I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. Question for the AWT team, we still have this in java_props_md.c: 458 PreferredToolkit prefToolkit = getPreferredToolkit(); 459 if (prefToolkit == CToolkit) { 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; 461 } else { 462 // TODO: do we still need this? 463 sprops.awt_toolkit = "sun.awt.HToolkit"; 464 } Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. -DrD- From erik.joelsson at oracle.com Mon Oct 21 01:31:31 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 Oct 2013 10:31:31 +0200 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> Message-ID: <5264E663.7050401@oracle.com> Hello David, From a build point of view, the changes look fine to me. /Erik On 2013-10-21 01:56, David DeHaven wrote: > CCing: build-dev, macosx-port-dev, hotspot-dev > > Request for review of JDK-8025673: > https://bugs.openjdk.java.net/browse/JDK-8025673 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8025673/ > > This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). > > A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. > > Significant build system changes, build-dev guys are encouraged to comment... > > I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. > > The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. > > > Question for the AWT team, we still have this in java_props_md.c: > 458 PreferredToolkit prefToolkit = getPreferredToolkit(); > 459 if (prefToolkit == CToolkit) { > 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; > 461 } else { > 462 // TODO: do we still need this? > 463 sprops.awt_toolkit = "sun.awt.HToolkit"; > 464 } > > Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. > > > I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. > > JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. > > -DrD- > From erik.joelsson at oracle.com Mon Oct 21 01:31:55 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 Oct 2013 10:31:55 +0200 Subject: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated In-Reply-To: References: Message-ID: <5264E67B.80502@oracle.com> Hello David, From a build point of view, the changes look fine to me. /Erik On 2013-10-21 01:53, David DeHaven wrote: > CCing: build-dev, macosx-port-dev > > Request for review of JDK-8016096: > https://bugs.openjdk.java.net/browse/JDK-8016096 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8016096/ > > Significant build system changes for this one so feedback from build-dev is appreciated. Actual functional changes are just ported from the JDK7 changes I made several months ago, less the X11 dependency in jawt_md.h. The autoconf changes also trigger an update of generated-configure.sh in jdk/make/closed, that will need to be pushed too. > > > Please note: > These patches will not work alone! You must also apply the patches for 8025673, which I'm also submitting for review. > > > Built and tested on Mac and Linux. I'm in the process of submitting JPRT runs. > > -DrD- > From artem.ananiev at oracle.com Mon Oct 21 02:35:39 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 21 Oct 2013 13:35:39 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> Message-ID: <5264F56B.6030100@oracle.com> Hi, David, the changes look fine to me. See more comments below. On 10/21/2013 3:56 AM, David DeHaven wrote: > > CCing: build-dev, macosx-port-dev, hotspot-dev > > Request for review of JDK-8025673: > https://bugs.openjdk.java.net/browse/JDK-8025673 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8025673/ > > This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). > > A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. > > Significant build system changes, build-dev guys are encouraged to comment... > > I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. > > The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. > > > Question for the AWT team, we still have this in java_props_md.c: > 458 PreferredToolkit prefToolkit = getPreferredToolkit(); > 459 if (prefToolkit == CToolkit) { > 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; > 461 } else { > 462 // TODO: do we still need this? > 463 sprops.awt_toolkit = "sun.awt.HToolkit"; > 464 } > > Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. This question is for SE embedded team and for people who are responsible for reduced JRE builds, when some native libraries (including libawt_lwawt) are stripped. If these reduced builds are only for Solaris/Linux, then we don't need HToolkit stuff on Mac. Thanks, Artem > I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. > > JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. > > -DrD- > From artem.ananiev at oracle.com Mon Oct 21 03:33:38 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 21 Oct 2013 14:33:38 +0400 Subject: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated In-Reply-To: References: Message-ID: <52650302.2080100@oracle.com> Hi, David, client (AWT, Java2D) part of the fix looks fine. Thanks, Artem On 10/21/2013 3:53 AM, David DeHaven wrote: > > CCing: build-dev, macosx-port-dev > > Request for review of JDK-8016096: > https://bugs.openjdk.java.net/browse/JDK-8016096 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8016096/ > > Significant build system changes for this one so feedback from build-dev is appreciated. Actual functional changes are just ported from the JDK7 changes I made several months ago, less the X11 dependency in jawt_md.h. The autoconf changes also trigger an update of generated-configure.sh in jdk/make/closed, that will need to be pushed too. > > > Please note: > These patches will not work alone! You must also apply the patches for 8025673, which I'm also submitting for review. > > > Built and tested on Mac and Linux. I'm in the process of submitting JPRT runs. > > -DrD- > From leonid.romanov at oracle.com Mon Oct 21 04:26:08 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 21 Oct 2013 15:26:08 +0400 Subject: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" (plan B) In-Reply-To: <526022E6.20806@oracle.com> References: <74C28886-331D-4199-947E-9E2747E86AC1@oracle.com> <525ECEDE.10503@oracle.com> <3DC9E5AA-4E33-4E5F-BA97-862514346C10@oracle.com> <526022E6.20806@oracle.com> Message-ID: Here is an updated version of the fix with the expanded comment: http://cr.openjdk.java.net/~leonidr/8020209/webrev.03/ On 17.10.2013, at 21:48, Anthony Petrov wrote: > Thanks for the clarifications. They sound good to me. > > Regarding NSApp instance, your understanding is correct. Although I'm not sure if this is a good idea to tell embedders to fix their code in this case. But I'm sort of OK with the current approach for now. > > So, I'd like to see the final version of the fix with an updated comment, and then I approve it. > > -- > best regards, > Anthony > > On 10/16/2013 11:19 PM, Leonid Romanov wrote: >> >> On Oct 16, 2013, at 9:37 PM, Anthony Petrov wrote: >> >>> Hi Leonid, >>> >>> The problem with overriding NSApplication -sendEvent: is that you can't be sure AWT is running with the NSApplicationAWT instance. If using SWT, FX, or otherwise embedding AWT into another application, the NSApp will point to an instance of another application class, and your sendEvent: will never be called. I'd suggest to avoid using this method altogether if possible. >> >> Do I understand you correctly that in case of AWT embedding NSApp could be some NSApplication subclass other than NSApplicationAWT? If so, then this hypothetical subclass might have the very same code I've added to NSApplicationAWT since it's the most common approach for solving the problem of missing NSKeyUp events. In this case, our attempt to solve it in some other way will only make things worse: we might end up with duplicate NSKeyUp events. >> So, my suggestions is to leave that code as it is and if embedders complain about aforementioned problem, tell them to fix it on theirs app level, as we've done it in our NSApplicationAWT. >> >>> >>> I see that webrev.01 also includes the changes in NSApplicationAWT.m. Is this really necessary for that version of the fix? >>> >>> I recall in your original review request you stated that the code currently consists of multiple workarounds, and adding another one could just bring more regressions or unexpected behaviors. So I'd actually prefer the version .01. >> >> So do I. There are circumstances beyond my control that prevent me from landing the fix into JDK 8 GA. However, I still see .01 as the definitive version of the fix, and planning to include it into JDK 8 Update 1/JDK 9 (I'll file a separate bug for it). Version .02 is a not a long term solution for me. >> >> >>> >>> Anyway, here's a couple of comments regarding the new fix: >>> >>> src/macosx/native/sun/awt/AWTView.m >>>> 313 NSUInteger modFlags = [event modifierFlags] & >>>> 314 (NSCommandKeyMask | NSAlternateKeyMask | NSShiftKeyMask | NSControlKeyMask); >>>> 315 if (modFlags == NSCommandKeyMask) { >>> >>> Do I understand correctly that OS X is fine with e.g. Shift+Cmd+'+', and only Cmd+'+' is causing a problem? >> >> Yep. >> >>> >>>> 311 // Workaround for 8020209: special case for "Cmd =" and "Cmd ." >>>> 312 // because Cocoa calls performKeyEquivalent twice for these keystrokes >>> >>> Interesting that you say that Cocoa sends multiple events and I'd guess one wants to filter some events out. However, at line 320 you call performKeyEquivalent yourself. Is this like the third call or something? Or the comment seems to be misleading otherwise. >> >> Ok, looks like I need to extend the comment. Cocoa calls -performKeyEquivalent twice only if we return NO from the first -performKeyEquivalent call. Normally, what happens when performKeyEquivalent returns NO is that Cocoa calls -performKeyEquivalent for the next responder in the responders chain, until it finds the one which would return YES. "Cmd =" and "Cmd ." key strokes, however, are really unusual: if we and all other responders in the chain return NO, then Cocoa will construct another NSEvent and call -performKeyEquivalent for that event. Returning YES from the -performKeyEquivalent prevents that. However, this means that Cocoa won't call -performKeyEquivalent for the menu bar, so we have to do it manually. >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/16/2013 08:53 PM, Leonid Romanov wrote: >>>> Hello, >>>> This is plan B version of the fix for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS". The previous, proper version of the fix has been reviewed here: >>>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005441.html >>>> Unfortunately, I can't proceed with that version because there are some difficulties with submitting private JDK 8 build to Apple for approval. Since we are short on time and I want to fix this bug in JDK 8, I've had to use a workaround. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8020209 >>>> webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.02/ >>>> >>>> Thanks, >>>> Leonid. >>>> >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131021/4df7af18/attachment-0001.html From magnus.ihse.bursie at oracle.com Mon Oct 21 05:14:06 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Oct 2013 14:14:06 +0200 Subject: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated In-Reply-To: <5264E67B.80502@oracle.com> References: <5264E67B.80502@oracle.com> Message-ID: <14F64E8F-0283-4E92-A4FA-CAA0402F2DB6@oracle.com> I agree with Erik. /Magnus 21 okt 2013 kl. 10:31 skrev Erik Joelsson : > Hello David, > > From a build point of view, the changes look fine to me. > > /Erik > > On 2013-10-21 01:53, David DeHaven wrote: >> CCing: build-dev, macosx-port-dev >> >> Request for review of JDK-8016096: >> https://bugs.openjdk.java.net/browse/JDK-8016096 >> >> Proposed changes: >> http://cr.openjdk.java.net/~ddehaven/8016096/ >> >> Significant build system changes for this one so feedback from build-dev is appreciated. Actual functional changes are just ported from the JDK7 changes I made several months ago, less the X11 dependency in jawt_md.h. The autoconf changes also trigger an update of generated-configure.sh in jdk/make/closed, that will need to be pushed too. >> >> >> Please note: >> These patches will not work alone! You must also apply the patches for 8025673, which I'm also submitting for review. >> >> >> Built and tested on Mac and Linux. I'm in the process of submitting JPRT runs. >> >> -DrD- > From magnus.ihse.bursie at oracle.com Mon Oct 21 05:21:34 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Oct 2013 14:21:34 +0200 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5264E663.7050401@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <5264E663.7050401@oracle.com> Message-ID: <23EDEC19-5FF1-4D80-A196-58C915AD0484@oracle.com> I agree with Erik once more. /Magnus 21 okt 2013 kl. 10:31 skrev Erik Joelsson : > Hello David, > > From a build point of view, the changes look fine to me. > > /Erik > > On 2013-10-21 01:56, David DeHaven wrote: >> CCing: build-dev, macosx-port-dev, hotspot-dev >> >> Request for review of JDK-8025673: >> https://bugs.openjdk.java.net/browse/JDK-8025673 >> >> Proposed changes: >> http://cr.openjdk.java.net/~ddehaven/8025673/ >> >> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >> >> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >> >> Significant build system changes, build-dev guys are encouraged to comment... >> >> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >> >> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >> >> >> Question for the AWT team, we still have this in java_props_md.c: >> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >> 459 if (prefToolkit == CToolkit) { >> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >> 461 } else { >> 462 // TODO: do we still need this? >> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >> 464 } >> >> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >> >> >> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >> >> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >> >> -DrD- > From Sergey.Bylokhov at oracle.com Mon Oct 21 05:36:23 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 Oct 2013 16:36:23 +0400 Subject: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" (plan B) In-Reply-To: References: <74C28886-331D-4199-947E-9E2747E86AC1@oracle.com> <525ECEDE.10503@oracle.com> <3DC9E5AA-4E33-4E5F-BA97-862514346C10@oracle.com> <526022E6.20806@oracle.com> Message-ID: <52651FC7.2080600@oracle.com> Hi, Leonid. Thie fix looks good. Let's hope that in this area we will have no more bugs. On 21.10.2013 15:26, Leonid Romanov wrote: > Here is an updated version of the fix with the expanded comment: > > http://cr.openjdk.java.net/~leonidr/8020209/webrev.03/ > > > On 17.10.2013, at 21:48, Anthony Petrov > wrote: > >> Thanks for the clarifications. They sound good to me. >> >> Regarding NSApp instance, your understanding is correct. Although I'm >> not sure if this is a good idea to tell embedders to fix their code >> in this case. But I'm sort of OK with the current approach for now. >> >> So, I'd like to see the final version of the fix with an updated >> comment, and then I approve it. >> >> -- >> best regards, >> Anthony >> >> On 10/16/2013 11:19 PM, Leonid Romanov wrote: >>> >>> On Oct 16, 2013, at 9:37 PM, Anthony Petrov >>> > wrote: >>> >>>> Hi Leonid, >>>> >>>> The problem with overriding NSApplication -sendEvent: is that you >>>> can't be sure AWT is running with the NSApplicationAWT instance. If >>>> using SWT, FX, or otherwise embedding AWT into another application, >>>> the NSApp will point to an instance of another application class, >>>> and your sendEvent: will never be called. I'd suggest to avoid >>>> using this method altogether if possible. >>> >>> Do I understand you correctly that in case of AWT embedding NSApp >>> could be some NSApplication subclass other than NSApplicationAWT? If >>> so, then this hypothetical subclass might have the very same code >>> I've added to NSApplicationAWT since it's the most common approach >>> for solving the problem of missing NSKeyUp events. In this case, our >>> attempt to solve it in some other way will only make things worse: >>> we might end up with duplicate NSKeyUp events. >>> So, my suggestions is to leave that code as it is and if embedders >>> complain about aforementioned problem, tell them to fix it on theirs >>> app level, as we've done it in our NSApplicationAWT. >>> >>>> >>>> I see that webrev.01 also includes the changes in >>>> NSApplicationAWT.m. Is this really necessary for that version of >>>> the fix? >>>> >>>> I recall in your original review request you stated that the code >>>> currently consists of multiple workarounds, and adding another one >>>> could just bring more regressions or unexpected behaviors. So I'd >>>> actually prefer the version .01. >>> >>> So do I. There are circumstances beyond my control that prevent me >>> from landing the fix into JDK 8 GA. However, I still see .01 as the >>> definitive version of the fix, and planning to include it into JDK 8 >>> Update 1/JDK 9 (I'll file a separate bug for it). Version .02 is a >>> not a long term solution for me. >>> >>> >>>> >>>> Anyway, here's a couple of comments regarding the new fix: >>>> >>>> src/macosx/native/sun/awt/AWTView.m >>>>> 313 NSUInteger modFlags = [event modifierFlags] & >>>>> 314 (NSCommandKeyMask | NSAlternateKeyMask | >>>>> NSShiftKeyMask | NSControlKeyMask); >>>>> 315 if (modFlags == NSCommandKeyMask) { >>>> >>>> Do I understand correctly that OS X is fine with e.g. >>>> Shift+Cmd+'+', and only Cmd+'+' is causing a problem? >>> >>> Yep. >>> >>>> >>>>> 311 // Workaround for 8020209: special case for "Cmd =" and >>>>> "Cmd ." >>>>> 312 // because Cocoa calls performKeyEquivalent twice for >>>>> these keystrokes >>>> >>>> Interesting that you say that Cocoa sends multiple events and I'd >>>> guess one wants to filter some events out. However, at line 320 you >>>> call performKeyEquivalent yourself. Is this like the third call or >>>> something? Or the comment seems to be misleading otherwise. >>> >>> Ok, looks like I need to extend the comment. Cocoa calls >>> -performKeyEquivalent twice only if we return NO from the first >>> -performKeyEquivalent call. Normally, what happens when >>> performKeyEquivalent returns NO is that Cocoa calls >>> -performKeyEquivalent for the next responder in the responders >>> chain, until it finds the one which would return YES. "Cmd =" and >>> "Cmd ." key strokes, however, are really unusual: if we and all >>> other responders in the chain return NO, then Cocoa will construct >>> another NSEvent and call -performKeyEquivalent for that event. >>> Returning YES from the -performKeyEquivalent prevents that. However, >>> this means that Cocoa won't call -performKeyEquivalent for the menu >>> bar, so we have to do it manually. >>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/16/2013 08:53 PM, Leonid Romanov wrote: >>>>> Hello, >>>>> This is plan B version of the fix for JDK-8020209: [macosx] Mac OS >>>>> X key event confusion for "COMMAND PLUS". The previous, proper >>>>> version of the fix has been reviewed here: >>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005441.html >>>>> Unfortunately, I can't proceed with that version because there are >>>>> some difficulties with submitting private JDK 8 build to Apple for >>>>> approval. Since we are short on time and I want to fix this bug >>>>> in JDK 8, I've had to use a workaround. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8020209 >>>>> webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.02/ >>>>> >>>>> Thanks, >>>>> Leonid. >>>>> >>>>> >>>>> >>> > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131021/ac9f02c6/attachment.html From Sergey.Bylokhov at oracle.com Mon Oct 21 05:53:41 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 Oct 2013 16:53:41 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError In-Reply-To: <52611FB9.9080605@oracle.com> References: <525E9BF6.9040602@oracle.com> <526118D7.8040106@oracle.com> <52611FB9.9080605@oracle.com> Message-ID: <526523D5.4090207@oracle.com> Hi, Anthony. Since cr have some issues with the space. I upload 2 files, where handleExposeEvent was renamed to postPaintEvent(): http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XWindow.java.sdiff.html http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XContentWindow.java.sdiff.html On 18.10.2013 15:47, Sergey Bylokhov wrote: > Hi, Anthony. > On 18.10.2013 15:17, Anthony Petrov wrote: >> Hi Sergey, >> >> In XAWT, we usually use the StateLock to synchronize access to peer >> fields (such as background, label, etc.) I don't think that switching >> to volatile is a good idea since it prevents us from performing >> atomic read/writes to the fields. And this is exactly what we need >> for this fix, actually. In other words, the following pattern works >> perfectly: >> >> synchronized (lock) { >> if (a != b) { >> a = b; >> // do stuff, or set a flag to do it later w/o the lock >> } >> } >> >> whereas the following doesn't: >> >> volatile a; >> if (a != b) { >> a = b; >> // do stuff >> } >> >> The latter doesn't work because the value of 'a' may change from >> another thread after the if() statement in the first thread is executed. > If it will be changed that's ok. It is safe in this context since > there is no races. a will be the latest setted value and repaint > action will be done after a was set. Non trivial setters(like > setLabel/setText) are called under the locks in shared code. >> >> Please note that this is critical for AWT because it is a >> multi-threaded GUI toolkit. >> >> src/solaris/classes/sun/awt/X11/XListPeer.java >>> - target.paint(g); >>> + handleExposeEvent(target, 0, 0, getWidth(), >>> getHeight()); >> >> (the same applies to XWindow.repaint): can you please rename >> XWindow.handleExposeEvent(Component...) to postPaintEvent() and make >> it final? A good javadoc for this method would also be appreciated, >> because currently seeing the name handle*() I'd think it needs to be >> done under the awtLock(). > Will do. >> >> Also, for the corresponding changes in XWindow.repaint(), could you >> please elaborate a bit more? Looking at the code I see that >> XWindow.paint() calls paintPeer(). And in repaint(), you either call >> paint() or paintPeer() depending on the current thread. Why is it >> needed? Can we just call paintPeer() (or paint() for that matter) >> unconditionally since they both seem to result in the same call? > paintPeer is used to draw the native part of the peer(text of the > label, border of the button etc). > paint is a part of Component.paintAll(). And as a result of it call it > should paint the native part of the peer and it should call > appropriate paint method from the target. >> Also, why don't we post an event if reapint() is invoked on the EDT? > We do this in osx, but in xawt there are "smart" caches, which are > initialized during the paint of the peer. See > XLabelPeer&cachedFontMetrics for example . Note that this cache is > completely broken. >> >> -- >> best regards, >> Anthony >> >> On 10/16/2013 06:00 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk 8. >>> The fix has two parts >>> - Repaint method in the peer now paint the component in place if it >>> was called on EDT only. >>> - Most of setters were changed to stop recursion if they were called >>> on EDT. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-7090424 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7090424/webrev.00 >>> > > -- Best regards, Sergey. From anthony.petrov at oracle.com Mon Oct 21 10:09:40 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 21 Oct 2013 17:09:40 +0000 Subject: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" (plan B) In-Reply-To: <52651FC7.2080600@oracle.com> References: <74C28886-331D-4199-947E-9E2747E86AC1@oracle.com> <525ECEDE.10503@oracle.com> <3DC9E5AA-4E33-4E5F-BA97-862514346C10@oracle.com> <526022E6.20806@oracle.com> <52651FC7.2080600@oracle.com> Message-ID: <52655FD4.3060109@oracle.com> +1 -- best regards, Anthony On 10/21/2013 12:36 PM, Sergey Bylokhov wrote: > Hi, Leonid. > Thie fix looks good. Let's hope that in this area we will have no more bugs. > > On 21.10.2013 15:26, Leonid Romanov wrote: >> Here is an updated version of the fix with the expanded comment: >> >> http://cr.openjdk.java.net/~leonidr/8020209/webrev.03/ >> >> >> On 17.10.2013, at 21:48, Anthony Petrov > > wrote: >> >>> Thanks for the clarifications. They sound good to me. >>> >>> Regarding NSApp instance, your understanding is correct. Although I'm >>> not sure if this is a good idea to tell embedders to fix their code >>> in this case. But I'm sort of OK with the current approach for now. >>> >>> So, I'd like to see the final version of the fix with an updated >>> comment, and then I approve it. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/16/2013 11:19 PM, Leonid Romanov wrote: >>>> >>>> On Oct 16, 2013, at 9:37 PM, Anthony Petrov >>>> > wrote: >>>> >>>>> Hi Leonid, >>>>> >>>>> The problem with overriding NSApplication -sendEvent: is that you >>>>> can't be sure AWT is running with the NSApplicationAWT instance. If >>>>> using SWT, FX, or otherwise embedding AWT into another application, >>>>> the NSApp will point to an instance of another application class, >>>>> and your sendEvent: will never be called. I'd suggest to avoid >>>>> using this method altogether if possible. >>>> >>>> Do I understand you correctly that in case of AWT embedding NSApp >>>> could be some NSApplication subclass other than NSApplicationAWT? If >>>> so, then this hypothetical subclass might have the very same code >>>> I've added to NSApplicationAWT since it's the most common approach >>>> for solving the problem of missing NSKeyUp events. In this case, our >>>> attempt to solve it in some other way will only make things worse: >>>> we might end up with duplicate NSKeyUp events. >>>> So, my suggestions is to leave that code as it is and if embedders >>>> complain about aforementioned problem, tell them to fix it on theirs >>>> app level, as we've done it in our NSApplicationAWT. >>>> >>>>> >>>>> I see that webrev.01 also includes the changes in >>>>> NSApplicationAWT.m. Is this really necessary for that version of >>>>> the fix? >>>>> >>>>> I recall in your original review request you stated that the code >>>>> currently consists of multiple workarounds, and adding another one >>>>> could just bring more regressions or unexpected behaviors. So I'd >>>>> actually prefer the version .01. >>>> >>>> So do I. There are circumstances beyond my control that prevent me >>>> from landing the fix into JDK 8 GA. However, I still see .01 as the >>>> definitive version of the fix, and planning to include it into JDK 8 >>>> Update 1/JDK 9 (I'll file a separate bug for it). Version .02 is a >>>> not a long term solution for me. >>>> >>>> >>>>> >>>>> Anyway, here's a couple of comments regarding the new fix: >>>>> >>>>> src/macosx/native/sun/awt/AWTView.m >>>>>> 313 NSUInteger modFlags = [event modifierFlags] & >>>>>> 314 (NSCommandKeyMask | NSAlternateKeyMask | >>>>>> NSShiftKeyMask | NSControlKeyMask); >>>>>> 315 if (modFlags == NSCommandKeyMask) { >>>>> >>>>> Do I understand correctly that OS X is fine with e.g. >>>>> Shift+Cmd+'+', and only Cmd+'+' is causing a problem? >>>> >>>> Yep. >>>> >>>>> >>>>>> 311 // Workaround for 8020209: special case for "Cmd =" and >>>>>> "Cmd ." >>>>>> 312 // because Cocoa calls performKeyEquivalent twice for >>>>>> these keystrokes >>>>> >>>>> Interesting that you say that Cocoa sends multiple events and I'd >>>>> guess one wants to filter some events out. However, at line 320 you >>>>> call performKeyEquivalent yourself. Is this like the third call or >>>>> something? Or the comment seems to be misleading otherwise. >>>> >>>> Ok, looks like I need to extend the comment. Cocoa calls >>>> -performKeyEquivalent twice only if we return NO from the first >>>> -performKeyEquivalent call. Normally, what happens when >>>> performKeyEquivalent returns NO is that Cocoa calls >>>> -performKeyEquivalent for the next responder in the responders >>>> chain, until it finds the one which would return YES. "Cmd =" and >>>> "Cmd ." key strokes, however, are really unusual: if we and all >>>> other responders in the chain return NO, then Cocoa will construct >>>> another NSEvent and call -performKeyEquivalent for that event. >>>> Returning YES from the -performKeyEquivalent prevents that. However, >>>> this means that Cocoa won't call -performKeyEquivalent for the menu >>>> bar, so we have to do it manually. >>>> >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 10/16/2013 08:53 PM, Leonid Romanov wrote: >>>>>> Hello, >>>>>> This is plan B version of the fix for JDK-8020209: [macosx] Mac OS >>>>>> X key event confusion for "COMMAND PLUS". The previous, proper >>>>>> version of the fix has been reviewed here: >>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005441.html >>>>>> Unfortunately, I can't proceed with that version because there are >>>>>> some difficulties with submitting private JDK 8 build to Apple for >>>>>> approval. Since we are short on time and I want to fix this bug >>>>>> in JDK 8, I've had to use a workaround. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8020209 >>>>>> webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> Leonid. >>>>>> >>>>>> >>>>>> >>>> >> > > > -- > Best regards, Sergey. > From anthony.petrov at oracle.com Mon Oct 21 11:13:36 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 21 Oct 2013 18:13:36 +0000 Subject: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated In-Reply-To: References: Message-ID: <52656ED0.8010200@oracle.com> Hi David, The fix looks fine to me. -- best regards, Anthony On 10/20/2013 11:53 PM, David DeHaven wrote: > > CCing: build-dev, macosx-port-dev > > Request for review of JDK-8016096: > https://bugs.openjdk.java.net/browse/JDK-8016096 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8016096/ > > Significant build system changes for this one so feedback from build-dev is appreciated. Actual functional changes are just ported from the JDK7 changes I made several months ago, less the X11 dependency in jawt_md.h. The autoconf changes also trigger an update of generated-configure.sh in jdk/make/closed, that will need to be pushed too. > > > Please note: > These patches will not work alone! You must also apply the patches for 8025673, which I'm also submitting for review. > > > Built and tested on Mac and Linux. I'm in the process of submitting JPRT runs. > > -DrD- > From anthony.petrov at oracle.com Mon Oct 21 11:22:19 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 21 Oct 2013 18:22:19 +0000 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> Message-ID: <526570DB.9070509@oracle.com> This fix looks fine to me as well. -- best regards, Anthony On 10/20/2013 11:56 PM, David DeHaven wrote: > > CCing: build-dev, macosx-port-dev, hotspot-dev > > Request for review of JDK-8025673: > https://bugs.openjdk.java.net/browse/JDK-8025673 > > Proposed changes: > http://cr.openjdk.java.net/~ddehaven/8025673/ > > This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). > > A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. > > Significant build system changes, build-dev guys are encouraged to comment... > > I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. > > The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. > > > Question for the AWT team, we still have this in java_props_md.c: > 458 PreferredToolkit prefToolkit = getPreferredToolkit(); > 459 if (prefToolkit == CToolkit) { > 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; > 461 } else { > 462 // TODO: do we still need this? > 463 sprops.awt_toolkit = "sun.awt.HToolkit"; > 464 } > > Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. > > > I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. > > JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. > > -DrD- > From david.dehaven at oracle.com Mon Oct 21 08:58:36 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 21 Oct 2013 08:58:36 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <526570DB.9070509@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> Message-ID: <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Thanks guys. Anthony, can you sponsor this for me? -DrD- > This fix looks fine to me as well. > > -- > best regards, > Anthony > > On 10/20/2013 11:56 PM, David DeHaven wrote: >> >> CCing: build-dev, macosx-port-dev, hotspot-dev >> >> Request for review of JDK-8025673: >> https://bugs.openjdk.java.net/browse/JDK-8025673 >> >> Proposed changes: >> http://cr.openjdk.java.net/~ddehaven/8025673/ >> >> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >> >> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >> >> Significant build system changes, build-dev guys are encouraged to comment... >> >> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >> >> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >> >> >> Question for the AWT team, we still have this in java_props_md.c: >> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >> 459 if (prefToolkit == CToolkit) { >> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >> 461 } else { >> 462 // TODO: do we still need this? >> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >> 464 } >> >> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >> >> >> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >> >> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >> >> -DrD- >> From david.dehaven at oracle.com Mon Oct 21 12:54:17 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 21 Oct 2013 12:54:17 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Message-ID: I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. -DrD- > Thanks guys. > > Anthony, can you sponsor this for me? > > -DrD- > >> This fix looks fine to me as well. >> >> -- >> best regards, >> Anthony >> >> On 10/20/2013 11:56 PM, David DeHaven wrote: >>> >>> CCing: build-dev, macosx-port-dev, hotspot-dev >>> >>> Request for review of JDK-8025673: >>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>> >>> Proposed changes: >>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>> >>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>> >>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>> >>> Significant build system changes, build-dev guys are encouraged to comment... >>> >>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>> >>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>> >>> >>> Question for the AWT team, we still have this in java_props_md.c: >>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>> 459 if (prefToolkit == CToolkit) { >>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>> 461 } else { >>> 462 // TODO: do we still need this? >>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>> 464 } >>> >>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>> >>> >>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>> >>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>> >>> -DrD- >>> > From david.dehaven at oracle.com Mon Oct 21 20:34:30 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 21 Oct 2013 20:34:30 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Message-ID: Updated webrev for JDK (hotspot change is the same): http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ Changes since last version: - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] -DrD- > I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. > > -DrD- > >> Thanks guys. >> >> Anthony, can you sponsor this for me? >> >> -DrD- >> >>> This fix looks fine to me as well. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>> >>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>> >>>> Request for review of JDK-8025673: >>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>> >>>> Proposed changes: >>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>> >>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>> >>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>> >>>> Significant build system changes, build-dev guys are encouraged to comment... >>>> >>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>> >>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>> >>>> >>>> Question for the AWT team, we still have this in java_props_md.c: >>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>> 459 if (prefToolkit == CToolkit) { >>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>> 461 } else { >>>> 462 // TODO: do we still need this? >>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>> 464 } >>>> >>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>> >>>> >>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>> >>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>> >>>> -DrD- >>>> >> > From Sergey.Bylokhov at oracle.com Tue Oct 22 01:28:31 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Oct 2013 12:28:31 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError In-Reply-To: <526523D5.4090207@oracle.com> References: <525E9BF6.9040602@oracle.com> <526118D7.8040106@oracle.com> <52611FB9.9080605@oracle.com> <526523D5.4090207@oracle.com> Message-ID: <5266372F.1080104@oracle.com> I have a problem with the review tool. I assume that version .00 with removed volatiles and renamed handleexpose event is ok for everybody? On 10/21/13 4:53 PM, Sergey Bylokhov wrote: > Hi, Anthony. > Since cr have some issues with the space. I upload 2 files, where > handleExposeEvent was renamed to postPaintEvent(): > > http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XWindow.java.sdiff.html > > http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XContentWindow.java.sdiff.html > > > On 18.10.2013 15:47, Sergey Bylokhov wrote: >> Hi, Anthony. >> On 18.10.2013 15:17, Anthony Petrov wrote: >>> Hi Sergey, >>> >>> In XAWT, we usually use the StateLock to synchronize access to peer >>> fields (such as background, label, etc.) I don't think that >>> switching to volatile is a good idea since it prevents us from >>> performing atomic read/writes to the fields. And this is exactly >>> what we need for this fix, actually. In other words, the following >>> pattern works perfectly: >>> >>> synchronized (lock) { >>> if (a != b) { >>> a = b; >>> // do stuff, or set a flag to do it later w/o the lock >>> } >>> } >>> >>> whereas the following doesn't: >>> >>> volatile a; >>> if (a != b) { >>> a = b; >>> // do stuff >>> } >>> >>> The latter doesn't work because the value of 'a' may change from >>> another thread after the if() statement in the first thread is >>> executed. >> If it will be changed that's ok. It is safe in this context since >> there is no races. a will be the latest setted value and repaint >> action will be done after a was set. Non trivial setters(like >> setLabel/setText) are called under the locks in shared code. >>> >>> Please note that this is critical for AWT because it is a >>> multi-threaded GUI toolkit. >>> >>> src/solaris/classes/sun/awt/X11/XListPeer.java >>>> - target.paint(g); >>>> + handleExposeEvent(target, 0, 0, getWidth(), >>>> getHeight()); >>> >>> (the same applies to XWindow.repaint): can you please rename >>> XWindow.handleExposeEvent(Component...) to postPaintEvent() and make >>> it final? A good javadoc for this method would also be appreciated, >>> because currently seeing the name handle*() I'd think it needs to be >>> done under the awtLock(). >> Will do. >>> >>> Also, for the corresponding changes in XWindow.repaint(), could you >>> please elaborate a bit more? Looking at the code I see that >>> XWindow.paint() calls paintPeer(). And in repaint(), you either call >>> paint() or paintPeer() depending on the current thread. Why is it >>> needed? Can we just call paintPeer() (or paint() for that matter) >>> unconditionally since they both seem to result in the same call? >> paintPeer is used to draw the native part of the peer(text of the >> label, border of the button etc). >> paint is a part of Component.paintAll(). And as a result of it call >> it should paint the native part of the peer and it should call >> appropriate paint method from the target. >>> Also, why don't we post an event if reapint() is invoked on the EDT? >> We do this in osx, but in xawt there are "smart" caches, which are >> initialized during the paint of the peer. See >> XLabelPeer&cachedFontMetrics for example . Note that this cache is >> completely broken. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/16/2013 06:00 PM, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for jdk 8. >>>> The fix has two parts >>>> - Repaint method in the peer now paint the component in place if it >>>> was called on EDT only. >>>> - Most of setters were changed to stop recursion if they were called >>>> on EDT. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7090424 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7090424/webrev.00 >>>> >> >> > > -- Best regards, Sergey. From erik.joelsson at oracle.com Tue Oct 22 02:13:00 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Oct 2013 11:13:00 +0200 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Message-ID: <5266419C.5090705@oracle.com> Still looks good to me. /Erik On 2013-10-22 05:34, David DeHaven wrote: > Updated webrev for JDK (hotspot change is the same): > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ > > Changes since last version: > - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk > - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] > > -DrD- > > >> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >> >> -DrD- >> >>> Thanks guys. >>> >>> Anthony, can you sponsor this for me? >>> >>> -DrD- >>> >>>> This fix looks fine to me as well. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>> >>>>> Request for review of JDK-8025673: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>> >>>>> Proposed changes: >>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>> >>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>> >>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>> >>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>> >>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>> >>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>> >>>>> >>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>> 459 if (prefToolkit == CToolkit) { >>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>> 461 } else { >>>>> 462 // TODO: do we still need this? >>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>> 464 } >>>>> >>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>> >>>>> >>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>> >>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>> >>>>> -DrD- >>>>> From artem.ananiev at oracle.com Tue Oct 22 02:23:49 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 22 Oct 2013 13:23:49 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> Message-ID: <52664425.4080201@oracle.com> Hi, David, thanks for additional cleanup. I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? Thanks, Artem On 10/22/2013 7:34 AM, David DeHaven wrote: > > Updated webrev for JDK (hotspot change is the same): > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ > > Changes since last version: > - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk > - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] > > -DrD- > > >> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >> >> -DrD- >> >>> Thanks guys. >>> >>> Anthony, can you sponsor this for me? >>> >>> -DrD- >>> >>>> This fix looks fine to me as well. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>> >>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>> >>>>> Request for review of JDK-8025673: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>> >>>>> Proposed changes: >>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>> >>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>> >>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>> >>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>> >>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>> >>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>> >>>>> >>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>> 459 if (prefToolkit == CToolkit) { >>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>> 461 } else { >>>>> 462 // TODO: do we still need this? >>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>> 464 } >>>>> >>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>> >>>>> >>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>> >>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>> >>>>> -DrD- >>>>> >>> >> > From alexandr.scherbatiy at oracle.com Tue Oct 22 02:31:51 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 22 Oct 2013 13:31:51 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays Message-ID: <52664607.2090807@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8011059 webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 The IMAGE_SCALING rendering hint is added to the RenderingHints class. Enabling the image scaling rendering hint forces the SunGraphics2D to use getScaledInstance(width, height, hints) method from Image class with SCALE_DEFAULT hint. By default the image scaling rendering hint is enabled on HiDPI display and disabled for standard displays. User can override the getScaledInstance(width, height, hints) method and return necessary high resolution image according to the given image width and height. For example: --------------------- final Image highResolutionImage = new BufferedImage(2 * WIDTH, 2 * HEIGHT, BufferedImage.TYPE_INT_RGB); Image image = new BufferedImage(WIDTH, HEIGHT, BufferedImage.TYPE_INT_RGB) { @Override public Image getScaledInstance(int width, int height, int hints) { if ((hints & Image.SCALE_DEFAULT) != 0) { return (width <= WIDTH && height <= HEIGHT) ? this : highResolutionImage; } return super.getScaledInstance(width, height, hints); } }; --------------------- The LWCToolkit and ToolkitImage classes are patched to automatically get provided image at 2x.ext images on MacOSX. There are no significant changes in the Java2D demo to make it look perfect on Retina displays. It needs only to put necessary images with the @2x postfix and they will be automatically drawn. Thanks, Alexandr. From anthony.petrov at oracle.com Tue Oct 22 02:52:53 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Oct 2013 13:52:53 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError In-Reply-To: <5266372F.1080104@oracle.com> References: <525E9BF6.9040602@oracle.com> <526118D7.8040106@oracle.com> <52611FB9.9080605@oracle.com> <526523D5.4090207@oracle.com> <5266372F.1080104@oracle.com> Message-ID: <52664AF5.9090105@oracle.com> Hi Sergey, Sorry, but I can't review a fix w/o a webrev. What kind of problems do you experience with the tool? The cr.openjdk should now have enough free space to host new webrevs. Please try to re-upload the new webrev. -- best regards, Anthony On 10/22/2013 12:28 PM, Sergey Bylokhov wrote: > I have a problem with the review tool. I assume that version .00 with > removed volatiles and renamed handleexpose event is ok for everybody? > > On 10/21/13 4:53 PM, Sergey Bylokhov wrote: >> Hi, Anthony. >> Since cr have some issues with the space. I upload 2 files, where >> handleExposeEvent was renamed to postPaintEvent(): >> >> http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XWindow.java.sdiff.html >> >> http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XContentWindow.java.sdiff.html >> >> >> On 18.10.2013 15:47, Sergey Bylokhov wrote: >>> Hi, Anthony. >>> On 18.10.2013 15:17, Anthony Petrov wrote: >>>> Hi Sergey, >>>> >>>> In XAWT, we usually use the StateLock to synchronize access to peer >>>> fields (such as background, label, etc.) I don't think that >>>> switching to volatile is a good idea since it prevents us from >>>> performing atomic read/writes to the fields. And this is exactly >>>> what we need for this fix, actually. In other words, the following >>>> pattern works perfectly: >>>> >>>> synchronized (lock) { >>>> if (a != b) { >>>> a = b; >>>> // do stuff, or set a flag to do it later w/o the lock >>>> } >>>> } >>>> >>>> whereas the following doesn't: >>>> >>>> volatile a; >>>> if (a != b) { >>>> a = b; >>>> // do stuff >>>> } >>>> >>>> The latter doesn't work because the value of 'a' may change from >>>> another thread after the if() statement in the first thread is >>>> executed. >>> If it will be changed that's ok. It is safe in this context since >>> there is no races. a will be the latest setted value and repaint >>> action will be done after a was set. Non trivial setters(like >>> setLabel/setText) are called under the locks in shared code. >>>> >>>> Please note that this is critical for AWT because it is a >>>> multi-threaded GUI toolkit. >>>> >>>> src/solaris/classes/sun/awt/X11/XListPeer.java >>>>> - target.paint(g); >>>>> + handleExposeEvent(target, 0, 0, getWidth(), >>>>> getHeight()); >>>> >>>> (the same applies to XWindow.repaint): can you please rename >>>> XWindow.handleExposeEvent(Component...) to postPaintEvent() and make >>>> it final? A good javadoc for this method would also be appreciated, >>>> because currently seeing the name handle*() I'd think it needs to be >>>> done under the awtLock(). >>> Will do. >>>> >>>> Also, for the corresponding changes in XWindow.repaint(), could you >>>> please elaborate a bit more? Looking at the code I see that >>>> XWindow.paint() calls paintPeer(). And in repaint(), you either call >>>> paint() or paintPeer() depending on the current thread. Why is it >>>> needed? Can we just call paintPeer() (or paint() for that matter) >>>> unconditionally since they both seem to result in the same call? >>> paintPeer is used to draw the native part of the peer(text of the >>> label, border of the button etc). >>> paint is a part of Component.paintAll(). And as a result of it call >>> it should paint the native part of the peer and it should call >>> appropriate paint method from the target. >>>> Also, why don't we post an event if reapint() is invoked on the EDT? >>> We do this in osx, but in xawt there are "smart" caches, which are >>> initialized during the paint of the peer. See >>> XLabelPeer&cachedFontMetrics for example . Note that this cache is >>> completely broken. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/16/2013 06:00 PM, Sergey Bylokhov wrote: >>>>> Hello. >>>>> Please review the fix for jdk 8. >>>>> The fix has two parts >>>>> - Repaint method in the peer now paint the component in place if it >>>>> was called on EDT only. >>>>> - Most of setters were changed to stop recursion if they were called >>>>> on EDT. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7090424 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/7090424/webrev.00 >>>>> >>> >>> >> >> > > From anthony.petrov at oracle.com Tue Oct 22 03:16:07 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Oct 2013 14:16:07 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <52664425.4080201@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> Message-ID: <52665067.40102@oracle.com> Artem is correct. On Mac we can't start a GUI session via ssh, for example. Thus we choose the headless mode then. The isInAquaSession() is supposed to perform exactly this check. This logic needs to be preserved. -- best regards, Anthony On 10/22/2013 01:23 PM, Artem Ananiev wrote: > Hi, David, > > thanks for additional cleanup. > > I have only one concern. Before the fix, we checked if there is an > active Aqua session. When no session was found, we falled back to > HToolkit. I think this logic should be preserved, but slightly > corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). > > Otherwise the only way to run headless on Mac will be to force it with > the system property. It works this way on Windows, but on Windows we're > sure that WToolkit can run even without a UI session. Is it also true on > Mac? Did you try to launch AWT without -Djava.awt.headless=true from > remote console with no users logged in? > > Thanks, > > Artem > > On 10/22/2013 7:34 AM, David DeHaven wrote: >> >> Updated webrev for JDK (hotspot change is the same): >> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >> >> Changes since last version: >> - Moved to jdk8/build/jdk to save someone a merge headache, moved >> changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >> - Removed HToolkit option and toolkit selection code from >> java_props_macosx.[ch] >> >> -DrD- >> >> >>> I want to do one more iteration of this. Based on feedback it seems I >>> can remove a bit more code from java_props_macosx.[ch] and make >>> things a bit cleaner. >>> >>> -DrD- >>> >>>> Thanks guys. >>>> >>>> Anthony, can you sponsor this for me? >>>> >>>> -DrD- >>>> >>>>> This fix looks fine to me as well. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>> >>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>> >>>>>> Request for review of JDK-8025673: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>> >>>>>> Proposed changes: >>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>> >>>>>> This change disables building libawt_xawt.dylib and >>>>>> libawt_headless.dylib on Mac since they are not used and not >>>>>> supported. There are too many challenges (and not enough time) in >>>>>> removing all X11 code from the Mac build at this time, so we're >>>>>> deferring complete removal for later (will be covered by >>>>>> JDK-8003900). >>>>>> >>>>>> A small change to hotspot is required as it was looking for >>>>>> libawt_xawt.dylib and if not found would set java.awt.headless to >>>>>> true. Since we don't build a headless only JRE on Mac I just have >>>>>> that method return false. I'm not sure how to handle changes to >>>>>> hotspot, can it be pushed along with the jdk changes? Without that >>>>>> change the Mac builds will be broken. >>>>>> >>>>>> Significant build system changes, build-dev guys are encouraged to >>>>>> comment... >>>>>> >>>>>> I tried excluding all sun/awt/X11 classes in >>>>>> CompileJavaClasses.gmk but that broke JNI header generation on >>>>>> platforms still using X11 and I couldn't use the big list of >>>>>> excluded files on Mac as that resulted in Java compilation errors, >>>>>> so I just added some logic to exclude everything on Mac and left >>>>>> the list in place everywhere else. >>>>>> >>>>>> The changes to CompileNativeLibraries.gmk will port to >>>>>> libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a >>>>>> problem in the jdk8/build workspace where the build cannot find >>>>>> symbols in JNI libs so that issue needs to be resolved first. I've >>>>>> not had time to investigate that problem. >>>>>> >>>>>> >>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>> 459 if (prefToolkit == CToolkit) { >>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>> 461 } else { >>>>>> 462 // TODO: do we still need this? >>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>> 464 } >>>>>> >>>>>> Is that necessary? Since we're now using libawt_lwawt in both >>>>>> headless and headful modes I would think we could remove the >>>>>> HToolkit option, but I'm not 100% certain about that. >>>>>> >>>>>> >>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and >>>>>> both seem to be working fine. >>>>>> >>>>>> JPRT run for Mac is in progress, I will submit one for all other >>>>>> platforms when it finishes building. >>>>>> >>>>>> -DrD- >>>>>> >>>> >>> >> From Sergey.Bylokhov at oracle.com Tue Oct 22 04:19:21 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Oct 2013 15:19:21 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError In-Reply-To: <52664AF5.9090105@oracle.com> References: <525E9BF6.9040602@oracle.com> <526118D7.8040106@oracle.com> <52611FB9.9080605@oracle.com> <526523D5.4090207@oracle.com> <5266372F.1080104@oracle.com> <52664AF5.9090105@oracle.com> Message-ID: <52665F39.1030102@oracle.com> New version here: http://cr.openjdk.java.net/~serb/7090424/webrev.02/ On 22.10.2013 13:52, Anthony Petrov wrote: > Hi Sergey, > > Sorry, but I can't review a fix w/o a webrev. > > What kind of problems do you experience with the tool? The cr.openjdk > should now have enough free space to host new webrevs. Please try to > re-upload the new webrev. > > -- > best regards, > Anthony > > On 10/22/2013 12:28 PM, Sergey Bylokhov wrote: >> I have a problem with the review tool. I assume that version .00 with >> removed volatiles and renamed handleexpose event is ok for everybody? >> >> On 10/21/13 4:53 PM, Sergey Bylokhov wrote: >>> Hi, Anthony. >>> Since cr have some issues with the space. I upload 2 files, where >>> handleExposeEvent was renamed to postPaintEvent(): >>> >>> http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XWindow.java.sdiff.html >>> >>> >>> http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XContentWindow.java.sdiff.html >>> >>> >>> >>> On 18.10.2013 15:47, Sergey Bylokhov wrote: >>>> Hi, Anthony. >>>> On 18.10.2013 15:17, Anthony Petrov wrote: >>>>> Hi Sergey, >>>>> >>>>> In XAWT, we usually use the StateLock to synchronize access to peer >>>>> fields (such as background, label, etc.) I don't think that >>>>> switching to volatile is a good idea since it prevents us from >>>>> performing atomic read/writes to the fields. And this is exactly >>>>> what we need for this fix, actually. In other words, the following >>>>> pattern works perfectly: >>>>> >>>>> synchronized (lock) { >>>>> if (a != b) { >>>>> a = b; >>>>> // do stuff, or set a flag to do it later w/o the lock >>>>> } >>>>> } >>>>> >>>>> whereas the following doesn't: >>>>> >>>>> volatile a; >>>>> if (a != b) { >>>>> a = b; >>>>> // do stuff >>>>> } >>>>> >>>>> The latter doesn't work because the value of 'a' may change from >>>>> another thread after the if() statement in the first thread is >>>>> executed. >>>> If it will be changed that's ok. It is safe in this context since >>>> there is no races. a will be the latest setted value and repaint >>>> action will be done after a was set. Non trivial setters(like >>>> setLabel/setText) are called under the locks in shared code. >>>>> >>>>> Please note that this is critical for AWT because it is a >>>>> multi-threaded GUI toolkit. >>>>> >>>>> src/solaris/classes/sun/awt/X11/XListPeer.java >>>>>> - target.paint(g); >>>>>> + handleExposeEvent(target, 0, 0, getWidth(), >>>>>> getHeight()); >>>>> >>>>> (the same applies to XWindow.repaint): can you please rename >>>>> XWindow.handleExposeEvent(Component...) to postPaintEvent() and make >>>>> it final? A good javadoc for this method would also be appreciated, >>>>> because currently seeing the name handle*() I'd think it needs to be >>>>> done under the awtLock(). >>>> Will do. >>>>> >>>>> Also, for the corresponding changes in XWindow.repaint(), could you >>>>> please elaborate a bit more? Looking at the code I see that >>>>> XWindow.paint() calls paintPeer(). And in repaint(), you either call >>>>> paint() or paintPeer() depending on the current thread. Why is it >>>>> needed? Can we just call paintPeer() (or paint() for that matter) >>>>> unconditionally since they both seem to result in the same call? >>>> paintPeer is used to draw the native part of the peer(text of the >>>> label, border of the button etc). >>>> paint is a part of Component.paintAll(). And as a result of it call >>>> it should paint the native part of the peer and it should call >>>> appropriate paint method from the target. >>>>> Also, why don't we post an event if reapint() is invoked on the EDT? >>>> We do this in osx, but in xawt there are "smart" caches, which are >>>> initialized during the paint of the peer. See >>>> XLabelPeer&cachedFontMetrics for example . Note that this cache is >>>> completely broken. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 10/16/2013 06:00 PM, Sergey Bylokhov wrote: >>>>>> Hello. >>>>>> Please review the fix for jdk 8. >>>>>> The fix has two parts >>>>>> - Repaint method in the peer now paint the component in place >>>>>> if it >>>>>> was called on EDT only. >>>>>> - Most of setters were changed to stop recursion if they were >>>>>> called >>>>>> on EDT. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7090424 >>>>>> Webrev can be found at: >>>>>> http://cr.openjdk.java.net/~serb/7090424/webrev.00 >>>>>> >>>> >>>> >>> >>> >> >> -- Best regards, Sergey. From leonid.romanov at oracle.com Tue Oct 22 05:48:05 2013 From: leonid.romanov at oracle.com (leonid.romanov at oracle.com) Date: Tue, 22 Oct 2013 12:48:05 +0000 Subject: hg: jdk8/awt/jdk: 8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" Message-ID: <20131022124920.33BDF6260E@hg.openjdk.java.net> Changeset: d72ca6dac444 Author: leonidr Date: 2013-10-22 16:45 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d72ca6dac444 8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/osxapp/NSApplicationAWT.m + test/java/awt/event/KeyEvent/8020209/bug8020209.java ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java From anthony.petrov at oracle.com Tue Oct 22 06:38:53 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Oct 2013 17:38:53 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError In-Reply-To: <52665F39.1030102@oracle.com> References: <525E9BF6.9040602@oracle.com> <526118D7.8040106@oracle.com> <52611FB9.9080605@oracle.com> <526523D5.4090207@oracle.com> <5266372F.1080104@oracle.com> <52664AF5.9090105@oracle.com> <52665F39.1030102@oracle.com> Message-ID: <52667FED.5030903@oracle.com> Hi Sergey, Thanks for the updated webrev, and thanks for renaming the postPaintEvent() method. It now looks much better. I'm comparing the changes to XCanvasPeer and XComponentPeer, and I see that previously we would trigger target.repaint() if the current background of the peer is null (regardless of the argument value passed to XCanvasPeer.setBackground(). The XComponentPeer.setBackground() won'd trigger a repaint if both the current background color and the argument are nulls. Also, it doesn't call target.repaint() directly as the former method in XCanvasPeer did. I see that in XWindow.repaint() there's some logic that might send a repaint event asynchronously depending on the current thread, but still may not do so. Also, XListPeer now dispatches target's paint() asynchronously through an event whereas previously this method has always been called directly. I believe I understand the reason for this: we want to post an event instead of calling the method directly to avoid a StackOverflowError. And this looks fine then. However, in case of the XCanvasPeer I'm not sure we trigger target's repainting in all cases depending on the current thread. I feel there's some change in logic which is not properly documented or may even be a bug that could cause some regressions in user code dealing with canvases. Could you please elaborate on the changes in canvas? Another point is regarding the XWindow.reapint() changes alone. Previously it has called paint(), and the latter simply called paintPeer w/o repainting the target. Only the XComponentPeer repainted the target in its overridden repaint() method. And this does seem logical since it's the XComponentPeer that should maintain the link between a peer and its target. So my question is, would it be more logical to implement the if (dispatchThread) logic in XComponentPeer.paint() instead of XWindow.repaint()? -- best regards, Anthony On 10/22/2013 03:19 PM, Sergey Bylokhov wrote: > New version here: > http://cr.openjdk.java.net/~serb/7090424/webrev.02/ > > On 22.10.2013 13:52, Anthony Petrov wrote: >> Hi Sergey, >> >> Sorry, but I can't review a fix w/o a webrev. >> >> What kind of problems do you experience with the tool? The cr.openjdk >> should now have enough free space to host new webrevs. Please try to >> re-upload the new webrev. >> >> -- >> best regards, >> Anthony >> >> On 10/22/2013 12:28 PM, Sergey Bylokhov wrote: >>> I have a problem with the review tool. I assume that version .00 with >>> removed volatiles and renamed handleexpose event is ok for everybody? >>> >>> On 10/21/13 4:53 PM, Sergey Bylokhov wrote: >>>> Hi, Anthony. >>>> Since cr have some issues with the space. I upload 2 files, where >>>> handleExposeEvent was renamed to postPaintEvent(): >>>> >>>> http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XWindow.java.sdiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XContentWindow.java.sdiff.html >>>> >>>> >>>> >>>> On 18.10.2013 15:47, Sergey Bylokhov wrote: >>>>> Hi, Anthony. >>>>> On 18.10.2013 15:17, Anthony Petrov wrote: >>>>>> Hi Sergey, >>>>>> >>>>>> In XAWT, we usually use the StateLock to synchronize access to peer >>>>>> fields (such as background, label, etc.) I don't think that >>>>>> switching to volatile is a good idea since it prevents us from >>>>>> performing atomic read/writes to the fields. And this is exactly >>>>>> what we need for this fix, actually. In other words, the following >>>>>> pattern works perfectly: >>>>>> >>>>>> synchronized (lock) { >>>>>> if (a != b) { >>>>>> a = b; >>>>>> // do stuff, or set a flag to do it later w/o the lock >>>>>> } >>>>>> } >>>>>> >>>>>> whereas the following doesn't: >>>>>> >>>>>> volatile a; >>>>>> if (a != b) { >>>>>> a = b; >>>>>> // do stuff >>>>>> } >>>>>> >>>>>> The latter doesn't work because the value of 'a' may change from >>>>>> another thread after the if() statement in the first thread is >>>>>> executed. >>>>> If it will be changed that's ok. It is safe in this context since >>>>> there is no races. a will be the latest setted value and repaint >>>>> action will be done after a was set. Non trivial setters(like >>>>> setLabel/setText) are called under the locks in shared code. >>>>>> >>>>>> Please note that this is critical for AWT because it is a >>>>>> multi-threaded GUI toolkit. >>>>>> >>>>>> src/solaris/classes/sun/awt/X11/XListPeer.java >>>>>>> - target.paint(g); >>>>>>> + handleExposeEvent(target, 0, 0, getWidth(), >>>>>>> getHeight()); >>>>>> >>>>>> (the same applies to XWindow.repaint): can you please rename >>>>>> XWindow.handleExposeEvent(Component...) to postPaintEvent() and make >>>>>> it final? A good javadoc for this method would also be appreciated, >>>>>> because currently seeing the name handle*() I'd think it needs to be >>>>>> done under the awtLock(). >>>>> Will do. >>>>>> >>>>>> Also, for the corresponding changes in XWindow.repaint(), could you >>>>>> please elaborate a bit more? Looking at the code I see that >>>>>> XWindow.paint() calls paintPeer(). And in repaint(), you either call >>>>>> paint() or paintPeer() depending on the current thread. Why is it >>>>>> needed? Can we just call paintPeer() (or paint() for that matter) >>>>>> unconditionally since they both seem to result in the same call? >>>>> paintPeer is used to draw the native part of the peer(text of the >>>>> label, border of the button etc). >>>>> paint is a part of Component.paintAll(). And as a result of it call >>>>> it should paint the native part of the peer and it should call >>>>> appropriate paint method from the target. >>>>>> Also, why don't we post an event if reapint() is invoked on the EDT? >>>>> We do this in osx, but in xawt there are "smart" caches, which are >>>>> initialized during the paint of the peer. See >>>>> XLabelPeer&cachedFontMetrics for example . Note that this cache is >>>>> completely broken. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 10/16/2013 06:00 PM, Sergey Bylokhov wrote: >>>>>>> Hello. >>>>>>> Please review the fix for jdk 8. >>>>>>> The fix has two parts >>>>>>> - Repaint method in the peer now paint the component in place >>>>>>> if it >>>>>>> was called on EDT only. >>>>>>> - Most of setters were changed to stop recursion if they were >>>>>>> called >>>>>>> on EDT. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7090424 >>>>>>> Webrev can be found at: >>>>>>> http://cr.openjdk.java.net/~serb/7090424/webrev.00 >>>>>>> >>>>> >>>>> >>>> >>>> >>> >>> > > From Sergey.Bylokhov at oracle.com Tue Oct 22 08:16:08 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Oct 2013 19:16:08 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError In-Reply-To: <52667FED.5030903@oracle.com> References: <525E9BF6.9040602@oracle.com> <526118D7.8040106@oracle.com> <52611FB9.9080605@oracle.com> <526523D5.4090207@oracle.com> <5266372F.1080104@oracle.com> <52664AF5.9090105@oracle.com> <52665F39.1030102@oracle.com> <52667FED.5030903@oracle.com> Message-ID: <526696B8.3010203@oracle.com> Hi, Anthony. On 22.10.2013 17:38, Anthony Petrov wrote: > Hi Sergey, > > I'm comparing the changes to XCanvasPeer and XComponentPeer, and I see > that previously we would trigger target.repaint() if the current > background of the peer is null (regardless of the argument value > passed to XCanvasPeer.setBackground(). > The XComponentPeer.setBackground() won'd trigger a repaint if both the > current background color and the argument are nulls. Also, it doesn't > call target.repaint() directly as the former method in XCanvasPeer > did. I see that in XWindow.repaint() there's some logic that might > send a repaint event asynchronously depending on the current thread, > but still may not do so. - This method was added to the XCanvasPeer in this 4947530 to stop kind of recursion postRepaint->paint->postRepaint. - Usage of target repaint is incorrect here, it should be used from the user's code only, because it trigger UPDATE event instead of PAINT event. > Also, XListPeer now dispatches target's paint() asynchronously through > an event whereas previously this method has always been called > directly. I believe I understand the reason for this: we want to post > an event instead of calling the method directly to avoid a > StackOverflowError. And this looks fine then.However, in case of the > XCanvasPeer I'm not sure we trigger target's repainting in all cases > depending on the current thread. I feel there's some change in logic > which is not properly documented or may even be a bug that could cause > some regressions in user code dealing with canvases. What does it mean "not sure we trigger target's repainting in all cases depending on the current thread"? If background is changed on the EDT we paint a native/target, if background changed on other thread we paint native part and post PAINT event, which repaint the whole component later. > Another point is regarding the XWindow.reapint() changes alone. > Previously it has called paint(), and the latter simply called > paintPeer w/o repainting the target. Only the XComponentPeer repainted > the target in its overridden repaint() method. And this does seem > logical since it's the XComponentPeer that should maintain the link > between a peer and its target. So my question is, would it be more > logical to implement the if (dispatchThread) logic in > XComponentPeer.paint() instead of XWindow.repaint()? It is not possible, because a paint() method can be called from the Component.paintAll() on any thread and it should paint all parts of the component(native/user's) synchronously. > > -- > best regards, > Anthony > > On 10/22/2013 03:19 PM, Sergey Bylokhov wrote: >> New version here: >> http://cr.openjdk.java.net/~serb/7090424/webrev.02 >> >> On 22.10.2013 13:52, Anthony Petrov wrote: >>> Hi Sergey, >>> >>> Sorry, but I can't review a fix w/o a webrev. >>> >>> What kind of problems do you experience with the tool? The cr.openjdk >>> should now have enough free space to host new webrevs. Please try to >>> re-upload the new webrev. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/22/2013 12:28 PM, Sergey Bylokhov wrote: >>>> I have a problem with the review tool. I assume that version .00 with >>>> removed volatiles and renamed handleexpose event is ok for everybody? >>>> >>>> On 10/21/13 4:53 PM, Sergey Bylokhov wrote: >>>>> Hi, Anthony. >>>>> Since cr have some issues with the space. I upload 2 files, where >>>>> handleExposeEvent was renamed to postPaintEvent(): >>>>> >>>>> http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XWindow.java.sdiff.html >>>>> >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XContentWindow.java.sdiff.html >>>>> >>>>> >>>>> >>>>> >>>>> On 18.10.2013 15:47, Sergey Bylokhov wrote: >>>>>> Hi, Anthony. >>>>>> On 18.10.2013 15:17, Anthony Petrov wrote: >>>>>>> Hi Sergey, >>>>>>> >>>>>>> In XAWT, we usually use the StateLock to synchronize access to peer >>>>>>> fields (such as background, label, etc.) I don't think that >>>>>>> switching to volatile is a good idea since it prevents us from >>>>>>> performing atomic read/writes to the fields. And this is exactly >>>>>>> what we need for this fix, actually. In other words, the following >>>>>>> pattern works perfectly: >>>>>>> >>>>>>> synchronized (lock) { >>>>>>> if (a != b) { >>>>>>> a = b; >>>>>>> // do stuff, or set a flag to do it later w/o the lock >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> whereas the following doesn't: >>>>>>> >>>>>>> volatile a; >>>>>>> if (a != b) { >>>>>>> a = b; >>>>>>> // do stuff >>>>>>> } >>>>>>> >>>>>>> The latter doesn't work because the value of 'a' may change from >>>>>>> another thread after the if() statement in the first thread is >>>>>>> executed. >>>>>> If it will be changed that's ok. It is safe in this context since >>>>>> there is no races. a will be the latest setted value and repaint >>>>>> action will be done after a was set. Non trivial setters(like >>>>>> setLabel/setText) are called under the locks in shared code. >>>>>>> >>>>>>> Please note that this is critical for AWT because it is a >>>>>>> multi-threaded GUI toolkit. >>>>>>> >>>>>>> src/solaris/classes/sun/awt/X11/XListPeer.java >>>>>>>> - target.paint(g); >>>>>>>> + handleExposeEvent(target, 0, 0, getWidth(), >>>>>>>> getHeight()); >>>>>>> >>>>>>> (the same applies to XWindow.repaint): can you please rename >>>>>>> XWindow.handleExposeEvent(Component...) to postPaintEvent() and >>>>>>> make >>>>>>> it final? A good javadoc for this method would also be appreciated, >>>>>>> because currently seeing the name handle*() I'd think it needs >>>>>>> to be >>>>>>> done under the awtLock(). >>>>>> Will do. >>>>>>> >>>>>>> Also, for the corresponding changes in XWindow.repaint(), could you >>>>>>> please elaborate a bit more? Looking at the code I see that >>>>>>> XWindow.paint() calls paintPeer(). And in repaint(), you either >>>>>>> call >>>>>>> paint() or paintPeer() depending on the current thread. Why is it >>>>>>> needed? Can we just call paintPeer() (or paint() for that matter) >>>>>>> unconditionally since they both seem to result in the same call? >>>>>> paintPeer is used to draw the native part of the peer(text of the >>>>>> label, border of the button etc). >>>>>> paint is a part of Component.paintAll(). And as a result of it call >>>>>> it should paint the native part of the peer and it should call >>>>>> appropriate paint method from the target. >>>>>>> Also, why don't we post an event if reapint() is invoked on the >>>>>>> EDT? >>>>>> We do this in osx, but in xawt there are "smart" caches, which are >>>>>> initialized during the paint of the peer. See >>>>>> XLabelPeer&cachedFontMetrics for example . Note that this cache is >>>>>> completely broken. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 10/16/2013 06:00 PM, Sergey Bylokhov wrote: >>>>>>>> Hello. >>>>>>>> Please review the fix for jdk 8. >>>>>>>> The fix has two parts >>>>>>>> - Repaint method in the peer now paint the component in place >>>>>>>> if it >>>>>>>> was called on EDT only. >>>>>>>> - Most of setters were changed to stop recursion if they were >>>>>>>> called >>>>>>>> on EDT. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7090424 >>>>>>>> Webrev can be found at: >>>>>>>> http://cr.openjdk.java.net/~serb/7090424/webrev.00 >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >> >> -- Best regards, Sergey. From david.dehaven at oracle.com Tue Oct 22 09:09:31 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 22 Oct 2013 09:09:31 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <52665067.40102@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <52665067.40102@oracle.com> Message-ID: <9CE00A53-DEAC-4BEB-8965-6EA420451B68@oracle.com> Oops, you're right, it definitely crashes. I'll put that code back and take Artem's suggestion. -DrD- > Artem is correct. On Mac we can't start a GUI session via ssh, for example. Thus we choose the headless mode then. The isInAquaSession() is supposed to perform exactly this check. This logic needs to be preserved. > > -- > best regards, > Anthony > > On 10/22/2013 01:23 PM, Artem Ananiev wrote: >> Hi, David, >> >> thanks for additional cleanup. >> >> I have only one concern. Before the fix, we checked if there is an >> active Aqua session. When no session was found, we falled back to >> HToolkit. I think this logic should be preserved, but slightly >> corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >> >> Otherwise the only way to run headless on Mac will be to force it with >> the system property. It works this way on Windows, but on Windows we're >> sure that WToolkit can run even without a UI session. Is it also true on >> Mac? Did you try to launch AWT without -Djava.awt.headless=true from >> remote console with no users logged in? >> >> Thanks, >> >> Artem >> >> On 10/22/2013 7:34 AM, David DeHaven wrote: >>> >>> Updated webrev for JDK (hotspot change is the same): >>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>> >>> Changes since last version: >>> - Moved to jdk8/build/jdk to save someone a merge headache, moved >>> changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>> - Removed HToolkit option and toolkit selection code from >>> java_props_macosx.[ch] >>> >>> -DrD- >>> >>> >>>> I want to do one more iteration of this. Based on feedback it seems I >>>> can remove a bit more code from java_props_macosx.[ch] and make >>>> things a bit cleaner. >>>> >>>> -DrD- >>>> >>>>> Thanks guys. >>>>> >>>>> Anthony, can you sponsor this for me? >>>>> >>>>> -DrD- >>>>> >>>>>> This fix looks fine to me as well. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>> >>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>> >>>>>>> Request for review of JDK-8025673: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>> >>>>>>> Proposed changes: >>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>> >>>>>>> This change disables building libawt_xawt.dylib and >>>>>>> libawt_headless.dylib on Mac since they are not used and not >>>>>>> supported. There are too many challenges (and not enough time) in >>>>>>> removing all X11 code from the Mac build at this time, so we're >>>>>>> deferring complete removal for later (will be covered by >>>>>>> JDK-8003900). >>>>>>> >>>>>>> A small change to hotspot is required as it was looking for >>>>>>> libawt_xawt.dylib and if not found would set java.awt.headless to >>>>>>> true. Since we don't build a headless only JRE on Mac I just have >>>>>>> that method return false. I'm not sure how to handle changes to >>>>>>> hotspot, can it be pushed along with the jdk changes? Without that >>>>>>> change the Mac builds will be broken. >>>>>>> >>>>>>> Significant build system changes, build-dev guys are encouraged to >>>>>>> comment... >>>>>>> >>>>>>> I tried excluding all sun/awt/X11 classes in >>>>>>> CompileJavaClasses.gmk but that broke JNI header generation on >>>>>>> platforms still using X11 and I couldn't use the big list of >>>>>>> excluded files on Mac as that resulted in Java compilation errors, >>>>>>> so I just added some logic to exclude everything on Mac and left >>>>>>> the list in place everywhere else. >>>>>>> >>>>>>> The changes to CompileNativeLibraries.gmk will port to >>>>>>> libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a >>>>>>> problem in the jdk8/build workspace where the build cannot find >>>>>>> symbols in JNI libs so that issue needs to be resolved first. I've >>>>>>> not had time to investigate that problem. >>>>>>> >>>>>>> >>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>> 461 } else { >>>>>>> 462 // TODO: do we still need this? >>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>> 464 } >>>>>>> >>>>>>> Is that necessary? Since we're now using libawt_lwawt in both >>>>>>> headless and headful modes I would think we could remove the >>>>>>> HToolkit option, but I'm not 100% certain about that. >>>>>>> >>>>>>> >>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and >>>>>>> both seem to be working fine. >>>>>>> >>>>>>> JPRT run for Mac is in progress, I will submit one for all other >>>>>>> platforms when it finishes building. >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>> >>>> >>> From leonid.romanov at oracle.com Tue Oct 22 09:22:06 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 22 Oct 2013 20:22:06 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <52664425.4080201@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> Message-ID: <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> There was a discussion why we use HToolkit instead of HeadlessToolkit: http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html So we might want to continue using it. Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() On Oct 22, 2013, at 1:23 PM, Artem Ananiev wrote: > Hi, David, > > thanks for additional cleanup. > > I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). > > Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? > > Thanks, > > Artem > > On 10/22/2013 7:34 AM, David DeHaven wrote: >> >> Updated webrev for JDK (hotspot change is the same): >> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >> >> Changes since last version: >> - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >> - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] >> >> -DrD- >> >> >>> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >>> >>> -DrD- >>> >>>> Thanks guys. >>>> >>>> Anthony, can you sponsor this for me? >>>> >>>> -DrD- >>>> >>>>> This fix looks fine to me as well. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>> >>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>> >>>>>> Request for review of JDK-8025673: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>> >>>>>> Proposed changes: >>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>> >>>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>>> >>>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>>> >>>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>>> >>>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>>> >>>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>>> >>>>>> >>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>> 459 if (prefToolkit == CToolkit) { >>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>> 461 } else { >>>>>> 462 // TODO: do we still need this? >>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>> 464 } >>>>>> >>>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>>> >>>>>> >>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>>> >>>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>>> >>>>>> -DrD- >>>>>> >>>> >>> >> From anthony.petrov at oracle.com Tue Oct 22 10:46:38 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Oct 2013 21:46:38 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError In-Reply-To: <526696B8.3010203@oracle.com> References: <525E9BF6.9040602@oracle.com> <526118D7.8040106@oracle.com> <52611FB9.9080605@oracle.com> <526523D5.4090207@oracle.com> <5266372F.1080104@oracle.com> <52664AF5.9090105@oracle.com> <52665F39.1030102@oracle.com> <52667FED.5030903@oracle.com> <526696B8.3010203@oracle.com> Message-ID: <5266B9FE.6000303@oracle.com> On 10/22/2013 07:16 PM, Sergey Bylokhov wrote: > Hi, Anthony. > On 22.10.2013 17:38, Anthony Petrov wrote: >> Hi Sergey, >> >> I'm comparing the changes to XCanvasPeer and XComponentPeer, and I see >> that previously we would trigger target.repaint() if the current >> background of the peer is null (regardless of the argument value >> passed to XCanvasPeer.setBackground(). >> The XComponentPeer.setBackground() won'd trigger a repaint if both the >> current background color and the argument are nulls. Also, it doesn't >> call target.repaint() directly as the former method in XCanvasPeer >> did. I see that in XWindow.repaint() there's some logic that might >> send a repaint event asynchronously depending on the current thread, >> but still may not do so. > - This method was added to the XCanvasPeer in this 4947530 to stop > kind of recursion postRepaint->paint->postRepaint. > - Usage of target repaint is incorrect here, it should be used from > the user's code only, because it trigger UPDATE event instead of PAINT > event. >> Also, XListPeer now dispatches target's paint() asynchronously through >> an event whereas previously this method has always been called >> directly. I believe I understand the reason for this: we want to post >> an event instead of calling the method directly to avoid a >> StackOverflowError. And this looks fine then.However, in case of the >> XCanvasPeer I'm not sure we trigger target's repainting in all cases >> depending on the current thread. I feel there's some change in logic >> which is not properly documented or may even be a bug that could cause >> some regressions in user code dealing with canvases. > What does it mean "not sure we trigger target's repainting in all cases > depending on the current thread"? If background is changed on the EDT we See above: if you call Canvas.setBackground(null), currently this triggers repainting of the canvas even if the background hasn't been set previously. After your fix removes XCanvasPeer.setBackground(), this is no longer true. So, -1 time we repaint the canvas. This is what I mean under "not sure...". Let's hope this won't break user code (though it would be worthwhile to investigate the previous logic and understand why this was done...) > paint a native/target, if background changed on other thread we paint > native part and post PAINT event, which repaint the whole component later. Ah, so in this case we actually use the XComponentPeer.paint() which does paint the target synchronously. Now I see this. Could you please add a comment just above the line 503 in XWindow.java about that to clarify this? I'm OK with the fix with such a comment. >> Another point is regarding the XWindow.reapint() changes alone. >> Previously it has called paint(), and the latter simply called >> paintPeer w/o repainting the target. Only the XComponentPeer repainted >> the target in its overridden repaint() method. And this does seem >> logical since it's the XComponentPeer that should maintain the link >> between a peer and its target. So my question is, would it be more >> logical to implement the if (dispatchThread) logic in >> XComponentPeer.paint() instead of XWindow.repaint()? > It is not possible, because a paint() method can be called from the > Component.paintAll() on any thread and it should paint all parts of the > component(native/user's) synchronously. I see. This looks weird (at least, method naming-wise), but let it be so. Thanks for the clarification. -- best regards, Anthony >> >> -- >> best regards, >> Anthony >> >> On 10/22/2013 03:19 PM, Sergey Bylokhov wrote: >>> New version here: >>> http://cr.openjdk.java.net/~serb/7090424/webrev.02 >>> >>> On 22.10.2013 13:52, Anthony Petrov wrote: >>>> Hi Sergey, >>>> >>>> Sorry, but I can't review a fix w/o a webrev. >>>> >>>> What kind of problems do you experience with the tool? The cr.openjdk >>>> should now have enough free space to host new webrevs. Please try to >>>> re-upload the new webrev. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/22/2013 12:28 PM, Sergey Bylokhov wrote: >>>>> I have a problem with the review tool. I assume that version .00 with >>>>> removed volatiles and renamed handleexpose event is ok for everybody? >>>>> >>>>> On 10/21/13 4:53 PM, Sergey Bylokhov wrote: >>>>>> Hi, Anthony. >>>>>> Since cr have some issues with the space. I upload 2 files, where >>>>>> handleExposeEvent was renamed to postPaintEvent(): >>>>>> >>>>>> http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XWindow.java.sdiff.html >>>>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XContentWindow.java.sdiff.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 18.10.2013 15:47, Sergey Bylokhov wrote: >>>>>>> Hi, Anthony. >>>>>>> On 18.10.2013 15:17, Anthony Petrov wrote: >>>>>>>> Hi Sergey, >>>>>>>> >>>>>>>> In XAWT, we usually use the StateLock to synchronize access to peer >>>>>>>> fields (such as background, label, etc.) I don't think that >>>>>>>> switching to volatile is a good idea since it prevents us from >>>>>>>> performing atomic read/writes to the fields. And this is exactly >>>>>>>> what we need for this fix, actually. In other words, the following >>>>>>>> pattern works perfectly: >>>>>>>> >>>>>>>> synchronized (lock) { >>>>>>>> if (a != b) { >>>>>>>> a = b; >>>>>>>> // do stuff, or set a flag to do it later w/o the lock >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> whereas the following doesn't: >>>>>>>> >>>>>>>> volatile a; >>>>>>>> if (a != b) { >>>>>>>> a = b; >>>>>>>> // do stuff >>>>>>>> } >>>>>>>> >>>>>>>> The latter doesn't work because the value of 'a' may change from >>>>>>>> another thread after the if() statement in the first thread is >>>>>>>> executed. >>>>>>> If it will be changed that's ok. It is safe in this context since >>>>>>> there is no races. a will be the latest setted value and repaint >>>>>>> action will be done after a was set. Non trivial setters(like >>>>>>> setLabel/setText) are called under the locks in shared code. >>>>>>>> >>>>>>>> Please note that this is critical for AWT because it is a >>>>>>>> multi-threaded GUI toolkit. >>>>>>>> >>>>>>>> src/solaris/classes/sun/awt/X11/XListPeer.java >>>>>>>>> - target.paint(g); >>>>>>>>> + handleExposeEvent(target, 0, 0, getWidth(), >>>>>>>>> getHeight()); >>>>>>>> >>>>>>>> (the same applies to XWindow.repaint): can you please rename >>>>>>>> XWindow.handleExposeEvent(Component...) to postPaintEvent() and >>>>>>>> make >>>>>>>> it final? A good javadoc for this method would also be appreciated, >>>>>>>> because currently seeing the name handle*() I'd think it needs >>>>>>>> to be >>>>>>>> done under the awtLock(). >>>>>>> Will do. >>>>>>>> >>>>>>>> Also, for the corresponding changes in XWindow.repaint(), could you >>>>>>>> please elaborate a bit more? Looking at the code I see that >>>>>>>> XWindow.paint() calls paintPeer(). And in repaint(), you either >>>>>>>> call >>>>>>>> paint() or paintPeer() depending on the current thread. Why is it >>>>>>>> needed? Can we just call paintPeer() (or paint() for that matter) >>>>>>>> unconditionally since they both seem to result in the same call? >>>>>>> paintPeer is used to draw the native part of the peer(text of the >>>>>>> label, border of the button etc). >>>>>>> paint is a part of Component.paintAll(). And as a result of it call >>>>>>> it should paint the native part of the peer and it should call >>>>>>> appropriate paint method from the target. >>>>>>>> Also, why don't we post an event if reapint() is invoked on the >>>>>>>> EDT? >>>>>>> We do this in osx, but in xawt there are "smart" caches, which are >>>>>>> initialized during the paint of the peer. See >>>>>>> XLabelPeer&cachedFontMetrics for example . Note that this cache is >>>>>>> completely broken. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 10/16/2013 06:00 PM, Sergey Bylokhov wrote: >>>>>>>>> Hello. >>>>>>>>> Please review the fix for jdk 8. >>>>>>>>> The fix has two parts >>>>>>>>> - Repaint method in the peer now paint the component in place >>>>>>>>> if it >>>>>>>>> was called on EDT only. >>>>>>>>> - Most of setters were changed to stop recursion if they were >>>>>>>>> called >>>>>>>>> on EDT. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7090424 >>>>>>>>> Webrev can be found at: >>>>>>>>> http://cr.openjdk.java.net/~serb/7090424/webrev.00 >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >>> > > From Sergey.Bylokhov at oracle.com Tue Oct 22 10:53:10 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Oct 2013 21:53:10 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError In-Reply-To: <5266B9FE.6000303@oracle.com> References: <525E9BF6.9040602@oracle.com> <526118D7.8040106@oracle.com> <52611FB9.9080605@oracle.com> <526523D5.4090207@oracle.com> <5266372F.1080104@oracle.com> <52664AF5.9090105@oracle.com> <52665F39.1030102@oracle.com> <52667FED.5030903@oracle.com> <526696B8.3010203@oracle.com> <5266B9FE.6000303@oracle.com> Message-ID: <5266BB86.2040702@oracle.com> On 22.10.2013 21:46, Anthony Petrov wrote: > See above: if you call Canvas.setBackground(null), currently this > triggers repainting of the canvas even if the background hasn't been > set previously. After your fix removes XCanvasPeer.setBackground(), > this is no longer true. So, -1 time we repaint the canvas. This is > what I mean under "not sure...". Let's hope this won't break user code > (though it would be worthwhile to investigate the previous logic and > understand why this was done...) Correct, but color should not be null, because of the code in Component.setBackground() c = getBackground(); if (c != null) { peer.setBackground(c); } -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Oct 22 10:54:34 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Oct 2013 21:54:34 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> Message-ID: <5266BBDA.2010106@oracle.com> We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. Since we must load the lwawt lib in headless on Mac anyway, we may as well use the CToolkit (properly wrapped in the HeadlessToolkit). But there's no need to continue to use the HToolkit on Mac. -- best regards, Anthony On 10/22/2013 08:22 PM, Leonid Romanov wrote: > There was a discussion why we use HToolkit instead of HeadlessToolkit: > http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html > > So we might want to continue using it. > > Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() > > On Oct 22, 2013, at 1:23 PM, Artem Ananiev wrote: > >> Hi, David, >> >> thanks for additional cleanup. >> >> I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >> >> Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? >> >> Thanks, >> >> Artem >> >> On 10/22/2013 7:34 AM, David DeHaven wrote: >>> >>> Updated webrev for JDK (hotspot change is the same): >>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>> >>> Changes since last version: >>> - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>> - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] >>> >>> -DrD- >>> >>> >>>> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >>>> >>>> -DrD- >>>> >>>>> Thanks guys. >>>>> >>>>> Anthony, can you sponsor this for me? >>>>> >>>>> -DrD- >>>>> >>>>>> This fix looks fine to me as well. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>> >>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>> >>>>>>> Request for review of JDK-8025673: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>> >>>>>>> Proposed changes: >>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>> >>>>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>>>> >>>>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>>>> >>>>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>>>> >>>>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>>>> >>>>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>>>> >>>>>>> >>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>> 461 } else { >>>>>>> 462 // TODO: do we still need this? >>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>> 464 } >>>>>>> >>>>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>>>> >>>>>>> >>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>>>> >>>>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>> >>>> >>> > From anthony.petrov at oracle.com Tue Oct 22 10:57:49 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Oct 2013 21:57:49 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError In-Reply-To: <5266BB86.2040702@oracle.com> References: <525E9BF6.9040602@oracle.com> <526118D7.8040106@oracle.com> <52611FB9.9080605@oracle.com> <526523D5.4090207@oracle.com> <5266372F.1080104@oracle.com> <52664AF5.9090105@oracle.com> <52665F39.1030102@oracle.com> <52667FED.5030903@oracle.com> <526696B8.3010203@oracle.com> <5266B9FE.6000303@oracle.com> <5266BB86.2040702@oracle.com> Message-ID: <5266BC9D.7070801@oracle.com> On 10/22/2013 09:53 PM, Sergey Bylokhov wrote: > On 22.10.2013 21:46, Anthony Petrov wrote: >> See above: if you call Canvas.setBackground(null), currently this >> triggers repainting of the canvas even if the background hasn't been >> set previously. After your fix removes XCanvasPeer.setBackground(), >> this is no longer true. So, -1 time we repaint the canvas. This is >> what I mean under "not sure...". Let's hope this won't break user code >> (though it would be worthwhile to investigate the previous logic and >> understand why this was done...) > Correct, but color should not be null, because of the code in > Component.setBackground() > c = getBackground(); > if (c != null) { > peer.setBackground(c); > } Indeed. Thanks for pointing that out. All right then. Please add a comment that I asked you about in my previous message, and consider the fix approved by me then. -- best regards, Anthony From Sergey.Bylokhov at oracle.com Tue Oct 22 11:01:11 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Oct 2013 22:01:11 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5266BBDA.2010106@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> Message-ID: <5266BD67.4010101@oracle.com> Hello. I suppose we should request from sqe team to run the jck tests in the "true" headless mode via ssh(w/o headless option and w/o access to Aqua session). On 22.10.2013 21:54, Anthony Petrov wrote: > We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. > > Since we must load the lwawt lib in headless on Mac anyway, we may as > well use the CToolkit (properly wrapped in the HeadlessToolkit). But > there's no need to continue to use the HToolkit on Mac. > > -- > best regards, > Anthony > > On 10/22/2013 08:22 PM, Leonid Romanov wrote: >> There was a discussion why we use HToolkit instead of HeadlessToolkit: >> http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html >> >> So we might want to continue using it. >> >> Also, please be aware that there is HToolkit check in >> GraphicsToolkit.getHeadlessProperty() >> >> On Oct 22, 2013, at 1:23 PM, Artem Ananiev >> wrote: >> >>> Hi, David, >>> >>> thanks for additional cleanup. >>> >>> I have only one concern. Before the fix, we checked if there is an >>> active Aqua session. When no session was found, we falled back to >>> HToolkit. I think this logic should be preserved, but slightly >>> corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >>> >>> Otherwise the only way to run headless on Mac will be to force it >>> with the system property. It works this way on Windows, but on >>> Windows we're sure that WToolkit can run even without a UI session. >>> Is it also true on Mac? Did you try to launch AWT without >>> -Djava.awt.headless=true from remote console with no users logged in? >>> >>> Thanks, >>> >>> Artem >>> >>> On 10/22/2013 7:34 AM, David DeHaven wrote: >>>> >>>> Updated webrev for JDK (hotspot change is the same): >>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>>> >>>> Changes since last version: >>>> - Moved to jdk8/build/jdk to save someone a merge headache, moved >>>> changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>>> - Removed HToolkit option and toolkit selection code from >>>> java_props_macosx.[ch] >>>> >>>> -DrD- >>>> >>>> >>>>> I want to do one more iteration of this. Based on feedback it >>>>> seems I can remove a bit more code from java_props_macosx.[ch] and >>>>> make things a bit cleaner. >>>>> >>>>> -DrD- >>>>> >>>>>> Thanks guys. >>>>>> >>>>>> Anthony, can you sponsor this for me? >>>>>> >>>>>> -DrD- >>>>>> >>>>>>> This fix looks fine to me as well. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>>> >>>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>>> >>>>>>>> Request for review of JDK-8025673: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>>> >>>>>>>> Proposed changes: >>>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>>> >>>>>>>> This change disables building libawt_xawt.dylib and >>>>>>>> libawt_headless.dylib on Mac since they are not used and not >>>>>>>> supported. There are too many challenges (and not enough time) >>>>>>>> in removing all X11 code from the Mac build at this time, so >>>>>>>> we're deferring complete removal for later (will be covered by >>>>>>>> JDK-8003900). >>>>>>>> >>>>>>>> A small change to hotspot is required as it was looking for >>>>>>>> libawt_xawt.dylib and if not found would set java.awt.headless >>>>>>>> to true. Since we don't build a headless only JRE on Mac I just >>>>>>>> have that method return false. I'm not sure how to handle >>>>>>>> changes to hotspot, can it be pushed along with the jdk >>>>>>>> changes? Without that change the Mac builds will be broken. >>>>>>>> >>>>>>>> Significant build system changes, build-dev guys are encouraged >>>>>>>> to comment... >>>>>>>> >>>>>>>> I tried excluding all sun/awt/X11 classes in >>>>>>>> CompileJavaClasses.gmk but that broke JNI header generation on >>>>>>>> platforms still using X11 and I couldn't use the big list of >>>>>>>> excluded files on Mac as that resulted in Java compilation >>>>>>>> errors, so I just added some logic to exclude everything on Mac >>>>>>>> and left the list in place everywhere else. >>>>>>>> >>>>>>>> The changes to CompileNativeLibraries.gmk will port to >>>>>>>> libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a >>>>>>>> problem in the jdk8/build workspace where the build cannot find >>>>>>>> symbols in JNI libs so that issue needs to be resolved first. >>>>>>>> I've not had time to investigate that problem. >>>>>>>> >>>>>>>> >>>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>>> 461 } else { >>>>>>>> 462 // TODO: do we still need this? >>>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>>> 464 } >>>>>>>> >>>>>>>> Is that necessary? Since we're now using libawt_lwawt in both >>>>>>>> headless and headful modes I would think we could remove the >>>>>>>> HToolkit option, but I'm not 100% certain about that. >>>>>>>> >>>>>>>> >>>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and >>>>>>>> both seem to be working fine. >>>>>>>> >>>>>>>> JPRT run for Mac is in progress, I will submit one for all >>>>>>>> other platforms when it finishes building. >>>>>>>> >>>>>>>> -DrD- >>>>>>>> >>>>>> >>>>> >>>> >> -- Best regards, Sergey. From david.dehaven at oracle.com Tue Oct 22 11:15:31 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 22 Oct 2013 11:15:31 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5266BD67.4010101@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> Message-ID: <7F14B1EF-457C-45F3-8AAA-19DC365EB065@oracle.com> [removing hotspot-dev and build-dev..] I can't look at the code at the moment as I'm focused on something else... Does the wrapping happen automagically at some point based on java.awt.headless? It doesn't look trivial to do this from within the scope of java_props_md.c, it seems the best I could do from there is trigger java.awt.headless=true if we're not in a headful login session. It would be fairly simple to have it set java.awt.headless if the logic is there to do the HeadlessToolkit wrapping, and that's something that could be done for all platforms (though only Mac would use it for the moment). Otherwise I can just revert it back to my original version and we can continue using HToolkit for now. With the current code, JTREG fails massively in headless mode (due to most calls throwing a HeadlessException) and JPRT performs horribly when running the jdk_awt tests due to it not running in an Aqua session. Is there some reliable way of testing headless mode? -DrD- > Hello. > I suppose we should request from sqe team to run the jck tests in the "true" headless mode via ssh(w/o headless option and w/o access to Aqua session). > > On 22.10.2013 21:54, Anthony Petrov wrote: >> We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. >> >> Since we must load the lwawt lib in headless on Mac anyway, we may as well use the CToolkit (properly wrapped in the HeadlessToolkit). But there's no need to continue to use the HToolkit on Mac. >> >> -- >> best regards, >> Anthony >> >> On 10/22/2013 08:22 PM, Leonid Romanov wrote: >>> There was a discussion why we use HToolkit instead of HeadlessToolkit: >>> http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html >>> >>> So we might want to continue using it. >>> >>> Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() >>> >>> On Oct 22, 2013, at 1:23 PM, Artem Ananiev wrote: >>> >>>> Hi, David, >>>> >>>> thanks for additional cleanup. >>>> >>>> I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >>>> >>>> Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 10/22/2013 7:34 AM, David DeHaven wrote: >>>>> >>>>> Updated webrev for JDK (hotspot change is the same): >>>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>>>> >>>>> Changes since last version: >>>>> - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>>>> - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] >>>>> >>>>> -DrD- >>>>> >>>>> >>>>>> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >>>>>> >>>>>> -DrD- >>>>>> >>>>>>> Thanks guys. >>>>>>> >>>>>>> Anthony, can you sponsor this for me? >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>>>>> This fix looks fine to me as well. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>>>> >>>>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>>>> >>>>>>>>> Request for review of JDK-8025673: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>>>> >>>>>>>>> Proposed changes: >>>>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>>>> >>>>>>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>>>>>> >>>>>>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>>>>>> >>>>>>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>>>>>> >>>>>>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>>>>>> >>>>>>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>>>>>> >>>>>>>>> >>>>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>>>> 461 } else { >>>>>>>>> 462 // TODO: do we still need this? >>>>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>>>> 464 } >>>>>>>>> >>>>>>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>>>>>> >>>>>>>>> >>>>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>>>>>> >>>>>>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>>>>>> >>>>>>>>> -DrD- >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> > > > -- > Best regards, Sergey. > From anthony.petrov at oracle.com Tue Oct 22 11:39:22 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Oct 2013 22:39:22 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <7F14B1EF-457C-45F3-8AAA-19DC365EB065@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <7F14B1EF-457C-45F3-8AAA-19DC365EB065@oracle.com> Message-ID: <5266C65A.6070403@oracle.com> I think that triggering java.awt.headless=true is enough. The class instance wrapping will be done automatically in java.awt.Toolkit.getDefaultToolkit(). A reliable way to test it is, I guess, as follows: log out of your GUI session, ssh to the Mac box, and try running a headless app (e.g. a printing jtreg test.) -- best regards, Anthony On 10/22/2013 10:15 PM, David DeHaven wrote: > > [removing hotspot-dev and build-dev..] > > I can't look at the code at the moment as I'm focused on something else... Does the wrapping happen automagically at some point based on java.awt.headless? It doesn't look trivial to do this from within the scope of java_props_md.c, it seems the best I could do from there is trigger java.awt.headless=true if we're not in a headful login session. It would be fairly simple to have it set java.awt.headless if the logic is there to do the HeadlessToolkit wrapping, and that's something that could be done for all platforms (though only Mac would use it for the moment). > > Otherwise I can just revert it back to my original version and we can continue using HToolkit for now. > > With the current code, JTREG fails massively in headless mode (due to most calls throwing a HeadlessException) and JPRT performs horribly when running the jdk_awt tests due to it not running in an Aqua session. Is there some reliable way of testing headless mode? > > -DrD- > >> Hello. >> I suppose we should request from sqe team to run the jck tests in the "true" headless mode via ssh(w/o headless option and w/o access to Aqua session). >> >> On 22.10.2013 21:54, Anthony Petrov wrote: >>> We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. >>> >>> Since we must load the lwawt lib in headless on Mac anyway, we may as well use the CToolkit (properly wrapped in the HeadlessToolkit). But there's no need to continue to use the HToolkit on Mac. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/22/2013 08:22 PM, Leonid Romanov wrote: >>>> There was a discussion why we use HToolkit instead of HeadlessToolkit: >>>> http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html >>>> >>>> So we might want to continue using it. >>>> >>>> Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() >>>> >>>> On Oct 22, 2013, at 1:23 PM, Artem Ananiev wrote: >>>> >>>>> Hi, David, >>>>> >>>>> thanks for additional cleanup. >>>>> >>>>> I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >>>>> >>>>> Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 10/22/2013 7:34 AM, David DeHaven wrote: >>>>>> >>>>>> Updated webrev for JDK (hotspot change is the same): >>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>>>>> >>>>>> Changes since last version: >>>>>> - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>>>>> - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] >>>>>> >>>>>> -DrD- >>>>>> >>>>>> >>>>>>> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>>>>> Thanks guys. >>>>>>>> >>>>>>>> Anthony, can you sponsor this for me? >>>>>>>> >>>>>>>> -DrD- >>>>>>>> >>>>>>>>> This fix looks fine to me as well. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> best regards, >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>>>>> >>>>>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>>>>> >>>>>>>>>> Request for review of JDK-8025673: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>>>>> >>>>>>>>>> Proposed changes: >>>>>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>>>>> >>>>>>>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>>>>>>> >>>>>>>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>>>>>>> >>>>>>>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>>>>>>> >>>>>>>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>>>>>>> >>>>>>>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>>>>> 461 } else { >>>>>>>>>> 462 // TODO: do we still need this? >>>>>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>>>>> 464 } >>>>>>>>>> >>>>>>>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>>>>>>> >>>>>>>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>>>>>>> >>>>>>>>>> -DrD- >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> >> >> -- >> Best regards, Sergey. >> > From david.dehaven at oracle.com Tue Oct 22 11:51:08 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 22 Oct 2013 11:51:08 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5266C65A.6070403@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <7F14B1EF-457C-45F3-8AAA-19DC365EB065@oracle.com> <5266C65A.6070403@oracle.com> Message-ID: <59A52BE2-ED57-4E3F-BD0E-4F61C1A1899E@oracle.com> You can also just "ssh otheruser at localhost", the login session will have no Aqua session associated with the other user. That might even work with the current user... -DrD- > I think that triggering java.awt.headless=true is enough. The class instance wrapping will be done automatically in java.awt.Toolkit.getDefaultToolkit(). > > A reliable way to test it is, I guess, as follows: log out of your GUI session, ssh to the Mac box, and try running a headless app (e.g. a printing jtreg test.) > > -- > best regards, > Anthony > > On 10/22/2013 10:15 PM, David DeHaven wrote: >> >> [removing hotspot-dev and build-dev..] >> >> I can't look at the code at the moment as I'm focused on something else... Does the wrapping happen automagically at some point based on java.awt.headless? It doesn't look trivial to do this from within the scope of java_props_md.c, it seems the best I could do from there is trigger java.awt.headless=true if we're not in a headful login session. It would be fairly simple to have it set java.awt.headless if the logic is there to do the HeadlessToolkit wrapping, and that's something that could be done for all platforms (though only Mac would use it for the moment). >> >> Otherwise I can just revert it back to my original version and we can continue using HToolkit for now. >> >> With the current code, JTREG fails massively in headless mode (due to most calls throwing a HeadlessException) and JPRT performs horribly when running the jdk_awt tests due to it not running in an Aqua session. Is there some reliable way of testing headless mode? >> >> -DrD- >> >>> Hello. >>> I suppose we should request from sqe team to run the jck tests in the "true" headless mode via ssh(w/o headless option and w/o access to Aqua session). >>> >>> On 22.10.2013 21:54, Anthony Petrov wrote: >>>> We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. >>>> >>>> Since we must load the lwawt lib in headless on Mac anyway, we may as well use the CToolkit (properly wrapped in the HeadlessToolkit). But there's no need to continue to use the HToolkit on Mac. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/22/2013 08:22 PM, Leonid Romanov wrote: >>>>> There was a discussion why we use HToolkit instead of HeadlessToolkit: >>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html >>>>> >>>>> So we might want to continue using it. >>>>> >>>>> Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() >>>>> >>>>> On Oct 22, 2013, at 1:23 PM, Artem Ananiev wrote: >>>>> >>>>>> Hi, David, >>>>>> >>>>>> thanks for additional cleanup. >>>>>> >>>>>> I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >>>>>> >>>>>> Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>> On 10/22/2013 7:34 AM, David DeHaven wrote: >>>>>>> >>>>>>> Updated webrev for JDK (hotspot change is the same): >>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>>>>>> >>>>>>> Changes since last version: >>>>>>> - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>>>>>> - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>>>> >>>>>>>> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >>>>>>>> >>>>>>>> -DrD- >>>>>>>> >>>>>>>>> Thanks guys. >>>>>>>>> >>>>>>>>> Anthony, can you sponsor this for me? >>>>>>>>> >>>>>>>>> -DrD- >>>>>>>>> >>>>>>>>>> This fix looks fine to me as well. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> best regards, >>>>>>>>>> Anthony >>>>>>>>>> >>>>>>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>>>>>> >>>>>>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>>>>>> >>>>>>>>>>> Request for review of JDK-8025673: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>>>>>> >>>>>>>>>>> Proposed changes: >>>>>>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>>>>>> >>>>>>>>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>>>>>>>> >>>>>>>>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>>>>>>>> >>>>>>>>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>>>>>>>> >>>>>>>>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>>>>>>>> >>>>>>>>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>>>>>> 461 } else { >>>>>>>>>>> 462 // TODO: do we still need this? >>>>>>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>>>>>> 464 } >>>>>>>>>>> >>>>>>>>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>>>>>>>> >>>>>>>>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>>>>>>>> >>>>>>>>>>> -DrD- >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> From artem.ananiev at oracle.com Tue Oct 22 11:53:52 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 22 Oct 2013 22:53:52 +0400 Subject: [8] Review Request: 7090424 TestGlyphVectorLayout failed automately with java.lang.StackOverflowError In-Reply-To: <52665F39.1030102@oracle.com> References: <525E9BF6.9040602@oracle.com> <526118D7.8040106@oracle.com> <52611FB9.9080605@oracle.com> <526523D5.4090207@oracle.com> <5266372F.1080104@oracle.com> <52664AF5.9090105@oracle.com> <52665F39.1030102@oracle.com> Message-ID: <5266C9C0.80809@oracle.com> Hi, Sergey, this version looks fine. Thanks, Artem On 10/22/2013 3:19 PM, Sergey Bylokhov wrote: > New version here: > http://cr.openjdk.java.net/~serb/7090424/webrev.02/ > > On 22.10.2013 13:52, Anthony Petrov wrote: >> Hi Sergey, >> >> Sorry, but I can't review a fix w/o a webrev. >> >> What kind of problems do you experience with the tool? The cr.openjdk >> should now have enough free space to host new webrevs. Please try to >> re-upload the new webrev. >> >> -- >> best regards, >> Anthony >> >> On 10/22/2013 12:28 PM, Sergey Bylokhov wrote: >>> I have a problem with the review tool. I assume that version .00 with >>> removed volatiles and renamed handleexpose event is ok for everybody? >>> >>> On 10/21/13 4:53 PM, Sergey Bylokhov wrote: >>>> Hi, Anthony. >>>> Since cr have some issues with the space. I upload 2 files, where >>>> handleExposeEvent was renamed to postPaintEvent(): >>>> >>>> http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XWindow.java.sdiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~serb/7090424/webrev%2c01/src/solaris/classes/sun/awt/X11/XContentWindow.java.sdiff.html >>>> >>>> >>>> >>>> On 18.10.2013 15:47, Sergey Bylokhov wrote: >>>>> Hi, Anthony. >>>>> On 18.10.2013 15:17, Anthony Petrov wrote: >>>>>> Hi Sergey, >>>>>> >>>>>> In XAWT, we usually use the StateLock to synchronize access to peer >>>>>> fields (such as background, label, etc.) I don't think that >>>>>> switching to volatile is a good idea since it prevents us from >>>>>> performing atomic read/writes to the fields. And this is exactly >>>>>> what we need for this fix, actually. In other words, the following >>>>>> pattern works perfectly: >>>>>> >>>>>> synchronized (lock) { >>>>>> if (a != b) { >>>>>> a = b; >>>>>> // do stuff, or set a flag to do it later w/o the lock >>>>>> } >>>>>> } >>>>>> >>>>>> whereas the following doesn't: >>>>>> >>>>>> volatile a; >>>>>> if (a != b) { >>>>>> a = b; >>>>>> // do stuff >>>>>> } >>>>>> >>>>>> The latter doesn't work because the value of 'a' may change from >>>>>> another thread after the if() statement in the first thread is >>>>>> executed. >>>>> If it will be changed that's ok. It is safe in this context since >>>>> there is no races. a will be the latest setted value and repaint >>>>> action will be done after a was set. Non trivial setters(like >>>>> setLabel/setText) are called under the locks in shared code. >>>>>> >>>>>> Please note that this is critical for AWT because it is a >>>>>> multi-threaded GUI toolkit. >>>>>> >>>>>> src/solaris/classes/sun/awt/X11/XListPeer.java >>>>>>> - target.paint(g); >>>>>>> + handleExposeEvent(target, 0, 0, getWidth(), >>>>>>> getHeight()); >>>>>> >>>>>> (the same applies to XWindow.repaint): can you please rename >>>>>> XWindow.handleExposeEvent(Component...) to postPaintEvent() and make >>>>>> it final? A good javadoc for this method would also be appreciated, >>>>>> because currently seeing the name handle*() I'd think it needs to be >>>>>> done under the awtLock(). >>>>> Will do. >>>>>> >>>>>> Also, for the corresponding changes in XWindow.repaint(), could you >>>>>> please elaborate a bit more? Looking at the code I see that >>>>>> XWindow.paint() calls paintPeer(). And in repaint(), you either call >>>>>> paint() or paintPeer() depending on the current thread. Why is it >>>>>> needed? Can we just call paintPeer() (or paint() for that matter) >>>>>> unconditionally since they both seem to result in the same call? >>>>> paintPeer is used to draw the native part of the peer(text of the >>>>> label, border of the button etc). >>>>> paint is a part of Component.paintAll(). And as a result of it call >>>>> it should paint the native part of the peer and it should call >>>>> appropriate paint method from the target. >>>>>> Also, why don't we post an event if reapint() is invoked on the EDT? >>>>> We do this in osx, but in xawt there are "smart" caches, which are >>>>> initialized during the paint of the peer. See >>>>> XLabelPeer&cachedFontMetrics for example . Note that this cache is >>>>> completely broken. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 10/16/2013 06:00 PM, Sergey Bylokhov wrote: >>>>>>> Hello. >>>>>>> Please review the fix for jdk 8. >>>>>>> The fix has two parts >>>>>>> - Repaint method in the peer now paint the component in place >>>>>>> if it >>>>>>> was called on EDT only. >>>>>>> - Most of setters were changed to stop recursion if they were >>>>>>> called >>>>>>> on EDT. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7090424 >>>>>>> Webrev can be found at: >>>>>>> http://cr.openjdk.java.net/~serb/7090424/webrev.00 >>>>>>> >>>>> >>>>> >>>> >>>> >>> >>> > > From srikalyan.chandrashekar at oracle.com Tue Oct 22 13:11:43 2013 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Tue, 22 Oct 2013 13:11:43 -0700 Subject: [OpenJDK 2D-Dev] [8] Review request for JDK-8025684 - Fix Raw and unchecked warnings java.awt.image classes In-Reply-To: <525D178D.9030301@oracle.com> References: <524B43EF.4080603@oracle.com> <524BEF41.2000304@oracle.com> <524C9AA7.6010500@oracle.com> <525C5816.5010909@oracle.com> <525D178D.9030301@oracle.com> Message-ID: <5266DBFF.40005@oracle.com> Hi 2D folks any 2nd take on this for approval? --- Thanks kalyan On 10/15/2013 3:23 AM, Artem Ananiev wrote: > > On 10/15/2013 12:46 AM, srikalyan chandrashekar wrote: >> Hi Jim, Thanks for reviewing and apologies for the delayed response, I >> have made sure to set the properties type as String -> Object but mostly >> the public constructor(OR) setter method enforces where > Object> being too loose is guaranteed to not break at runtime but >> is brittle and may break at runtime . But as you said >> if it is documented then having this hole should be OK. I have updated >> the webrev and is available in same location >> . >> > > The new version is uploaded here: > > http://cr.openjdk.java.net/~art/srikalyc/8025684.02/ > > Thanks, > > Artem > >> -- >> Thanks >> kalyan >> >> On 10/2/13 3:13 PM, Jim Graham wrote: >>> I'm not the greatest expert on generics (in particular, in terms of >>> issues of retrofitting generics into existing public code without >>> breaking compatibility), but I'll note that the properties on an image >>> were always "documented" to be String->Object, but that was well >>> before generics and so we just accepted bare hash tables everywhere. >>> Is it possible to have at least some of the declarations of various >>> properties objects to be declared as even though we >>> are loose on the acceptance criteria in various constructors - or >>> would that just completely break compatibility. I know that we use >>> type erasure so we would never break binary compatibility, but there >>> may be some places where we can have them more strongly typed >>> internally for now, but more accepting at the external API level and >>> then possibly consider improving the externally-visible typing in >>> future versions when a source incompatibility is more appropriate? >>> >>> (I'm asking because I don't understand all of the compatibility issues >>> that this might cause...) >>> >>> ...jim >>> >>> On 10/2/13 3:02 AM, Artem Ananiev wrote: >>>> >>>> java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to >>>> CC. Please, wait for at least one approval from Java2D team. >>>> >>>> For easier review, I put the webrev here: >>>> >>>> http://cr.openjdk.java.net/~art/srikalyc/8025684.00/ >>>> >>>> It looks fine to me. There is one "unchecked" warning still left, at >>>> BufferedImage.java:645, it can be fixed by introducing a local >>>> variable >>>> and @SuppressWarnings("unchecked"), but I'm not sure it's worth doing. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 10/2/2013 1:51 AM, srikalyan chandrashekar wrote: >>>>> Hi team , could someone review the fix >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8025684 >>>>> Webrev : >>>>> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.image.raw_unchecked_webrev.zip >>>>> >>>>> >>>>> >>>>> >>>>> Fix : Raw and unchecked warnings in AWT image classes fixed >>>>> >> From david.dehaven at oracle.com Tue Oct 22 20:27:32 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 22 Oct 2013 20:27:32 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5266C65A.6070403@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <7F14B1EF-457C-45F3-8AAA-19DC365EB065@oracle.com> <5266C65A.6070403@oracle.com> Message-ID: Ok, I tried: PreferredToolkit prefToolkit = getPreferredToolkit(); if (prefToolkit == HToolkit) { sprops.awt_headless = "true"; } after adding awt_headless to the props struct and it works OK. The only issue is that in a non-GUI login there's a big fat warning: 2013-10-22 20:25:08.489 java[12267:707] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode. You don't see that if you specify java.awt.headless on the command line. It seems to be benign, not sure if there will be any long term impact or not. I'll update the webrev and post it. -DrD- > I think that triggering java.awt.headless=true is enough. The class instance wrapping will be done automatically in java.awt.Toolkit.getDefaultToolkit(). > > A reliable way to test it is, I guess, as follows: log out of your GUI session, ssh to the Mac box, and try running a headless app (e.g. a printing jtreg test.) > > -- > best regards, > Anthony > > On 10/22/2013 10:15 PM, David DeHaven wrote: >> >> [removing hotspot-dev and build-dev..] >> >> I can't look at the code at the moment as I'm focused on something else... Does the wrapping happen automagically at some point based on java.awt.headless? It doesn't look trivial to do this from within the scope of java_props_md.c, it seems the best I could do from there is trigger java.awt.headless=true if we're not in a headful login session. It would be fairly simple to have it set java.awt.headless if the logic is there to do the HeadlessToolkit wrapping, and that's something that could be done for all platforms (though only Mac would use it for the moment). >> >> Otherwise I can just revert it back to my original version and we can continue using HToolkit for now. >> >> With the current code, JTREG fails massively in headless mode (due to most calls throwing a HeadlessException) and JPRT performs horribly when running the jdk_awt tests due to it not running in an Aqua session. Is there some reliable way of testing headless mode? >> >> -DrD- >> >>> Hello. >>> I suppose we should request from sqe team to run the jck tests in the "true" headless mode via ssh(w/o headless option and w/o access to Aqua session). >>> >>> On 22.10.2013 21:54, Anthony Petrov wrote: >>>> We don't have to. IIRC, the choice of HToolkit on Mac was made by chance. >>>> >>>> Since we must load the lwawt lib in headless on Mac anyway, we may as well use the CToolkit (properly wrapped in the HeadlessToolkit). But there's no need to continue to use the HToolkit on Mac. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/22/2013 08:22 PM, Leonid Romanov wrote: >>>>> There was a discussion why we use HToolkit instead of HeadlessToolkit: >>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html >>>>> >>>>> So we might want to continue using it. >>>>> >>>>> Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() >>>>> >>>>> On Oct 22, 2013, at 1:23 PM, Artem Ananiev wrote: >>>>> >>>>>> Hi, David, >>>>>> >>>>>> thanks for additional cleanup. >>>>>> >>>>>> I have only one concern. Before the fix, we checked if there is an active Aqua session. When no session was found, we falled back to HToolkit. I think this logic should be preserved, but slightly corrected: fall back to HeadlessToolkit (with CToolkit wrapped in). >>>>>> >>>>>> Otherwise the only way to run headless on Mac will be to force it with the system property. It works this way on Windows, but on Windows we're sure that WToolkit can run even without a UI session. Is it also true on Mac? Did you try to launch AWT without -Djava.awt.headless=true from remote console with no users logged in? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>> On 10/22/2013 7:34 AM, David DeHaven wrote: >>>>>>> >>>>>>> Updated webrev for JDK (hotspot change is the same): >>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ >>>>>>> >>>>>>> Changes since last version: >>>>>>> - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk >>>>>>> - Removed HToolkit option and toolkit selection code from java_props_macosx.[ch] >>>>>>> >>>>>>> -DrD- >>>>>>> >>>>>>> >>>>>>>> I want to do one more iteration of this. Based on feedback it seems I can remove a bit more code from java_props_macosx.[ch] and make things a bit cleaner. >>>>>>>> >>>>>>>> -DrD- >>>>>>>> >>>>>>>>> Thanks guys. >>>>>>>>> >>>>>>>>> Anthony, can you sponsor this for me? >>>>>>>>> >>>>>>>>> -DrD- >>>>>>>>> >>>>>>>>>> This fix looks fine to me as well. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> best regards, >>>>>>>>>> Anthony >>>>>>>>>> >>>>>>>>>> On 10/20/2013 11:56 PM, David DeHaven wrote: >>>>>>>>>>> >>>>>>>>>>> CCing: build-dev, macosx-port-dev, hotspot-dev >>>>>>>>>>> >>>>>>>>>>> Request for review of JDK-8025673: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025673 >>>>>>>>>>> >>>>>>>>>>> Proposed changes: >>>>>>>>>>> http://cr.openjdk.java.net/~ddehaven/8025673/ >>>>>>>>>>> >>>>>>>>>>> This change disables building libawt_xawt.dylib and libawt_headless.dylib on Mac since they are not used and not supported. There are too many challenges (and not enough time) in removing all X11 code from the Mac build at this time, so we're deferring complete removal for later (will be covered by JDK-8003900). >>>>>>>>>>> >>>>>>>>>>> A small change to hotspot is required as it was looking for libawt_xawt.dylib and if not found would set java.awt.headless to true. Since we don't build a headless only JRE on Mac I just have that method return false. I'm not sure how to handle changes to hotspot, can it be pushed along with the jdk changes? Without that change the Mac builds will be broken. >>>>>>>>>>> >>>>>>>>>>> Significant build system changes, build-dev guys are encouraged to comment... >>>>>>>>>>> >>>>>>>>>>> I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that broke JNI header generation on platforms still using X11 and I couldn't use the big list of excluded files on Mac as that resulted in Java compilation errors, so I just added some logic to exclude everything on Mac and left the list in place everywhere else. >>>>>>>>>>> >>>>>>>>>>> The changes to CompileNativeLibraries.gmk will port to libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the jdk8/build workspace where the build cannot find symbols in JNI libs so that issue needs to be resolved first. I've not had time to investigate that problem. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Question for the AWT team, we still have this in java_props_md.c: >>>>>>>>>>> 458 PreferredToolkit prefToolkit = getPreferredToolkit(); >>>>>>>>>>> 459 if (prefToolkit == CToolkit) { >>>>>>>>>>> 460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit"; >>>>>>>>>>> 461 } else { >>>>>>>>>>> 462 // TODO: do we still need this? >>>>>>>>>>> 463 sprops.awt_toolkit = "sun.awt.HToolkit"; >>>>>>>>>>> 464 } >>>>>>>>>>> >>>>>>>>>>> Is that necessary? Since we're now using libawt_lwawt in both headless and headful modes I would think we could remove the HToolkit option, but I'm not 100% certain about that. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be working fine. >>>>>>>>>>> >>>>>>>>>>> JPRT run for Mac is in progress, I will submit one for all other platforms when it finishes building. >>>>>>>>>>> >>>>>>>>>>> -DrD- >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> From david.dehaven at oracle.com Tue Oct 22 21:10:49 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 22 Oct 2013 21:10:49 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5266BD67.4010101@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> Message-ID: <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> Updated webrev: http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/ Summary of changes since last: - Added awt_headless to java_props_t (set to NULL by default which does not set the property) - Replaced the toolkit selection code in java_props_macosx.[ch]. I could have just exposed isAquaSession but I wanted to preserve the AWT_TOOLKIT environment variable support (no idea if it's actually used or not...). - Modified WrappedToolkitTest.sh to check that it's wrapping LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless jtreg tests pass. No build system or hotspot changes since the last patch. -DrD- From david.holmes at oracle.com Tue Oct 22 21:52:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Oct 2013 14:52:26 +1000 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> Message-ID: <5267560A.1010800@oracle.com> On 23/10/2013 2:10 PM, David DeHaven wrote: > > Updated webrev: > > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/ > > Summary of changes since last: > - Added awt_headless to java_props_t (set to NULL by default which does not set the property) Not sure about this part. We already force this property to be set in Embedded without needing any changes in the code you have modified and I'm not sure if your changes will break what we already do. Why do you need to do it? I'm getting concerned about this change touching stuff outside of OSX. David > - Replaced the toolkit selection code in java_props_macosx.[ch]. I could have just exposed isAquaSession but I wanted to preserve the AWT_TOOLKIT environment variable support (no idea if it's actually used or not...). > - Modified WrappedToolkitTest.sh to check that it's wrapping LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless jtreg tests pass. > > No build system or hotspot changes since the last patch. > > -DrD- > From petr.pchelko at oracle.com Wed Oct 23 01:43:07 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 23 Oct 2013 12:43:07 +0400 Subject: [8] Review Request: JDK-8027025 [macosx] getLocationOnScreen returns 0 if parent invisible Message-ID: Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8027025 The fix is available at: http://cr.openjdk.java.net/~pchelko/8027025/webrev.00/ The problem: When initializing the peer's location and bounds we rely on the initial move/resize event. However if the undecorated frame is created right at the center of the screen this initial event does not come. My testing shows that this is an only situation. The solution: We revert the changes in JDK-8007219 for undecorated frames. The initial position is a 0-0-1-1 stub, the real position is set later during the initialization. I don't want to do that for decorated frames as 1. this is not needed 2. the native maximize button starts working ugly in some cases. With best regards. Petr. From anthony.petrov at oracle.com Wed Oct 23 01:56:01 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 23 Oct 2013 12:56:01 +0400 Subject: [8] Review Request: JDK-8027025 [macosx] getLocationOnScreen returns 0 if parent invisible In-Reply-To: References: Message-ID: <52678F21.3010305@oracle.com> Hi Petr, What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames? Also, at [1] Alexander said: > The problem was that NSWindow is created with zero bounds and then > actual bounds are set. > In this case NSWindow treats big bounds as zoomed state and next zoom > move the window to initial zero bounds. I'm wondering, won't the same scenario fail for undecorated windows after your fix, just reverting them back to 0x0/1x1 instead of 0x0/0x0? [1] http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005469.html -- best regards, Anthony On 10/23/2013 12:43 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8027025 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/8027025/webrev.00/ > > The problem: > When initializing the peer's location and bounds we rely on the initial move/resize event. However if the undecorated frame is created right at the center of the screen this initial event does not come. > My testing shows that this is an only situation. > > The solution: > We revert the changes in JDK-8007219 for undecorated frames. The initial position is a 0-0-1-1 stub, the real position is set later during the initialization. > I don't want to do that for decorated frames as 1. this is not needed 2. the native maximize button starts working ugly in some cases. > > With best regards. Petr. > From petr.pchelko at oracle.com Wed Oct 23 02:05:28 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 23 Oct 2013 13:05:28 +0400 Subject: [8] Review Request: JDK-8027025 [macosx] getLocationOnScreen returns 0 if parent invisible In-Reply-To: <52678F21.3010305@oracle.com> References: <52678F21.3010305@oracle.com> Message-ID: <4957D0F3-3B21-4701-9FC4-285512B114EE@oracle.com> Hello, Anthony. > What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames? Yes. The decorated frame is receiving the initial move/resize event. I suppose it's somehow moved(resized) be adding the window decorations, but this is only a guess. With best regards. Petr. On 23.10.2013, at 12:56, Anthony Petrov wrote: > Hi Petr, > > What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames? > > Also, at [1] Alexander said: >> The problem was that NSWindow is created with zero bounds and then >> actual bounds are set. >> In this case NSWindow treats big bounds as zoomed state and next zoom >> move the window to initial zero bounds. > > I'm wondering, won't the same scenario fail for undecorated windows after your fix, just reverting them back to 0x0/1x1 instead of 0x0/0x0? > > [1] http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005469.html > > -- > best regards, > Anthony > > On 10/23/2013 12:43 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8027025 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/8027025/webrev.00/ >> >> The problem: >> When initializing the peer's location and bounds we rely on the initial move/resize event. However if the undecorated frame is created right at the center of the screen this initial event does not come. >> My testing shows that this is an only situation. >> >> The solution: >> We revert the changes in JDK-8007219 for undecorated frames. The initial position is a 0-0-1-1 stub, the real position is set later during the initialization. >> I don't want to do that for decorated frames as 1. this is not needed 2. the native maximize button starts working ugly in some cases. >> >> With best regards. Petr. >> From sergey.bylokhov at oracle.com Wed Oct 23 05:31:14 2013 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Wed, 23 Oct 2013 12:31:14 +0000 Subject: hg: jdk8/awt/jdk: 8020851: java.awt.event.WindowEvent spec should state that WINDOW_CLOSED event may not be delivered under certain circumstances Message-ID: <20131023123256.6F3DB62682@hg.openjdk.java.net> Changeset: 4ad826a08e6f Author: serb Date: 2013-10-23 16:24 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4ad826a08e6f 8020851: java.awt.event.WindowEvent spec should state that WINDOW_CLOSED event may not be delivered under certain circumstances Reviewed-by: anthony, art ! src/share/classes/java/awt/event/WindowEvent.java From anthony.petrov at oracle.com Wed Oct 23 05:34:15 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 23 Oct 2013 16:34:15 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5267560A.1010800@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> Message-ID: <5267C247.7040708@oracle.com> On 10/23/2013 08:52 AM, David Holmes wrote: > On 23/10/2013 2:10 PM, David DeHaven wrote: >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/ >> >> Summary of changes since last: >> - Added awt_headless to java_props_t (set to NULL by default which >> does not set the property) > > Not sure about this part. We already force this property to be set in > Embedded without needing any changes in the code you have modified and > I'm not sure if your changes will break what we already do. Why do you > need to do it? > > I'm getting concerned about this change touching stuff outside of OSX. I think I agree with David. E.g. I'm not sure I like changing j/l/System.c for this fix. Given the time constraints, perhaps going with HToolkit would be a good enough solution for now? Artem, what's your opinion? -- best regards, Anthony > > David > >> - Replaced the toolkit selection code in java_props_macosx.[ch]. I >> could have just exposed isAquaSession but I wanted to preserve the >> AWT_TOOLKIT environment variable support (no idea if it's actually >> used or not...). >> - Modified WrappedToolkitTest.sh to check that it's wrapping >> LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless >> jtreg tests pass. >> >> No build system or hotspot changes since the last patch. >> >> -DrD- >> From anton.tarasov at oracle.com Wed Oct 23 11:15:07 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 23 Oct 2013 22:15:07 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow Message-ID: <5268122B.9010105@oracle.com> Hello, Please, review the fix: jira: https://bugs.openjdk.java.net/browse/JDK-8027157 webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 This is to support SwingNode. On Windows, in the interop mode, when a popup (JWindow) is shown it doesn't get WM_PAINT native message. The message should trigger adding a dirty component to RepaintManager that will eventually paint it. Currently, a popup is shown blank. Please, see https://javafx-jira.kenai.com/browse/RT-32570 for more details. The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a window owned by JLightweightFrame. Thanks, Anton. From artem.ananiev at oracle.com Wed Oct 23 07:52:38 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 23 Oct 2013 18:52:38 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5268122B.9010105@oracle.com> References: <5268122B.9010105@oracle.com> Message-ID: <5267E2B6.4090105@oracle.com> Hi, Anton, can this code be moved to WLightweightFramePeer? It would help to get rid of the nasty instanceof check. Thanks, Artem On 10/23/2013 10:15 PM, Anton V. Tarasov wrote: > Hello, > > Please, review the fix: > > jira: https://bugs.openjdk.java.net/browse/JDK-8027157 > webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 > > This is to support SwingNode. On Windows, in the interop mode, when a > popup (JWindow) is shown it doesn't get WM_PAINT native message. > The message should trigger adding a dirty component to RepaintManager > that will eventually paint it. > Currently, a popup is shown blank. Please, see > https://javafx-jira.kenai.com/browse/RT-32570 for more details. > > The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a > window owned by JLightweightFrame. > > Thanks, > Anton. From artem.ananiev at oracle.com Wed Oct 23 08:11:47 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 23 Oct 2013 19:11:47 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5267C247.7040708@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> Message-ID: <5267E733.8010905@oracle.com> On 10/23/2013 4:34 PM, Anthony Petrov wrote: > On 10/23/2013 08:52 AM, David Holmes wrote: >> On 23/10/2013 2:10 PM, David DeHaven wrote: >>> >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/ >>> >>> Summary of changes since last: >>> - Added awt_headless to java_props_t (set to NULL by default which >>> does not set the property) >> >> Not sure about this part. We already force this property to be set in >> Embedded without needing any changes in the code you have modified and >> I'm not sure if your changes will break what we already do. Why do you >> need to do it? >> >> I'm getting concerned about this change touching stuff outside of OSX. > > I think I agree with David. E.g. I'm not sure I like changing > j/l/System.c for this fix. > > Given the time constraints, perhaps going with HToolkit would be a good > enough solution for now? > > Artem, what's your opinion? I'm personally fine with the current version. The fix is now Mac OS X specific, as sprops.awt_headless is only set within #ifdef MACOSX, it won't have any impact on other platforms. At the same time it enables headless functionality on Mac OS X, while HToolkit doesn't. Note that it can be improved further. As it stands now, the only purpose of getPreferredToolkit() is to check if Aqua session is active. The toolkit we use is always CToolkit, regardless of what this method returns, so the method can be removed, and isInAquaSession() can be called instead. Leaving this further cleanup up to David D., though. Thanks, Artem > -- > best regards, > Anthony > >> >> David >> >>> - Replaced the toolkit selection code in java_props_macosx.[ch]. I >>> could have just exposed isAquaSession but I wanted to preserve the >>> AWT_TOOLKIT environment variable support (no idea if it's actually >>> used or not...). >>> - Modified WrappedToolkitTest.sh to check that it's wrapping >>> LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless >>> jtreg tests pass. >>> >>> No build system or hotspot changes since the last patch. >>> >>> -DrD- >>> From alexandr.scherbatiy at oracle.com Wed Oct 23 08:24:05 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 23 Oct 2013 19:24:05 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <52664607.2090807@oracle.com> References: <52664607.2090807@oracle.com> Message-ID: <5267EA15.1080103@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/ The JCK failures has been resolved: - Some tests tries to draw an image with Integer.MAX_VALUE width or height. Passing large values to image.getScaledImage(width, height, hints). leads that an Image filter is not able to create necessary arrays. The fix uses the original image if width or height are equal to Integer.MAX_VALUE. - Using Image.SCALE_DEFAULT hint for the getScaledImage(width, height, hints) method to get the high resolution image interferes with JCK tests that expect that the scaled image by certain algorithm is returned. This is fixed by invoking the super.getScaledImage(width, height, hints) method in ToolkitImage in case if a high resolution image is not set. Thanks, Alexandr. On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8011059 > webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 > > The IMAGE_SCALING rendering hint is added to the RenderingHints class. > Enabling the image scaling rendering hint forces the SunGraphics2D > to use getScaledInstance(width, height, hints) method > from Image class with SCALE_DEFAULT hint. > > By default the image scaling rendering hint is enabled on HiDPI > display and disabled for standard displays. > > User can override the getScaledInstance(width, height, hints) method > and return necessary high resolution image > according to the given image width and height. > > For example: > --------------------- > final Image highResolutionImage = > new BufferedImage(2 * WIDTH, 2 * HEIGHT, > BufferedImage.TYPE_INT_RGB); > Image image = new BufferedImage(WIDTH, HEIGHT, > BufferedImage.TYPE_INT_RGB) { > > @Override > public Image getScaledInstance(int width, int height, int > hints) { > if ((hints & Image.SCALE_DEFAULT) != 0) { > return (width <= WIDTH && height <= HEIGHT) > ? this : highResolutionImage; > } > return super.getScaledInstance(width, height, hints); > } > }; > --------------------- > > The LWCToolkit and ToolkitImage classes are patched to automatically > get provided image at 2x.ext images on MacOSX. > > There are no significant changes in the Java2D demo to make it look > perfect on Retina displays. > It needs only to put necessary images with the @2x postfix and they > will be automatically drawn. > > Thanks, > Alexandr. > From anthony.petrov at oracle.com Wed Oct 23 09:24:59 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 23 Oct 2013 20:24:59 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5267E733.8010905@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> Message-ID: <5267F85B.8090509@oracle.com> On 10/23/2013 07:11 PM, Artem Ananiev wrote: > > On 10/23/2013 4:34 PM, Anthony Petrov wrote: >> On 10/23/2013 08:52 AM, David Holmes wrote: >>> On 23/10/2013 2:10 PM, David DeHaven wrote: >>>> >>>> Updated webrev: >>>> >>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/ >>>> >>>> Summary of changes since last: >>>> - Added awt_headless to java_props_t (set to NULL by default which >>>> does not set the property) >>> >>> Not sure about this part. We already force this property to be set in >>> Embedded without needing any changes in the code you have modified and >>> I'm not sure if your changes will break what we already do. Why do you >>> need to do it? >>> >>> I'm getting concerned about this change touching stuff outside of OSX. >> >> I think I agree with David. E.g. I'm not sure I like changing >> j/l/System.c for this fix. >> >> Given the time constraints, perhaps going with HToolkit would be a good >> enough solution for now? >> >> Artem, what's your opinion? > > I'm personally fine with the current version. The fix is now Mac OS X > specific, as sprops.awt_headless is only set within #ifdef MACOSX, it Well, we also need to make sure it's always initialized. I assume the whole sprops structure is zeroed out somewhere? If so, then everything looks fine. > won't have any impact on other platforms. At the same time it enables > headless functionality on Mac OS X, while HToolkit doesn't. > > Note that it can be improved further. As it stands now, the only purpose > of getPreferredToolkit() is to check if Aqua session is active. The > toolkit we use is always CToolkit, regardless of what this method > returns, so the method can be removed, and isInAquaSession() can be > called instead. Leaving this further cleanup up to David D., though. Thanks Artem. I'm OK with the current fix, too, then. -- best regards, Anthony > > Thanks, > > Artem > >> -- >> best regards, >> Anthony >> >>> >>> David >>> >>>> - Replaced the toolkit selection code in java_props_macosx.[ch]. I >>>> could have just exposed isAquaSession but I wanted to preserve the >>>> AWT_TOOLKIT environment variable support (no idea if it's actually >>>> used or not...). >>>> - Modified WrappedToolkitTest.sh to check that it's wrapping >>>> LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless >>>> jtreg tests pass. >>>> >>>> No build system or hotspot changes since the last patch. >>>> >>>> -DrD- >>>> From anthony.petrov at oracle.com Wed Oct 23 09:37:55 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 23 Oct 2013 20:37:55 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5268122B.9010105@oracle.com> References: <5268122B.9010105@oracle.com> Message-ID: <5267FB63.1040104@oracle.com> Hi Anton, Not sure if this matters much, but normally we don't use *.swing.* classes directly from *.awt.* classes to avoid inter-dependencies. It would look better if you could use an approach based on the Class.getName()/Class.getSuperClass() methods here. Also, I don't quite understand why "in case of interop WM_PAINT is never triggered". W/o understanding this, I'm not sure if the current fix is correct. Please elaborate on the root cause of the bug. -- best regards, Anthony On 10/23/2013 10:15 PM, Anton V. Tarasov wrote: > Hello, > > Please, review the fix: > > jira: https://bugs.openjdk.java.net/browse/JDK-8027157 > webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 > > This is to support SwingNode. On Windows, in the interop mode, when a > popup (JWindow) is shown it doesn't get WM_PAINT native message. > The message should trigger adding a dirty component to RepaintManager > that will eventually paint it. > Currently, a popup is shown blank. Please, see > https://javafx-jira.kenai.com/browse/RT-32570 for more details. > > The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a > window owned by JLightweightFrame. > > Thanks, > Anton. From david.dehaven at oracle.com Wed Oct 23 09:49:09 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 23 Oct 2013 09:49:09 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5267E733.8010905@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> Message-ID: <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> >>> Not sure about this part. We already force this property to be set in >>> Embedded without needing any changes in the code you have modified and >>> I'm not sure if your changes will break what we already do. Why do you >>> need to do it? >>> >>> I'm getting concerned about this change touching stuff outside of OSX. >> >> I think I agree with David. E.g. I'm not sure I like changing >> j/l/System.c for this fix. >> >> Given the time constraints, perhaps going with HToolkit would be a good >> enough solution for now? >> >> Artem, what's your opinion? > > I'm personally fine with the current version. The fix is now Mac OS X specific, as sprops.awt_headless is only set within #ifdef MACOSX, it won't have any impact on other platforms. At the same time it enables headless functionality on Mac OS X, while HToolkit doesn't. > > Note that it can be improved further. As it stands now, the only purpose of getPreferredToolkit() is to check if Aqua session is active. The toolkit we use is always CToolkit, regardless of what this method returns, so the method can be removed, and isInAquaSession() can be called instead. Leaving this further cleanup up to David D., though. The only reason I left it in there was for the AWT_TOOLKIT environment variable support. Right now if you set AWT_TOOLKIT to HToolkit it will start in headless mode regardless of what isAquaSession() returns. If we don't care about that then I'll happily remove it (I'm asking because I don't know if it's used or not). For example: $ AWT_TOOLKIT=HToolkit ./build/macosx-x86_64-normal-server-release/jdk/bin/java -jar ~/Desktop/SwingSet2.jar 2013-10-23 09:26:21.726 java[23276:707] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode. Exception in thread "main" java.awt.HeadlessException at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) at SwingSet2.main(SwingSet2.java:224) But it's *only* implemented on Mac OS X so it doesn't appear to be all that useful unless we want it implemented for other platforms, which would be a whole separate issue. Another option (I think would make everyone happy) would be to add a native method to LWCToolkit.{java,m} that implements isAquaSession and returns a boolean. Call this new method in the static initializer and use it's return value to set java.awt.headless before calling initIDs. This will still be done early enough that Toolkit.java will end up wrapping LWCToolkit in a HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks to see if it needs to be wrapped. Then all that code in java_props* and System.c could be removed. -DrD- From anthony.petrov at oracle.com Wed Oct 23 09:54:05 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 23 Oct 2013 20:54:05 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> Message-ID: <5267FF2D.5060804@oracle.com> On 10/23/2013 08:49 PM, David DeHaven wrote: >>>> Not sure about this part. We already force this property to be set in >>>> Embedded without needing any changes in the code you have modified and >>>> I'm not sure if your changes will break what we already do. Why do you >>>> need to do it? >>>> >>>> I'm getting concerned about this change touching stuff outside of OSX. >>> >>> I think I agree with David. E.g. I'm not sure I like changing >>> j/l/System.c for this fix. >>> >>> Given the time constraints, perhaps going with HToolkit would be a good >>> enough solution for now? >>> >>> Artem, what's your opinion? >> >> I'm personally fine with the current version. The fix is now Mac OS X specific, as sprops.awt_headless is only set within #ifdef MACOSX, it won't have any impact on other platforms. At the same time it enables headless functionality on Mac OS X, while HToolkit doesn't. >> >> Note that it can be improved further. As it stands now, the only purpose of getPreferredToolkit() is to check if Aqua session is active. The toolkit we use is always CToolkit, regardless of what this method returns, so the method can be removed, and isInAquaSession() can be called instead. Leaving this further cleanup up to David D., though. > > The only reason I left it in there was for the AWT_TOOLKIT environment variable support. Right now if you set AWT_TOOLKIT to HToolkit it will start in headless mode regardless of what isAquaSession() returns. If we don't care about that then I'll happily remove it (I'm asking because I don't know if it's used or not). > > For example: > $ AWT_TOOLKIT=HToolkit ./build/macosx-x86_64-normal-server-release/jdk/bin/java -jar ~/Desktop/SwingSet2.jar > 2013-10-23 09:26:21.726 java[23276:707] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode. > Exception in thread "main" java.awt.HeadlessException > at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) > at SwingSet2.main(SwingSet2.java:224) > > But it's *only* implemented on Mac OS X so it doesn't appear to be all that useful unless we want it implemented for other platforms, which would be a whole separate issue. There's a documented way to choose a toolkit: it is the awt.toolkit system property. We don't care about AWT_TOOLKIT anymore. It was only relevant at the time of 1.5 and 1.6 to allow users to switch between MToolkit and XToolkit. Now that MToolkit is gone, this environment variable isn't needed. > Another option (I think would make everyone happy) would be to add a native method to LWCToolkit.{java,m} that implements isAquaSession and returns a boolean. Call this new method in the static initializer and use it's return value to set java.awt.headless before calling initIDs. This will still be done early enough that Toolkit.java will end up wrapping LWCToolkit in a HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks to see if it needs to be wrapped. Then all that code in java_props* and System.c could be removed. I like this idea. But it needs testing. -- best regards, Anthony From david.dehaven at oracle.com Wed Oct 23 10:00:24 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 23 Oct 2013 10:00:24 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5267FF2D.5060804@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> <5267FF2D.5060804@oracle.com> Message-ID: >> The only reason I left it in there was for the AWT_TOOLKIT environment variable support. Right now if you set AWT_TOOLKIT to HToolkit it will start in headless mode regardless of what isAquaSession() returns. If we don't care about that then I'll happily remove it (I'm asking because I don't know if it's used or not). >> >> For example: >> $ AWT_TOOLKIT=HToolkit ./build/macosx-x86_64-normal-server-release/jdk/bin/java -jar ~/Desktop/SwingSet2.jar >> 2013-10-23 09:26:21.726 java[23276:707] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode. >> Exception in thread "main" java.awt.HeadlessException >> at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) >> at SwingSet2.main(SwingSet2.java:224) >> >> But it's *only* implemented on Mac OS X so it doesn't appear to be all that useful unless we want it implemented for other platforms, which would be a whole separate issue. > > There's a documented way to choose a toolkit: it is the awt.toolkit system property. > > We don't care about AWT_TOOLKIT anymore. It was only relevant at the time of 1.5 and 1.6 to allow users to switch between MToolkit and XToolkit. Now that MToolkit is gone, this environment variable isn't needed. Ah, ok. That makes sense. In that case we can nuke most of what I just put back :) >> Another option (I think would make everyone happy) would be to add a native method to LWCToolkit.{java,m} that implements isAquaSession and returns a boolean. Call this new method in the static initializer and use it's return value to set java.awt.headless before calling initIDs. This will still be done early enough that Toolkit.java will end up wrapping LWCToolkit in a HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks to see if it needs to be wrapped. Then all that code in java_props* and System.c could be removed. > > I like this idea. But it needs testing. Cool, I'll poke at it when I get a chance. -DrD- From david.holmes at oracle.com Wed Oct 23 19:01:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Oct 2013 12:01:56 +1000 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5267E733.8010905@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> Message-ID: <52687F94.2010307@oracle.com> On 24/10/2013 1:11 AM, Artem Ananiev wrote: > > On 10/23/2013 4:34 PM, Anthony Petrov wrote: >> On 10/23/2013 08:52 AM, David Holmes wrote: >>> On 23/10/2013 2:10 PM, David DeHaven wrote: >>>> >>>> Updated webrev: >>>> >>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/ >>>> >>>> Summary of changes since last: >>>> - Added awt_headless to java_props_t (set to NULL by default which >>>> does not set the property) >>> >>> Not sure about this part. We already force this property to be set in >>> Embedded without needing any changes in the code you have modified and >>> I'm not sure if your changes will break what we already do. Why do you >>> need to do it? >>> >>> I'm getting concerned about this change touching stuff outside of OSX. >> >> I think I agree with David. E.g. I'm not sure I like changing >> j/l/System.c for this fix. >> >> Given the time constraints, perhaps going with HToolkit would be a good >> enough solution for now? >> >> Artem, what's your opinion? > > I'm personally fine with the current version. The fix is now Mac OS X > specific, as sprops.awt_headless is only set within #ifdef MACOSX, Are we looking at the same code? This change in System.c: 209 if (sprops->awt_headless) { 210 PUTPROP(props, "java.awt.headless", sprops->awt_headless); 211 } is not in any ifdef. http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/src/share/native/java/lang/System.c.frames.html David H. -------- it > won't have any impact on other platforms. At the same time it enables > headless functionality on Mac OS X, while HToolkit doesn't. > > Note that it can be improved further. As it stands now, the only purpose > of getPreferredToolkit() is to check if Aqua session is active. The > toolkit we use is always CToolkit, regardless of what this method > returns, so the method can be removed, and isInAquaSession() can be > called instead. Leaving this further cleanup up to David D., though. > > Thanks, > > Artem > >> -- >> best regards, >> Anthony >> >>> >>> David >>> >>>> - Replaced the toolkit selection code in java_props_macosx.[ch]. I >>>> could have just exposed isAquaSession but I wanted to preserve the >>>> AWT_TOOLKIT environment variable support (no idea if it's actually >>>> used or not...). >>>> - Modified WrappedToolkitTest.sh to check that it's wrapping >>>> LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless >>>> jtreg tests pass. >>>> >>>> No build system or hotspot changes since the last patch. >>>> >>>> -DrD- >>>> From david.dehaven at oracle.com Wed Oct 23 20:52:09 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 23 Oct 2013 20:52:09 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> <5267FF2D.5060804@oracle.com> Message-ID: <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> >>> Another option (I think would make everyone happy) would be to add a native method to LWCToolkit.{java,m} that implements isAquaSession and returns a boolean. Call this new method in the static initializer and use it's return value to set java.awt.headless before calling initIDs. This will still be done early enough that Toolkit.java will end up wrapping LWCToolkit in a HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks to see if it needs to be wrapped. Then all that code in java_props* and System.c could be removed. >> >> I like this idea. But it needs testing. > > Cool, I'll poke at it when I get a chance. Doesn't work in LWCToolkit, GraphicsEnvironment gets initialized first which messes things up. It sort of works in CGraphicsEnvironment. The problem there is GraphicsEnvironment.isHeadless() is called at least once prior to CGraphicsEnvironment being loaded which then caches the value (false) so just changing the system property doesn't do anything. I added a protected method to change headless and it works, but I'm not entirely happy with that approach and I'm not convinced there won't be other side effects. For one thing, what is calling isHeadless before CGE gets loaded and will it cope with the mode changing? I don't think we have time to chase down all the issues that might manifest from that change, when we know for certain the setting the property in System.c works fine. I think the safest bet at this point is to move all the java_props.awt_headless field related code into #ifdef blocks so they only exist on Mac OS X. That will address the cross-platform concern and fix this issue. I just thought it would be useful for other platforms (especially embedded) to be able to poll their environment and set themselves up accordingly... Updated (hopefully final...) webrev: http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/ Changes from last version: http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/webrev.delta/index.html (src/windows/native/java/lang/java_props_md.c only shows up because of the delta webrev, it gets reverted back to the way it was) As a side note, SplashScreen calls isHeadless and dumps a nice ugly stack trace in a non-GUI session. It does this in the existing code so that's something that'll need to be addressed as a separate issue. Also, the message returned by GraphicsEnvironment.getHeadlessMessage() isn't correct for Mac, that should either be made more generic or let the platform impl class return that string (if it's even known or loaded at the time...). -DrD- From anton.tarasov at oracle.com Thu Oct 24 03:59:12 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 24 Oct 2013 14:59:12 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5267E2B6.4090105@oracle.com> References: <5268122B.9010105@oracle.com> <5267E2B6.4090105@oracle.com> Message-ID: <5268FD80.5070103@oracle.com> Hi Artem, I'm afraid it can't. I override the show method of an _owned_ window. Thanks, Anton. On 10/23/13 6:52 PM, Artem Ananiev wrote: > Hi, Anton, > > can this code be moved to WLightweightFramePeer? It would help to get > rid of the nasty instanceof check. > > Thanks, > > Artem > > On 10/23/2013 10:15 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please, review the fix: >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >> >> This is to support SwingNode. On Windows, in the interop mode, when a >> popup (JWindow) is shown it doesn't get WM_PAINT native message. >> The message should trigger adding a dirty component to RepaintManager >> that will eventually paint it. >> Currently, a popup is shown blank. Please, see >> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >> >> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >> window owned by JLightweightFrame. >> >> Thanks, >> Anton. From anton.tarasov at oracle.com Thu Oct 24 04:06:35 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 24 Oct 2013 15:06:35 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5267FB63.1040104@oracle.com> References: <5268122B.9010105@oracle.com> <5267FB63.1040104@oracle.com> Message-ID: <5268FF3B.9070200@oracle.com> Hi Anthony, On 10/23/13 8:37 PM, Anthony Petrov wrote: > Hi Anton, > > Not sure if this matters much, but normally we don't use *.swing.* > classes directly from *.awt.* classes to avoid inter-dependencies. It > would look better if you could use an approach based on the > Class.getName()/Class.getSuperClass() methods here. Right, I missed that. Thanks. > > Also, I don't quite understand why "in case of interop WM_PAINT is > never triggered". W/o understanding this, I'm not sure if the current > fix is correct. Please elaborate on the root cause of the bug. Well, I agree we should understand why WM_PAINT is not generated. However, I'm afraid the investigation may take too much time and with no guarantee (that it can't be solved). This is a simple and, imo, harmless workaround which gets the issue solved in jfx8/jdk8. What about leaving the WM_PAINT issue open, but targeting it to the next release (when we have more time to investigate)? Thanks, Anton. > > -- > best regards, > Anthony > > On 10/23/2013 10:15 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please, review the fix: >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >> >> This is to support SwingNode. On Windows, in the interop mode, when a >> popup (JWindow) is shown it doesn't get WM_PAINT native message. >> The message should trigger adding a dirty component to RepaintManager >> that will eventually paint it. >> Currently, a popup is shown blank. Please, see >> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >> >> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >> window owned by JLightweightFrame. >> >> Thanks, >> Anton. From sergey.bylokhov at oracle.com Thu Oct 24 03:37:07 2013 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Thu, 24 Oct 2013 10:37:07 +0000 Subject: hg: jdk8/awt/jdk: 7090424: TestGlyphVectorLayout failed automately with java.lang.StackOverflowError Message-ID: <20131024103827.69574626D1@hg.openjdk.java.net> Changeset: cd2e3c63ee42 Author: serb Date: 2013-10-24 14:32 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/cd2e3c63ee42 7090424: TestGlyphVectorLayout failed automately with java.lang.StackOverflowError Reviewed-by: anthony, art ! src/solaris/classes/sun/awt/X11/XButtonPeer.java ! src/solaris/classes/sun/awt/X11/XCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XContentWindow.java ! src/solaris/classes/sun/awt/X11/XLabelPeer.java ! src/solaris/classes/sun/awt/X11/XListPeer.java ! src/solaris/classes/sun/awt/X11/XWindow.java + test/java/awt/Paint/ButtonRepaint.java + test/java/awt/Paint/CheckboxRepaint.java + test/java/awt/Paint/ExposeOnEDT.java + test/java/awt/Paint/LabelRepaint.java + test/java/awt/Paint/ListRepaint.java From anthony.petrov at oracle.com Thu Oct 24 10:00:51 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 24 Oct 2013 17:00:51 +0000 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5268FF3B.9070200@oracle.com> References: <5268122B.9010105@oracle.com> <5267FB63.1040104@oracle.com> <5268FF3B.9070200@oracle.com> Message-ID: <52695243.3070306@oracle.com> On 10/24/2013 11:06 AM, Anton V. Tarasov wrote: > On 10/23/13 8:37 PM, Anthony Petrov wrote: >> Not sure if this matters much, but normally we don't use *.swing.* >> classes directly from *.awt.* classes to avoid inter-dependencies. It >> would look better if you could use an approach based on the >> Class.getName()/Class.getSuperClass() methods here. > Right, I missed that. Thanks. Looking forward to seeing a new webrev. >> Also, I don't quite understand why "in case of interop WM_PAINT is >> never triggered". W/o understanding this, I'm not sure if the current >> fix is correct. Please elaborate on the root cause of the bug. > > Well, I agree we should understand why WM_PAINT is not generated. > However, I'm afraid the investigation may take too much time and with no > guarantee (that it can't be solved). This is a simple and, imo, harmless > workaround which gets the issue solved in jfx8/jdk8. What about leaving > the WM_PAINT issue open, but targeting it to the next release (when we > have more time to investigate)? Yes, I think this is a good option for now. -- best regards, Anthony > > Thanks, > Anton. > > >> >> -- >> best regards, >> Anthony >> >> On 10/23/2013 10:15 PM, Anton V. Tarasov wrote: >>> Hello, >>> >>> Please, review the fix: >>> >>> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >>> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >>> >>> This is to support SwingNode. On Windows, in the interop mode, when a >>> popup (JWindow) is shown it doesn't get WM_PAINT native message. >>> The message should trigger adding a dirty component to RepaintManager >>> that will eventually paint it. >>> Currently, a popup is shown blank. Please, see >>> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >>> >>> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >>> window owned by JLightweightFrame. >>> >>> Thanks, >>> Anton. > From anthony.petrov at oracle.com Thu Oct 24 10:08:34 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 24 Oct 2013 17:08:34 +0000 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> <5267FF2D.5060804@oracle.com> <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> Message-ID: <52695412.5050804@oracle.com> Hi David, The fix looks fine to me. Thanks for all your hard work. -- best regards, Anthony On 10/24/2013 03:52 AM, David DeHaven wrote: > >>>> Another option (I think would make everyone happy) would be to add a native method to LWCToolkit.{java,m} that implements isAquaSession and returns a boolean. Call this new method in the static initializer and use it's return value to set java.awt.headless before calling initIDs. This will still be done early enough that Toolkit.java will end up wrapping LWCToolkit in a HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks to see if it needs to be wrapped. Then all that code in java_props* and System.c could be removed. >>> >>> I like this idea. But it needs testing. >> >> Cool, I'll poke at it when I get a chance. > > Doesn't work in LWCToolkit, GraphicsEnvironment gets initialized first which messes things up. > > It sort of works in CGraphicsEnvironment. The problem there is GraphicsEnvironment.isHeadless() is called at least once prior to CGraphicsEnvironment being loaded which then caches the value (false) so just changing the system property doesn't do anything. I added a protected method to change headless and it works, but I'm not entirely happy with that approach and I'm not convinced there won't be other side effects. For one thing, what is calling isHeadless before CGE gets loaded and will it cope with the mode changing? I don't think we have time to chase down all the issues that might manifest from that change, when we know for certain the setting the property in System.c works fine. > > I think the safest bet at this point is to move all the java_props.awt_headless field related code into #ifdef blocks so they only exist on Mac OS X. That will address the cross-platform concern and fix this issue. I just thought it would be useful for other platforms (especially embedded) to be able to poll their environment and set themselves up accordingly... > > > Updated (hopefully final...) webrev: > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/ > > Changes from last version: > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/webrev.delta/index.html > > (src/windows/native/java/lang/java_props_md.c only shows up because of the delta webrev, it gets reverted back to the way it was) > > > As a side note, SplashScreen calls isHeadless and dumps a nice ugly stack trace in a non-GUI session. It does this in the existing code so that's something that'll need to be addressed as a separate issue. Also, the message returned by GraphicsEnvironment.getHeadlessMessage() isn't correct for Mac, that should either be made more generic or let the platform impl class return that string (if it's even known or loaded at the time...). > > -DrD- > From petr.pchelko at oracle.com Thu Oct 24 06:33:29 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 24 Oct 2013 17:33:29 +0400 Subject: [8] Review Request: JDK-8027030 AWT Multiple JVM DnD Test Failing on Linux (OEL and Ubuntu) and Solaris (Sparc and x64) Message-ID: <039125C7-EA10-47D1-A890-F2AD80A542B1@oracle.com> Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8027030 The fix is available at: http://cr.openjdk.java.net/~pchelko/8027030/webrev.00/ This is a fix for a yet another regression of the JDK-7075105. We did not handle RMI DataFlavors when converting byte arrays. With best regards. Petr. From anthony.petrov at oracle.com Thu Oct 24 06:52:12 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 24 Oct 2013 17:52:12 +0400 Subject: [8] Review Request: JDK-8027030 AWT Multiple JVM DnD Test Failing on Linux (OEL and Ubuntu) and Solaris (Sparc and x64) In-Reply-To: <039125C7-EA10-47D1-A890-F2AD80A542B1@oracle.com> References: <039125C7-EA10-47D1-A890-F2AD80A542B1@oracle.com> Message-ID: <5269260C.3040902@oracle.com> Looks fine. -- best regards, Anthony On 10/24/2013 05:33 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8027030 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/8027030/webrev.00/ > > This is a fix for a yet another regression of the JDK-7075105. We did not handle RMI DataFlavors when converting byte arrays. > > With best regards. Petr. > From Sergey.Bylokhov at oracle.com Thu Oct 24 07:00:26 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 Oct 2013 18:00:26 +0400 Subject: [8] Review Request: 7172770 Default Toolkit implementation return null value for property "awt.dynamicLayoutSupported" Message-ID: <526927FA.8020402@oracle.com> Hello. Please review the fix for jdk 8. Implementation of "dynamicLayoutSupported" now aligned to the set/getdynamicLayout which always use default toolkit. Note that we have CR to revisit all this code JDK-8024948 Bug: https://bugs.openjdk.java.net/browse/JDK-7172770 Webrev can be found at: http://cr.openjdk.java.net/~serb/7172770/webrev.00 -- Best regards, Sergey. From anthony.petrov at oracle.com Thu Oct 24 07:04:45 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 24 Oct 2013 18:04:45 +0400 Subject: [8] Review Request: JDK-8027025 [macosx] getLocationOnScreen returns 0 if parent invisible In-Reply-To: <4957D0F3-3B21-4701-9FC4-285512B114EE@oracle.com> References: <52678F21.3010305@oracle.com> <4957D0F3-3B21-4701-9FC4-285512B114EE@oracle.com> Message-ID: <526928FD.6040805@oracle.com> Hi Petr, The workaround you suggest seems to be more or less safe, so let's go with it. Please file a separate issue to investigate the setBounds/zoom code on Mac later. -- best regards, Anthony On 10/23/2013 01:05 PM, Petr Pchelko wrote: > Hello, Anthony. > >> What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames? > Yes. The decorated frame is receiving the initial move/resize event. I suppose it's somehow moved(resized) be adding the window decorations, but this is only a guess. > > With best regards. Petr. > > On 23.10.2013, at 12:56, Anthony Petrov wrote: > >> Hi Petr, >> >> What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames? >> >> Also, at [1] Alexander said: >>> The problem was that NSWindow is created with zero bounds and then >>> actual bounds are set. >>> In this case NSWindow treats big bounds as zoomed state and next zoom >>> move the window to initial zero bounds. >> >> I'm wondering, won't the same scenario fail for undecorated windows after your fix, just reverting them back to 0x0/1x1 instead of 0x0/0x0? >> >> [1] http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005469.html >> >> -- >> best regards, >> Anthony >> >> On 10/23/2013 12:43 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8027025 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/8027025/webrev.00/ >>> >>> The problem: >>> When initializing the peer's location and bounds we rely on the initial move/resize event. However if the undecorated frame is created right at the center of the screen this initial event does not come. >>> My testing shows that this is an only situation. >>> >>> The solution: >>> We revert the changes in JDK-8007219 for undecorated frames. The initial position is a 0-0-1-1 stub, the real position is set later during the initialization. >>> I don't want to do that for decorated frames as 1. this is not needed 2. the native maximize button starts working ugly in some cases. >>> >>> With best regards. Petr. >>> > From artem.ananiev at oracle.com Thu Oct 24 07:03:36 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 24 Oct 2013 18:03:36 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <52687F94.2010307@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <52687F94.2010307@oracle.com> Message-ID: <526928B8.9010106@oracle.com> On 10/24/2013 6:01 AM, David Holmes wrote: > On 24/10/2013 1:11 AM, Artem Ananiev wrote: >> >> On 10/23/2013 4:34 PM, Anthony Petrov wrote: >>> On 10/23/2013 08:52 AM, David Holmes wrote: >>>> On 23/10/2013 2:10 PM, David DeHaven wrote: >>>>> >>>>> Updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/ >>>>> >>>>> Summary of changes since last: >>>>> - Added awt_headless to java_props_t (set to NULL by default which >>>>> does not set the property) >>>> >>>> Not sure about this part. We already force this property to be set in >>>> Embedded without needing any changes in the code you have modified and >>>> I'm not sure if your changes will break what we already do. Why do you >>>> need to do it? >>>> >>>> I'm getting concerned about this change touching stuff outside of OSX. >>> >>> I think I agree with David. E.g. I'm not sure I like changing >>> j/l/System.c for this fix. >>> >>> Given the time constraints, perhaps going with HToolkit would be a good >>> enough solution for now? >>> >>> Artem, what's your opinion? >> >> I'm personally fine with the current version. The fix is now Mac OS X >> specific, as sprops.awt_headless is only set within #ifdef MACOSX, > > Are we looking at the same code? This change in System.c: I was looking at java_props_md.c. Anyway, in version .03 of the fix this block in System.c is put to #ifdef MACOSX as well. Thanks, Artem > 209 if (sprops->awt_headless) { > 210 PUTPROP(props, "java.awt.headless", sprops->awt_headless); > 211 } > > is not in any ifdef. > > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/src/share/native/java/lang/System.c.frames.html > > > David H. > -------- > > it >> won't have any impact on other platforms. At the same time it enables >> headless functionality on Mac OS X, while HToolkit doesn't. >> >> Note that it can be improved further. As it stands now, the only purpose >> of getPreferredToolkit() is to check if Aqua session is active. The >> toolkit we use is always CToolkit, regardless of what this method >> returns, so the method can be removed, and isInAquaSession() can be >> called instead. Leaving this further cleanup up to David D., though. >> >> Thanks, >> >> Artem >> >>> -- >>> best regards, >>> Anthony >>> >>>> >>>> David >>>> >>>>> - Replaced the toolkit selection code in java_props_macosx.[ch]. I >>>>> could have just exposed isAquaSession but I wanted to preserve the >>>>> AWT_TOOLKIT environment variable support (no idea if it's actually >>>>> used or not...). >>>>> - Modified WrappedToolkitTest.sh to check that it's wrapping >>>>> LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless >>>>> jtreg tests pass. >>>>> >>>>> No build system or hotspot changes since the last patch. >>>>> >>>>> -DrD- >>>>> From Sergey.Bylokhov at oracle.com Thu Oct 24 07:05:36 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 Oct 2013 18:05:36 +0400 Subject: [8] Review Request: JDK-8027030 AWT Multiple JVM DnD Test Failing on Linux (OEL and Ubuntu) and Solaris (Sparc and x64) In-Reply-To: <039125C7-EA10-47D1-A890-F2AD80A542B1@oracle.com> References: <039125C7-EA10-47D1-A890-F2AD80A542B1@oracle.com> Message-ID: <52692930.2000500@oracle.com> Hi, Petr. Should we update translateStream() as well? On 24.10.2013 17:33, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8027030 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/8027030/webrev.00/ > > This is a fix for a yet another regression of the JDK-7075105. We did not handle RMI DataFlavors when converting byte arrays. > > With best regards. Petr. -- Best regards, Sergey. From petr.pchelko at oracle.com Thu Oct 24 07:09:08 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 24 Oct 2013 18:09:08 +0400 Subject: [8] Review Request: JDK-8027030 AWT Multiple JVM DnD Test Failing on Linux (OEL and Ubuntu) and Solaris (Sparc and x64) In-Reply-To: <52692930.2000500@oracle.com> References: <039125C7-EA10-47D1-A890-F2AD80A542B1@oracle.com> <52692930.2000500@oracle.com> Message-ID: Hello, Sergey. > Should we update translateStream() as well? No, the translateStream contains this if clause. With best regards. Petr. On 24.10.2013, at 18:05, Sergey Bylokhov wrote: > Hi, Petr. > Should we update translateStream() as well? > > On 24.10.2013 17:33, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8027030 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/8027030/webrev.00/ >> >> This is a fix for a yet another regression of the JDK-7075105. We did not handle RMI DataFlavors when converting byte arrays. >> >> With best regards. Petr. > > > -- > Best regards, Sergey. > From artem.ananiev at oracle.com Thu Oct 24 07:05:36 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 24 Oct 2013 18:05:36 +0400 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> <5267FF2D.5060804@oracle.com> <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> Message-ID: <52692930.7050307@oracle.com> Hi, David, .03 looks fine. Thanks for investigation, addressing all our comments, and this cleanup in general. Artem On 10/24/2013 7:52 AM, David DeHaven wrote: > >>>> Another option (I think would make everyone happy) would be to add a native method to LWCToolkit.{java,m} that implements isAquaSession and returns a boolean. Call this new method in the static initializer and use it's return value to set java.awt.headless before calling initIDs. This will still be done early enough that Toolkit.java will end up wrapping LWCToolkit in a HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks to see if it needs to be wrapped. Then all that code in java_props* and System.c could be removed. >>> >>> I like this idea. But it needs testing. >> >> Cool, I'll poke at it when I get a chance. > > Doesn't work in LWCToolkit, GraphicsEnvironment gets initialized first which messes things up. > > It sort of works in CGraphicsEnvironment. The problem there is GraphicsEnvironment.isHeadless() is called at least once prior to CGraphicsEnvironment being loaded which then caches the value (false) so just changing the system property doesn't do anything. I added a protected method to change headless and it works, but I'm not entirely happy with that approach and I'm not convinced there won't be other side effects. For one thing, what is calling isHeadless before CGE gets loaded and will it cope with the mode changing? I don't think we have time to chase down all the issues that might manifest from that change, when we know for certain the setting the property in System.c works fine. > > I think the safest bet at this point is to move all the java_props.awt_headless field related code into #ifdef blocks so they only exist on Mac OS X. That will address the cross-platform concern and fix this issue. I just thought it would be useful for other platforms (especially embedded) to be able to poll their environment and set themselves up accordingly... > > > Updated (hopefully final...) webrev: > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/ > > Changes from last version: > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/webrev.delta/index.html > > (src/windows/native/java/lang/java_props_md.c only shows up because of the delta webrev, it gets reverted back to the way it was) > > > As a side note, SplashScreen calls isHeadless and dumps a nice ugly stack trace in a non-GUI session. It does this in the existing code so that's something that'll need to be addressed as a separate issue. Also, the message returned by GraphicsEnvironment.getHeadlessMessage() isn't correct for Mac, that should either be made more generic or let the platform impl class return that string (if it's even known or loaded at the time...). > > -DrD- > From petr.pchelko at oracle.com Thu Oct 24 07:16:09 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 24 Oct 2013 18:16:09 +0400 Subject: [8] Review Request: JDK-8027025 [macosx] getLocationOnScreen returns 0 if parent invisible In-Reply-To: <526928FD.6040805@oracle.com> References: <52678F21.3010305@oracle.com> <4957D0F3-3B21-4701-9FC4-285512B114EE@oracle.com> <526928FD.6040805@oracle.com> Message-ID: <09110C81-44E6-40AE-88FA-38C7BF97680E@oracle.com> Hello, Anthony. > Please file a separate issue to investigate the setBounds/zoom code on Mac later. I have filed https://bugs.openjdk.java.net/browse/JDK-8027250 With best regards. Petr. On 24.10.2013, at 18:04, Anthony Petrov wrote: > Hi Petr, > > The workaround you suggest seems to be more or less safe, so let's go with it. > > Please file a separate issue to investigate the setBounds/zoom code on Mac later. > > -- > best regards, > Anthony > > On 10/23/2013 01:05 PM, Petr Pchelko wrote: >> Hello, Anthony. >> >>> What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames? >> Yes. The decorated frame is receiving the initial move/resize event. I suppose it's somehow moved(resized) be adding the window decorations, but this is only a guess. >> >> With best regards. Petr. >> >> On 23.10.2013, at 12:56, Anthony Petrov wrote: >> >>> Hi Petr, >>> >>> What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames? >>> >>> Also, at [1] Alexander said: >>>> The problem was that NSWindow is created with zero bounds and then >>>> actual bounds are set. >>>> In this case NSWindow treats big bounds as zoomed state and next zoom >>>> move the window to initial zero bounds. >>> >>> I'm wondering, won't the same scenario fail for undecorated windows after your fix, just reverting them back to 0x0/1x1 instead of 0x0/0x0? >>> >>> [1] http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005469.html >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/23/2013 12:43 PM, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8027025 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/8027025/webrev.00/ >>>> >>>> The problem: >>>> When initializing the peer's location and bounds we rely on the initial move/resize event. However if the undecorated frame is created right at the center of the screen this initial event does not come. >>>> My testing shows that this is an only situation. >>>> >>>> The solution: >>>> We revert the changes in JDK-8007219 for undecorated frames. The initial position is a 0-0-1-1 stub, the real position is set later during the initialization. >>>> I don't want to do that for decorated frames as 1. this is not needed 2. the native maximize button starts working ugly in some cases. >>>> >>>> With best regards. Petr. >>>> >> From anthony.petrov at oracle.com Thu Oct 24 07:22:44 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 24 Oct 2013 18:22:44 +0400 Subject: [8] Review Request: 7172770 Default Toolkit implementation return null value for property "awt.dynamicLayoutSupported" In-Reply-To: <526927FA.8020402@oracle.com> References: <526927FA.8020402@oracle.com> Message-ID: <52692D34.2050208@oracle.com> Hi Sergey, The fix looks good to me. -- best regards, Anthony On 10/24/2013 06:00 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 8. > Implementation of "dynamicLayoutSupported" now aligned to the > set/getdynamicLayout which always use default toolkit. > Note that we have CR to revisit all this code JDK-8024948 > > Bug: https://bugs.openjdk.java.net/browse/JDK-7172770 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7172770/webrev.00 > From anton.tarasov at oracle.com Thu Oct 24 07:35:08 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 24 Oct 2013 18:35:08 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5268122B.9010105@oracle.com> References: <5268122B.9010105@oracle.com> Message-ID: <5269301C.6050205@oracle.com> Hello, Please look at the new version: http://cr.openjdk.java.net/~ant/RT-32570/webrev.1 It eliminates code dependency b/w awt & swing. Thanks, Anton. On 10/23/13 10:15 PM, Anton V. Tarasov wrote: > Hello, > > Please, review the fix: > > jira: https://bugs.openjdk.java.net/browse/JDK-8027157 > webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 > > This is to support SwingNode. On Windows, in the interop mode, when a > popup (JWindow) is shown it doesn't get WM_PAINT native message. > The message should trigger adding a dirty component to RepaintManager > that will eventually paint it. > Currently, a popup is shown blank. Please, see > https://javafx-jira.kenai.com/browse/RT-32570 for more details. > > The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a > window owned by JLightweightFrame. > > Thanks, > Anton. From artem.ananiev at oracle.com Thu Oct 24 07:59:04 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 24 Oct 2013 18:59:04 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5269301C.6050205@oracle.com> References: <5268122B.9010105@oracle.com> <5269301C.6050205@oracle.com> Message-ID: <526935B8.1020609@oracle.com> Hi, Anton, it looks much better now. Is it possible to create a regression test for this change? Thanks, Artem On 10/24/2013 6:35 PM, Anton V. Tarasov wrote: > Hello, > > Please look at the new version: > > http://cr.openjdk.java.net/~ant/RT-32570/webrev.1 > > It eliminates code dependency b/w awt & swing. > > Thanks, > Anton. > > On 10/23/13 10:15 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please, review the fix: >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >> >> This is to support SwingNode. On Windows, in the interop mode, when a >> popup (JWindow) is shown it doesn't get WM_PAINT native message. >> The message should trigger adding a dirty component to RepaintManager >> that will eventually paint it. >> Currently, a popup is shown blank. Please, see >> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >> >> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >> window owned by JLightweightFrame. >> >> Thanks, >> Anton. > From Sergey.Bylokhov at oracle.com Thu Oct 24 08:02:42 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 Oct 2013 19:02:42 +0400 Subject: [8] Review Request: JDK-8027030 AWT Multiple JVM DnD Test Failing on Linux (OEL and Ubuntu) and Solaris (Sparc and x64) In-Reply-To: References: <039125C7-EA10-47D1-A890-F2AD80A542B1@oracle.com> <52692930.2000500@oracle.com> Message-ID: <52693692.1010705@oracle.com> Hi, Petr. The fix looks good. On 24.10.2013 18:09, Petr Pchelko wrote: > Hello, Sergey. > >> Should we update translateStream() as well? > No, the translateStream contains this if clause. > > With best regards. Petr. > > On 24.10.2013, at 18:05, Sergey Bylokhov wrote: > >> Hi, Petr. >> Should we update translateStream() as well? >> >> On 24.10.2013 17:33, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> https://bugs.openjdk.java.net/browse/JDK-8027030 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/8027030/webrev.00/ >>> >>> This is a fix for a yet another regression of the JDK-7075105. We did not handle RMI DataFlavors when converting byte arrays. >>> >>> With best regards. Petr. >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From petr.pchelko at oracle.com Thu Oct 24 08:22:55 2013 From: petr.pchelko at oracle.com (petr.pchelko at oracle.com) Date: Thu, 24 Oct 2013 15:22:55 +0000 Subject: hg: jdk8/awt/jdk: 8027030: AWT Multiple JVM DnD Test Failing on Linux (OEL and Ubuntu) and Solaris (Sparc and x64) Message-ID: <20131024152449.5D0BC626DB@hg.openjdk.java.net> Changeset: 7c84aff91033 Author: pchelko Date: 2013-10-24 19:23 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7c84aff91033 8027030: AWT Multiple JVM DnD Test Failing on Linux (OEL and Ubuntu) and Solaris (Sparc and x64) Reviewed-by: anthony, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java From artem.ananiev at oracle.com Thu Oct 24 08:32:10 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 24 Oct 2013 19:32:10 +0400 Subject: [8] Review request for JDK-8026071 - Fix raw warnings in java AWT geometry package In-Reply-To: <52603711.9030005@oracle.com> References: <5255A97E.2040902@oracle.com> <525FFC6B.4070703@oracle.com> <52603711.9030005@oracle.com> Message-ID: <52693D7A.7020706@oracle.com> The webrev is available here: http://cr.openjdk.java.net/~art/srikalyc/8026071.00/ Looks fine to me. Thanks, Artem On 10/17/2013 11:14 PM, srikalyan chandrashekar wrote: > Hi Artem, i just verified and that it indeed corresponds to 8026071 but > you might also be looking at its parent umbrella JDK-7196567 > which entails this > bug 8026071 . > > --- > Thanks > kalyan > > On 10/17/2013 8:04 AM, Artem Ananiev wrote: >> Hi, Kalyan, >> >> it seems that the webrev doesn't correspond to 8026071, but to another >> bug about javac warnings. >> >> Thanks, >> >> Artem >> >> On 10/9/2013 11:07 PM, srikalyan chandrashekar wrote: >>> Hi team , could someone review the fix >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8026071 >>> Webrev : >>> https://github.com/srikalyc/JDKfixes/blob/master/java.awt.geom.raw.webrev.zip >>> >>> Fix : Raw warnings in AWT geom classes fixed >>> >>> *NOTE*: In java.awt.geom.Area.java , the inner class AreaIterator's >>> public constructor's signature has been changed and is only indirectly >>> exposed through a public method "PathIterator >>> getPathIterator(AffineTransform at)" which is harmless . >>> >>> -- >>> >>> -- >>> Thanks >>> kalyan >>> > From petr.pchelko at oracle.com Thu Oct 24 08:40:28 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 24 Oct 2013 19:40:28 +0400 Subject: [8] Review Request: JDK-8027152 Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112 Message-ID: Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8027152 The fix is available at: http://cr.openjdk.java.net/~pchelko/8027152/webrev.00/ The problem: After the fix for JDK-7081594 the ownedWindowList is used in setAlwaysOnTop. However the field is transient, so we get an NPE The solution: Move the ownedWindowList field initialization after the deserialization earlier that setAlwaysOnTop call. With best regards. Petr. From Sergey.Bylokhov at oracle.com Thu Oct 24 08:39:04 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 Oct 2013 19:39:04 +0400 Subject: [8] Review Request: JDK-8027025 [macosx] getLocationOnScreen returns 0 if parent invisible In-Reply-To: <09110C81-44E6-40AE-88FA-38C7BF97680E@oracle.com> References: <52678F21.3010305@oracle.com> <4957D0F3-3B21-4701-9FC4-285512B114EE@oracle.com> <526928FD.6040805@oracle.com> <09110C81-44E6-40AE-88FA-38C7BF97680E@oracle.com> Message-ID: <52693F18.3050604@oracle.com> Hi,Petr. The fix looks good. On 24.10.2013 18:16, Petr Pchelko wrote: > Hello, Anthony. > >> Please file a separate issue to investigate the setBounds/zoom code on Mac later. > I have filed https://bugs.openjdk.java.net/browse/JDK-8027250 > > With best regards. Petr. > > On 24.10.2013, at 18:04, Anthony Petrov wrote: > >> Hi Petr, >> >> The workaround you suggest seems to be more or less safe, so let's go with it. >> >> Please file a separate issue to investigate the setBounds/zoom code on Mac later. >> >> -- >> best regards, >> Anthony >> >> On 10/23/2013 01:05 PM, Petr Pchelko wrote: >>> Hello, Anthony. >>> >>>> What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames? >>> Yes. The decorated frame is receiving the initial move/resize event. I suppose it's somehow moved(resized) be adding the window decorations, but this is only a guess. >>> >>> With best regards. Petr. >>> >>> On 23.10.2013, at 12:56, Anthony Petrov wrote: >>> >>>> Hi Petr, >>>> >>>> What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames? >>>> >>>> Also, at [1] Alexander said: >>>>> The problem was that NSWindow is created with zero bounds and then >>>>> actual bounds are set. >>>>> In this case NSWindow treats big bounds as zoomed state and next zoom >>>>> move the window to initial zero bounds. >>>> I'm wondering, won't the same scenario fail for undecorated windows after your fix, just reverting them back to 0x0/1x1 instead of 0x0/0x0? >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005469.html >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/23/2013 12:43 PM, Petr Pchelko wrote: >>>>> Hello, AWT Team. >>>>> >>>>> Please review the fix for the issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8027025 >>>>> The fix is available at: >>>>> http://cr.openjdk.java.net/~pchelko/8027025/webrev.00/ >>>>> >>>>> The problem: >>>>> When initializing the peer's location and bounds we rely on the initial move/resize event. However if the undecorated frame is created right at the center of the screen this initial event does not come. >>>>> My testing shows that this is an only situation. >>>>> >>>>> The solution: >>>>> We revert the changes in JDK-8007219 for undecorated frames. The initial position is a 0-0-1-1 stub, the real position is set later during the initialization. >>>>> I don't want to do that for decorated frames as 1. this is not needed 2. the native maximize button starts working ugly in some cases. >>>>> >>>>> With best regards. Petr. >>>>> -- Best regards, Sergey. From petr.pchelko at oracle.com Thu Oct 24 08:49:12 2013 From: petr.pchelko at oracle.com (petr.pchelko at oracle.com) Date: Thu, 24 Oct 2013 15:49:12 +0000 Subject: hg: jdk8/awt/jdk: 8027025: [macosx] getLocationOnScreen returns 0 if parent invisible Message-ID: <20131024155005.DAD9E626DD@hg.openjdk.java.net> Changeset: c561db53a24c Author: pchelko Date: 2013-10-24 19:50 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c561db53a24c 8027025: [macosx] getLocationOnScreen returns 0 if parent invisible Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java + test/java/awt/Window/8027025/Test8027025.java From petr.pchelko at oracle.com Thu Oct 24 08:58:15 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 24 Oct 2013 19:58:15 +0400 Subject: [8] Review Request: JDK-8027152 Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112 In-Reply-To: References: Message-ID: <375904CE-2B1A-4D80-9450-DB7FE35ADF2E@oracle.com> Please disregard this request. It is incorrect. With best regards. Petr. On 24.10.2013, at 19:40, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8027152 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/8027152/webrev.00/ > > The problem: > After the fix for JDK-7081594 the ownedWindowList is used in setAlwaysOnTop. However the field is transient, so we get an NPE > > The solution: > Move the ownedWindowList field initialization after the deserialization earlier that setAlwaysOnTop call. > > With best regards. Petr. From Sergey.Bylokhov at oracle.com Thu Oct 24 10:30:02 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 Oct 2013 21:30:02 +0400 Subject: [8] Review Request: 7172770 Default Toolkit implementation return null value for property "awt.dynamicLayoutSupported" In-Reply-To: <52692D34.2050208@oracle.com> References: <526927FA.8020402@oracle.com> <52692D34.2050208@oracle.com> Message-ID: <5269591A.6060704@oracle.com> Hi, Anthony. After a small considering with Artem I decided to reduce changes as we at zbb stage here is a new small version: http://cr.openjdk.java.net/~serb/7172770/webrev.01 On 24.10.2013 18:22, Anthony Petrov wrote: > Hi Sergey, > > The fix looks good to me. > > -- > best regards, > Anthony > > On 10/24/2013 06:00 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk 8. >> Implementation of "dynamicLayoutSupported" now aligned to the >> set/getdynamicLayout which always use default toolkit. >> Note that we have CR to revisit all this code JDK-8024948 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-7172770 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7172770/webrev.00 >> -- Best regards, Sergey. From anthony.petrov at oracle.com Thu Oct 24 13:07:18 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 Oct 2013 00:07:18 +0400 Subject: [8] Review Request: JDK-8027025 [macosx] getLocationOnScreen returns 0 if parent invisible In-Reply-To: <09110C81-44E6-40AE-88FA-38C7BF97680E@oracle.com> References: <52678F21.3010305@oracle.com> <4957D0F3-3B21-4701-9FC4-285512B114EE@oracle.com> <526928FD.6040805@oracle.com> <09110C81-44E6-40AE-88FA-38C7BF97680E@oracle.com> Message-ID: <52697DF6.2010801@oracle.com> Thanks. -- best regards, Anthony On 10/24/2013 06:16 PM, Petr Pchelko wrote: > Hello, Anthony. > >> Please file a separate issue to investigate the setBounds/zoom code on Mac later. > > I have filed https://bugs.openjdk.java.net/browse/JDK-8027250 > > With best regards. Petr. > > On 24.10.2013, at 18:04, Anthony Petrov wrote: > >> Hi Petr, >> >> The workaround you suggest seems to be more or less safe, so let's go with it. >> >> Please file a separate issue to investigate the setBounds/zoom code on Mac later. >> >> -- >> best regards, >> Anthony >> >> On 10/23/2013 01:05 PM, Petr Pchelko wrote: >>> Hello, Anthony. >>> >>>> What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames? >>> Yes. The decorated frame is receiving the initial move/resize event. I suppose it's somehow moved(resized) be adding the window decorations, but this is only a guess. >>> >>> With best regards. Petr. >>> >>> On 23.10.2013, at 12:56, Anthony Petrov wrote: >>> >>>> Hi Petr, >>>> >>>> What happens if you display a decorated frame centered on the screen? Will it receive the initial Move/Size event? And if yes, why exactly this isn't happening for undecorated frames? >>>> >>>> Also, at [1] Alexander said: >>>>> The problem was that NSWindow is created with zero bounds and then >>>>> actual bounds are set. >>>>> In this case NSWindow treats big bounds as zoomed state and next zoom >>>>> move the window to initial zero bounds. >>>> >>>> I'm wondering, won't the same scenario fail for undecorated windows after your fix, just reverting them back to 0x0/1x1 instead of 0x0/0x0? >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005469.html >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/23/2013 12:43 PM, Petr Pchelko wrote: >>>>> Hello, AWT Team. >>>>> >>>>> Please review the fix for the issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8027025 >>>>> The fix is available at: >>>>> http://cr.openjdk.java.net/~pchelko/8027025/webrev.00/ >>>>> >>>>> The problem: >>>>> When initializing the peer's location and bounds we rely on the initial move/resize event. However if the undecorated frame is created right at the center of the screen this initial event does not come. >>>>> My testing shows that this is an only situation. >>>>> >>>>> The solution: >>>>> We revert the changes in JDK-8007219 for undecorated frames. The initial position is a 0-0-1-1 stub, the real position is set later during the initialization. >>>>> I don't want to do that for decorated frames as 1. this is not needed 2. the native maximize button starts working ugly in some cases. >>>>> >>>>> With best regards. Petr. >>>>> >>> > From anthony.petrov at oracle.com Thu Oct 24 13:10:19 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 Oct 2013 00:10:19 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5269301C.6050205@oracle.com> References: <5268122B.9010105@oracle.com> <5269301C.6050205@oracle.com> Message-ID: <52697EAB.1060302@oracle.com> The fix looks fine to me. Thanks. -- best regards, Anthony On 10/24/2013 06:35 PM, Anton V. Tarasov wrote: > Hello, > > Please look at the new version: > > http://cr.openjdk.java.net/~ant/RT-32570/webrev.1 > > It eliminates code dependency b/w awt & swing. > > Thanks, > Anton. > > On 10/23/13 10:15 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please, review the fix: >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >> >> This is to support SwingNode. On Windows, in the interop mode, when a >> popup (JWindow) is shown it doesn't get WM_PAINT native message. >> The message should trigger adding a dirty component to RepaintManager >> that will eventually paint it. >> Currently, a popup is shown blank. Please, see >> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >> >> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >> window owned by JLightweightFrame. >> >> Thanks, >> Anton. > From anthony.petrov at oracle.com Thu Oct 24 13:15:29 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 Oct 2013 00:15:29 +0400 Subject: [8] Review Request: 7172770 Default Toolkit implementation return null value for property "awt.dynamicLayoutSupported" In-Reply-To: <5269591A.6060704@oracle.com> References: <526927FA.8020402@oracle.com> <52692D34.2050208@oracle.com> <5269591A.6060704@oracle.com> Message-ID: <52697FE1.3050609@oracle.com> This looks even better. Thanks! -- best regards, Anthony On 10/24/2013 09:30 PM, Sergey Bylokhov wrote: > Hi, Anthony. > After a small considering with Artem I decided to reduce changes as we > at zbb stage > here is a new small version: > http://cr.openjdk.java.net/~serb/7172770/webrev.01 > > On 24.10.2013 18:22, Anthony Petrov wrote: >> Hi Sergey, >> >> The fix looks good to me. >> >> -- >> best regards, >> Anthony >> >> On 10/24/2013 06:00 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk 8. >>> Implementation of "dynamicLayoutSupported" now aligned to the >>> set/getdynamicLayout which always use default toolkit. >>> Note that we have CR to revisit all this code JDK-8024948 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-7172770 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7172770/webrev.00 >>> > > From david.holmes at oracle.com Thu Oct 24 15:59:45 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Oct 2013 08:59:45 +1000 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> <5267FF2D.5060804@oracle.com> <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> Message-ID: <5269A661.1080807@oracle.com> David, In src/share/native/java/lang/java_props.h the new field should really also be in ifdef MACOSX. The change to System.c allays my concerns there. You can also consider the hotspot changes Reviewed. Thanks, David H. On 24/10/2013 1:52 PM, David DeHaven wrote: > >>>> Another option (I think would make everyone happy) would be to add a native method to LWCToolkit.{java,m} that implements isAquaSession and returns a boolean. Call this new method in the static initializer and use it's return value to set java.awt.headless before calling initIDs. This will still be done early enough that Toolkit.java will end up wrapping LWCToolkit in a HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks to see if it needs to be wrapped. Then all that code in java_props* and System.c could be removed. >>> >>> I like this idea. But it needs testing. >> >> Cool, I'll poke at it when I get a chance. > > Doesn't work in LWCToolkit, GraphicsEnvironment gets initialized first which messes things up. > > It sort of works in CGraphicsEnvironment. The problem there is GraphicsEnvironment.isHeadless() is called at least once prior to CGraphicsEnvironment being loaded which then caches the value (false) so just changing the system property doesn't do anything. I added a protected method to change headless and it works, but I'm not entirely happy with that approach and I'm not convinced there won't be other side effects. For one thing, what is calling isHeadless before CGE gets loaded and will it cope with the mode changing? I don't think we have time to chase down all the issues that might manifest from that change, when we know for certain the setting the property in System.c works fine. > > I think the safest bet at this point is to move all the java_props.awt_headless field related code into #ifdef blocks so they only exist on Mac OS X. That will address the cross-platform concern and fix this issue. I just thought it would be useful for other platforms (especially embedded) to be able to poll their environment and set themselves up accordingly... > > > Updated (hopefully final...) webrev: > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/ > > Changes from last version: > http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/webrev.delta/index.html > > (src/windows/native/java/lang/java_props_md.c only shows up because of the delta webrev, it gets reverted back to the way it was) > > > As a side note, SplashScreen calls isHeadless and dumps a nice ugly stack trace in a non-GUI session. It does this in the existing code so that's something that'll need to be addressed as a separate issue. Also, the message returned by GraphicsEnvironment.getHeadlessMessage() isn't correct for Mac, that should either be made more generic or let the platform impl class return that string (if it's even known or loaded at the time...). > > -DrD- > From david.dehaven at oracle.com Thu Oct 24 16:05:31 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 24 Oct 2013 16:05:31 -0700 Subject: RFR: 8025673: Disable X11 AWT toolkit In-Reply-To: <5269A661.1080807@oracle.com> References: <824D9A11-C1F7-48B0-8923-C68D67F07263@oracle.com> <526570DB.9070509@oracle.com> <24BDD242-ACB4-4A95-8458-6877221EBC1A@oracle.com> <52664425.4080201@oracle.com> <1BFB0C64-CBC7-4B6B-A1F1-A694DC907BF3@oracle.com> <5266BBDA.2010106@oracle.com> <5266BD67.4010101@oracle.com> <3F04EB2D-BE97-4F87-B9A7-E814C7071A50@oracle.com> <5267560A.1010800@oracle.com> <5267C247.7040708@oracle.com> <5267E733.8010905@oracle.com> <921BAB90-269A-4A25-88A3-A070F8F5D814@oracle.com> <5267FF2D.5060804@oracle.com> <37A8A709-B034-41C0-93FB-53CE2A85EB38@oracle.com> <5269A661.1080807@oracle.com> Message-ID: <0825B755-E580-486B-A509-17037425D2FE@oracle.com> > David, > > In src/share/native/java/lang/java_props.h the new field should really also be in ifdef MACOSX. It's inside the "#ifdef MACOSX" block that was already there (starts at line 94), that's why I moved it to the bottom. You can't see it in the xDIFFs, but it's visible in the side-by-side frame mode. > The change to System.c allays my concerns there. > > You can also consider the hotspot changes Reviewed. Thank you! -DrD- From artem.ananiev at oracle.com Fri Oct 25 01:52:59 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 25 Oct 2013 12:52:59 +0400 Subject: [8] Review Request: 7172770 Default Toolkit implementation return null value for property "awt.dynamicLayoutSupported" In-Reply-To: <5269591A.6060704@oracle.com> References: <526927FA.8020402@oracle.com> <52692D34.2050208@oracle.com> <5269591A.6060704@oracle.com> Message-ID: <526A316B.9070505@oracle.com> On 10/24/2013 9:30 PM, Sergey Bylokhov wrote: > Hi, Anthony. > After a small considering with Artem I decided to reduce changes as we > at zbb stage > here is a new small version: > http://cr.openjdk.java.net/~serb/7172770/webrev.01 Looks fine. Thanks, Artem > On 24.10.2013 18:22, Anthony Petrov wrote: >> Hi Sergey, >> >> The fix looks good to me. >> >> -- >> best regards, >> Anthony >> >> On 10/24/2013 06:00 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk 8. >>> Implementation of "dynamicLayoutSupported" now aligned to the >>> set/getdynamicLayout which always use default toolkit. >>> Note that we have CR to revisit all this code JDK-8024948 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-7172770 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7172770/webrev.00 >>> > > From petr.pchelko at oracle.com Fri Oct 25 02:06:29 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 25 Oct 2013 13:06:29 +0400 Subject: [8] Review Request: JDK-8027152 Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112 Message-ID: <956F1DA8-2703-4EF4-9B22-CFDA339679CF@oracle.com> Hello, AWT Team. Please review the fix for the issue: http://bugs.openjdk.java.net/browse/JDK-8027152 The fix is available at: http://cr.openjdk.java.net/~pchelko/8027152/webrev.01/ The problem: After the fix for JDK-7081594 the setAlwaysOnTop needs the ownedWindowList to propagate the alwaysOnTop property to owned windows. However, after the deserialization we get an NPE. In the fix I've moved the ownedWindowList serialization and deserialization earlier, before we apply the alwaysOnTop. The test shows that owned windows are serialized and deserialized properly. With best regards. Petr. From anton.litvinov at oracle.com Fri Oct 25 02:50:03 2013 From: anton.litvinov at oracle.com (anton.litvinov at oracle.com) Date: Fri, 25 Oct 2013 09:50:03 +0000 Subject: hg: jdk8/awt/jdk: 8027066: XMLDecoder in java 7 cannot properly deserialize object arrays Message-ID: <20131025095327.CE58562731@hg.openjdk.java.net> Changeset: 6fe5443c3dde Author: alitvinov Date: 2013-10-25 13:41 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6fe5443c3dde 8027066: XMLDecoder in java 7 cannot properly deserialize object arrays Reviewed-by: alexsch, malenkov Contributed-by: anton.nashatyrev at oracle.com ! src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java + test/java/beans/XMLEncoder/Test8027066.java From sergey.malenkov at oracle.com Fri Oct 25 05:43:09 2013 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Fri, 25 Oct 2013 12:43:09 +0000 Subject: hg: jdk8/awt/jdk: 8026705: [TEST_BUG] java/beans/Introspector/TestTypeResolver.java failed Message-ID: <20131025124450.845AB62746@hg.openjdk.java.net> Changeset: 75ae2a980db5 Author: malenkov Date: 2013-10-25 16:42 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/75ae2a980db5 8026705: [TEST_BUG] java/beans/Introspector/TestTypeResolver.java failed Reviewed-by: art, jfranck ! test/java/beans/Introspector/TestTypeResolver.java From alexandr.scherbatiy at oracle.com Fri Oct 25 06:18:47 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 25 Oct 2013 17:18:47 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <5267EA15.1080103@oracle.com> References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com> Message-ID: <526A6FB7.7000800@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/ - Scaled image width and height are transformed according to the AffineTransform type. - ToolkitImage subclass is used to hold @2x image instance. Thanks, Alexandr. On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/ > > The JCK failures has been resolved: > - Some tests tries to draw an image with Integer.MAX_VALUE width > or height. Passing large values to image.getScaledImage(width, height, > hints). > leads that an Image filter is not able to create necessary > arrays. The fix uses the original image if width or height are equal > to Integer.MAX_VALUE. > - Using Image.SCALE_DEFAULT hint for the getScaledImage(width, > height, hints) method to get the high resolution image interferes with > JCK tests that expect that the scaled image by certain > algorithm is returned. This is fixed by invoking the > super.getScaledImage(width, height, hints) > method in ToolkitImage in case if a high resolution image is > not set. > > Thanks, > Alexandr. > > > > On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8011059 >> webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 >> >> The IMAGE_SCALING rendering hint is added to the RenderingHints class. >> Enabling the image scaling rendering hint forces the SunGraphics2D >> to use getScaledInstance(width, height, hints) method >> from Image class with SCALE_DEFAULT hint. >> >> By default the image scaling rendering hint is enabled on HiDPI >> display and disabled for standard displays. >> >> User can override the getScaledInstance(width, height, hints) >> method and return necessary high resolution image >> according to the given image width and height. >> >> For example: >> --------------------- >> final Image highResolutionImage = >> new BufferedImage(2 * WIDTH, 2 * HEIGHT, >> BufferedImage.TYPE_INT_RGB); >> Image image = new BufferedImage(WIDTH, HEIGHT, >> BufferedImage.TYPE_INT_RGB) { >> >> @Override >> public Image getScaledInstance(int width, int height, int >> hints) { >> if ((hints & Image.SCALE_DEFAULT) != 0) { >> return (width <= WIDTH && height <= HEIGHT) >> ? this : highResolutionImage; >> } >> return super.getScaledInstance(width, height, hints); >> } >> }; >> --------------------- >> >> The LWCToolkit and ToolkitImage classes are patched to >> automatically get provided image at 2x.ext images on MacOSX. >> >> There are no significant changes in the Java2D demo to make it look >> perfect on Retina displays. >> It needs only to put necessary images with the @2x postfix and they >> will be automatically drawn. >> >> Thanks, >> Alexandr. >> > From anton.tarasov at oracle.com Fri Oct 25 06:45:30 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 25 Oct 2013 17:45:30 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <526935B8.1020609@oracle.com> References: <5268122B.9010105@oracle.com> <5269301C.6050205@oracle.com> <526935B8.1020609@oracle.com> Message-ID: <526A75FA.6010400@oracle.com> Hi Artem, On 10/24/13 6:59 PM, Artem Ananiev wrote: > Hi, Anton, > > it looks much better now. Is it possible to create a regression test > for this change? Ok, I did that. Here's the test: http://cr.openjdk.java.net/~ant/RT-32570.test/webrev.0 It persistently passes with the fix (Window/Mac), and fails without (Windows). I'll push it to jfx8 right after this fix gets into jdk8 and jfx8 is switched to build since that jdk8 build (if that is possible). Thanks, Anton. > > Thanks, > > Artem > > On 10/24/2013 6:35 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please look at the new version: >> >> http://cr.openjdk.java.net/~ant/RT-32570/webrev.1 >> >> It eliminates code dependency b/w awt & swing. >> >> Thanks, >> Anton. >> >> On 10/23/13 10:15 PM, Anton V. Tarasov wrote: >>> Hello, >>> >>> Please, review the fix: >>> >>> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >>> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >>> >>> This is to support SwingNode. On Windows, in the interop mode, when a >>> popup (JWindow) is shown it doesn't get WM_PAINT native message. >>> The message should trigger adding a dirty component to RepaintManager >>> that will eventually paint it. >>> Currently, a popup is shown blank. Please, see >>> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >>> >>> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >>> window owned by JLightweightFrame. >>> >>> Thanks, >>> Anton. >> From sergey.bylokhov at oracle.com Fri Oct 25 08:57:28 2013 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Fri, 25 Oct 2013 15:57:28 +0000 Subject: hg: jdk8/awt/jdk: 7172770: Default Toolkit implementation return null value for property "awt.dynamicLayoutSupported" Message-ID: <20131025155800.979666274D@hg.openjdk.java.net> Changeset: dab1d3798016 Author: serb Date: 2013-10-25 19:51 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dab1d3798016 7172770: Default Toolkit implementation return null value for property "awt.dynamicLayoutSupported" Reviewed-by: anthony, art ! src/share/classes/java/awt/Toolkit.java From leonid.romanov at oracle.com Fri Oct 25 10:33:07 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 25 Oct 2013 21:33:07 +0400 Subject: [8] Review request for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow Message-ID: <9A8388F2-3F39-42BB-84D8-0268625F3858@oracle.com> Hello, Please review a fix for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow The problem here is that NSView's -enterFullScreenMode: withOptions: we currently use for entering exclusive full screen mode does it by creating a NSFullScreenWindow instance and moving the view from its window to that newly created full screen window. Since we do not control NSFullScreenWindow creation, we do not get any focus and other notifications from it. The fix is to stop using -enterFullScreenMode: withOptions: and just achieve the exclusive full screen mode manually. Bug: https://bugs.openjdk.java.net/browse/JDK-8013581 Webrev: http://cr.openjdk.java.net/~leonidr/8013581/webrev.00/ Regards, Leonid. From Sergey.Bylokhov at oracle.com Fri Oct 25 11:28:06 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Oct 2013 22:28:06 +0400 Subject: [8] Review request for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow In-Reply-To: <9A8388F2-3F39-42BB-84D8-0268625F3858@oracle.com> References: <9A8388F2-3F39-42BB-84D8-0268625F3858@oracle.com> Message-ID: <526AB836.3000805@oracle.com> Hi, Leonid. The fix looks good. But can you update the test to check all devices in the system? On 25.10.2013 21:33, Leonid Romanov wrote: > Hello, > Please review a fix for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow > The problem here is that NSView's -enterFullScreenMode: withOptions: we currently use for entering exclusive full screen mode does it by creating a NSFullScreenWindow instance and moving the view from its window to that newly created full screen window. Since we do not control NSFullScreenWindow creation, we do not get any focus and other notifications from it. > The fix is to stop using -enterFullScreenMode: withOptions: and just achieve the exclusive full screen mode manually. > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8013581 > Webrev:http://cr.openjdk.java.net/~leonidr/8013581/webrev.00/ > > Regards, > Leonid. -- Best regards, Sergey. From lana.steuck at oracle.com Fri Oct 25 12:26:15 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 25 Oct 2013 19:26:15 +0000 Subject: hg: jdk8/awt: 51 new changesets Message-ID: <20131025192631.0FA4D62760@hg.openjdk.java.net> Changeset: 7dea0ce25bdc Author: pbhat Date: 2013-05-30 16:00 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/7dea0ce25bdc Merge ! common/autoconf/generated-configure.sh Changeset: d081bdbf904d Author: jqzuo Date: 2013-06-10 16:15 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/d081bdbf904d Merge ! common/autoconf/generated-configure.sh Changeset: b59990653fb9 Author: pbhat Date: 2013-06-21 18:56 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/b59990653fb9 Merge ! common/autoconf/generated-configure.sh Changeset: dd345e4b51fb Author: pbhat Date: 2013-07-05 11:00 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/dd345e4b51fb Merge ! common/autoconf/generated-configure.sh Changeset: 24cc2d9b0af5 Author: pbhat Date: 2013-07-18 16:49 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/24cc2d9b0af5 Merge ! common/autoconf/generated-configure.sh Changeset: 4a4c9e7bc6c9 Author: pbhat Date: 2013-07-25 17:26 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/4a4c9e7bc6c9 Merge Changeset: 63d794ade242 Author: pbhat Date: 2013-08-02 09:41 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/63d794ade242 Merge Changeset: a5485b9a2d14 Author: pbhat Date: 2013-08-09 14:54 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/a5485b9a2d14 Merge Changeset: 028ac95111b9 Author: pbhat Date: 2013-08-16 14:33 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/028ac95111b9 Merge Changeset: 4b686cbc32c7 Author: pbhat Date: 2013-08-23 09:45 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/4b686cbc32c7 Merge ! common/autoconf/generated-configure.sh Changeset: ec583e324aaf Author: pbhat Date: 2013-08-30 10:14 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/ec583e324aaf Merge ! common/autoconf/generated-configure.sh Changeset: 96f00091b570 Author: pbhat Date: 2013-09-05 11:23 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/96f00091b570 Merge ! common/autoconf/generated-configure.sh Changeset: 69096d4b1da2 Author: pbhat Date: 2013-09-12 12:08 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/69096d4b1da2 Merge ! common/autoconf/generated-configure.sh Changeset: 5a306baf3bb7 Author: pbhat Date: 2013-09-19 14:01 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/5a306baf3bb7 Merge ! common/autoconf/generated-configure.sh Changeset: 88ca3ff9ce2d Author: billyh Date: 2013-09-25 10:50 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/88ca3ff9ce2d 8025262: new64jre/new64jdk wrappers should be removed, build 32-bit AU during windows-amd64 builds instead Reviewed-by: amenkov, jqzuo ! make/install-rules.gmk Changeset: c8066e5d7a7b Author: pbhat Date: 2013-09-26 11:20 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/c8066e5d7a7b Merge Changeset: 00ae95ca1755 Author: pbhat Date: 2013-10-03 09:52 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/00ae95ca1755 Merge Changeset: 7deff16cf438 Author: jqzuo Date: 2013-10-14 18:53 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/rev/7deff16cf438 Merge ! common/autoconf/generated-configure.sh Changeset: ec48d637778a Author: tbell Date: 2013-10-09 18:51 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/ec48d637778a 8023611: Win32 and win64: Remove all the WARNINGS in JDK 8 builds for Windows 2008 and MSVS 2010 SP1 Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 174a54ce39c4 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/rev/174a54ce39c4 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! NewMakefile.gmk ! common/autoconf/autogen.sh ! common/autoconf/basics.m4 ! common/autoconf/basics_windows.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/bootcycle-spec.gmk.in ! common/autoconf/build-aux/config.guess ! common/autoconf/build-performance.m4 ! common/autoconf/builddeps.conf.example ! common/autoconf/builddeps.conf.nfs.example ! common/autoconf/builddeps.m4 ! common/autoconf/compare.sh.in ! common/autoconf/config.h.in ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/libraries.m4 ! common/autoconf/platform.m4 ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 ! common/makefiles/HotspotWrapper.gmk ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/NativeCompilation.gmk ! common/makefiles/RMICompilation.gmk ! common/makefiles/devkit/Makefile ! common/makefiles/devkit/Tools.gmk ! common/makefiles/javadoc/CORE_PKGS.gmk ! common/makefiles/javadoc/Javadoc.gmk ! common/makefiles/javadoc/NON_CORE_PKGS.gmk ! common/makefiles/javadoc/Notes.html Changeset: 6274d4cd22d3 Author: erikj Date: 2013-10-14 11:54 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/rev/6274d4cd22d3 8025921: Make LOG=debug output more readable Reviewed-by: tbell, ihse ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk Changeset: 547316ea137d Author: katleman Date: 2013-10-16 11:55 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/547316ea137d Merge ! common/autoconf/generated-configure.sh ! common/makefiles/javadoc/CORE_PKGS.gmk ! common/makefiles/javadoc/Javadoc.gmk Changeset: ac748011cbbf Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/ac748011cbbf Added tag jdk8-b112 for changeset 547316ea137d ! .hgtags Changeset: 4d23143c676a Author: lana Date: 2013-10-10 08:49 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/4d23143c676a Merge Changeset: fd3b32cc4b6e Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/fd3b32cc4b6e Merge Changeset: 3f9873789d44 Author: mduigou Date: 2013-10-11 15:20 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/3f9873789d44 8025796: hgforest.sh could trigger unbuffered output from hg without complicated machinations Reviewed-by: mduigou Contributed-by: Dmitry Samersoff ! common/bin/hgforest.sh Changeset: d35943431696 Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/d35943431696 Merge Changeset: af87dabb4263 Author: msheppar Date: 2013-06-14 15:49 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/rev/af87dabb4263 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! common/makefiles/RMICompilation.gmk Changeset: ce8c63017f11 Author: chegar Date: 2013-10-13 21:37 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/rev/ce8c63017f11 Merge Changeset: 28be3d174c92 Author: chegar Date: 2013-10-15 13:39 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/rev/28be3d174c92 Merge Changeset: af81988013b5 Author: erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/rev/af81988013b5 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! common/makefiles/JavaCompilation.gmk ! common/makefiles/RMICompilation.gmk Changeset: 9ec6626d43bb Author: mduigou Date: 2013-10-17 14:07 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/9ec6626d43bb 8026062: webrev.ksh: fix bug title web scraping, remove teamware, sac, "open bug", -l and wxfile support Reviewed-by: weijun, dsamersoff, darcy, jrose, tbell ! make/scripts/webrev.ksh Changeset: 77473affb9c0 Author: lana Date: 2013-10-17 13:53 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/77473affb9c0 Merge ! common/makefiles/JavaCompilation.gmk ! common/makefiles/RMICompilation.gmk Changeset: 35c14ec3e12f Author: lana Date: 2013-10-17 15:50 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/35c14ec3e12f Merge Changeset: 22c6f0b7e2b5 Author: dcubed Date: 2013-10-15 08:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/22c6f0b7e2b5 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/makefiles/NativeCompilation.gmk Changeset: ac09e62d5e6b Author: amurillo Date: 2013-10-19 08:51 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/ac09e62d5e6b Merge ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/makefiles/NativeCompilation.gmk Changeset: 9d5284dfc00d Author: amurillo Date: 2013-10-22 13:56 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/9d5284dfc00d Merge Changeset: 5b4f14990dd1 Author: ihse Date: 2013-10-18 10:41 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/rev/5b4f14990dd1 8001912: Improve detection of msvcr100.dll Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 Changeset: 65c1752b4c38 Author: katleman Date: 2013-10-18 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/65c1752b4c38 Merge Changeset: 17d195bd56fc Author: erikj Date: 2013-10-18 11:34 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/rev/17d195bd56fc 8025869: make docs doesn't regenerate docs correctly after changing API doc comments in jaxp sources Reviewed-by: ihse, tbell ! common/makefiles/JavaCompilation.gmk Changeset: e27dda53d4f5 Author: erikj Date: 2013-10-21 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/rev/e27dda53d4f5 Merge Changeset: 1a853fac18ff Author: erikj Date: 2013-10-21 11:59 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/rev/1a853fac18ff 8026528: [build] configure does not recognize newer make in cygwin Reviewed-by: tbell, ksrini, ihse ! NewMakefile.gmk ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: dffe654ab24c Author: ihse Date: 2013-10-22 11:12 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/rev/dffe654ab24c 8001925: Add useful help messages if freetype is not found on Windows Reviewed-by: erikj, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 Changeset: 56db38956113 Author: ihse Date: 2013-10-22 12:29 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/rev/56db38956113 8026864: Deprecate --disable-macosx-runtime-support. Reviewed-by: erikj ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 9e177e7fc438 Author: katleman Date: 2013-10-22 14:53 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/9e177e7fc438 Merge ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/makefiles/JavaCompilation.gmk Changeset: 4293401d683b Author: katleman Date: 2013-10-22 16:35 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/4293401d683b 8027068: Update to NewMakefile.gmk check of MAKE_VERSION broke jdk8-build nightly builds on windows, saying 3.82.90 is too low Reviewed-by: ihse, tbell, wetmore ! NewMakefile.gmk Changeset: 269497597620 Author: tbell Date: 2013-10-22 16:28 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/269497597620 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 2cc1a52d37ef Author: tbell Date: 2013-10-22 16:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/2cc1a52d37ef Merge Changeset: 6f19b2440412 Author: ihse Date: 2013-10-23 13:05 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/rev/6f19b2440412 8001922: Improve freetype handling. Reviewed-by: erikj ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/libraries.m4 ! common/autoconf/spec.gmk.in Changeset: 6ba4c7cb623e Author: erikj Date: 2013-10-23 17:03 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/rev/6ba4c7cb623e 8026888: Licensee build failure due to wrong libs being called Reviewed-by: tbell, ihse, simonis ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: a36df87b3901 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/a36df87b3901 Added tag jdk8-b113 for changeset 6ba4c7cb623e ! .hgtags From lana.steuck at oracle.com Fri Oct 25 12:26:12 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 25 Oct 2013 19:26:12 +0000 Subject: hg: jdk8/awt/corba: 23 new changesets Message-ID: <20131025192725.1541E62761@hg.openjdk.java.net> Changeset: 66fc1a749867 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/66fc1a749867 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildCorba.gmk ! makefiles/Makefile Changeset: 43cec76d1d62 Author: katleman Date: 2013-10-16 11:55 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/43cec76d1d62 Merge Changeset: 54aa9b7d743d Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/54aa9b7d743d Added tag jdk8-b112 for changeset 43cec76d1d62 ! .hgtags Changeset: 81d694b1ab2f Author: msheppar Date: 2013-06-14 16:31 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/81d694b1ab2f 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java ! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java Changeset: ab6eae733bce Author: chegar Date: 2013-07-15 11:04 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/ab6eae733bce Merge Changeset: e5ea72df9806 Author: chegar Date: 2013-07-22 13:59 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/e5ea72df9806 Merge Changeset: be4fdc568d73 Author: mchung Date: 2013-07-22 19:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/be4fdc568d73 8017196: Ensure Proxies are handled appropriately Reviewed-by: dfuchs, jrose, jdn, ahgross, chegar ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/InvocationHandlerFactoryImpl.java ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java Changeset: b0aeb77f0292 Author: chegar Date: 2013-07-25 17:32 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/b0aeb77f0292 Merge Changeset: a72f506e3058 Author: chegar Date: 2013-08-02 09:38 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/a72f506e3058 Merge Changeset: 0717fc6f2960 Author: chegar Date: 2013-08-09 14:24 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/0717fc6f2960 Merge Changeset: 6b5db99e194c Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/6b5db99e194c Merge - src/share/classes/com/sun/corba/se/impl/copyobject/JavaInputStream.sjava - src/share/classes/com/sun/corba/se/impl/copyobject/JavaOutputStream.sjava - src/share/classes/com/sun/corba/se/impl/interceptors/ThreadCurrentStack.sjava - src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl_save.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/transport/BufferConnectionImpl.sjava Changeset: 9c75c61d97f8 Author: msheppar Date: 2013-08-19 15:22 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/9c75c61d97f8 8022940: Enhance CORBA translations Reviewed-by: coffeys, alanb, skoivu ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java Changeset: 2caa37dfd7cd Author: chegar Date: 2013-08-23 22:11 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/2caa37dfd7cd Merge Changeset: a5788ab042dc Author: chegar Date: 2013-08-30 09:48 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/a5788ab042dc Merge Changeset: 118a211bb3ba Author: chegar Date: 2013-09-06 09:48 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/118a211bb3ba Merge Changeset: cc52d582df09 Author: chegar Date: 2013-09-14 19:40 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/cc52d582df09 Merge Changeset: 396854c032bb Author: chegar Date: 2013-10-03 19:11 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/396854c032bb Merge Changeset: 47513cdce4ed Author: chegar Date: 2013-10-13 22:00 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/47513cdce4ed Merge Changeset: 438c54c148a6 Author: erikj Date: 2013-10-16 13:49 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/438c54c148a6 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! makefiles/BuildCorba.gmk Changeset: 1a71d800b032 Author: wetmore Date: 2013-10-16 23:31 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/1a71d800b032 8026762: jdk8-tl builds windows builds failing in corba - javac: no source files Reviewed-by: katleman, dholmes ! makefiles/BuildCorba.gmk Changeset: 1c01208087b5 Author: lana Date: 2013-10-17 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/1c01208087b5 Merge ! makefiles/BuildCorba.gmk Changeset: a259ff3e42d9 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/a259ff3e42d9 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 0bbccf77c23e Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/0bbccf77c23e Added tag jdk8-b113 for changeset a259ff3e42d9 ! .hgtags From lana.steuck at oracle.com Fri Oct 25 12:27:28 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 25 Oct 2013 19:27:28 +0000 Subject: hg: jdk8/awt/jaxws: 22 new changesets Message-ID: <20131025193137.36D6F62765@hg.openjdk.java.net> Changeset: 602fdd7bb765 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/602fdd7bb765 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildJaxws.gmk ! makefiles/Makefile Changeset: dbdd5c762509 Author: katleman Date: 2013-10-16 11:56 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/dbdd5c762509 Merge Changeset: 9ca9735d9966 Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/9ca9735d9966 Added tag jdk8-b112 for changeset dbdd5c762509 ! .hgtags Changeset: da77e343f458 Author: lana Date: 2013-10-10 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/da77e343f458 Merge Changeset: 66a12ce67d3a Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/66a12ce67d3a Merge Changeset: 328b8b96773b Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/328b8b96773b Merge Changeset: 43240b8b995b Author: mkos Date: 2013-08-01 16:09 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/43240b8b995b 8017505: Better Client Service Reviewed-by: mullan, ahgross, mgrebac ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AbstractInstanceResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/InstanceResolver.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/MethodUtil.java + src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SEIStub.java + src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/PolicyUtils.java Changeset: 358f32260d1f Author: chegar Date: 2013-08-02 11:11 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/358f32260d1f Merge Changeset: 5212665bea32 Author: chegar Date: 2013-08-09 14:31 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/5212665bea32 Merge Changeset: d9704ab517d5 Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/d9704ab517d5 Merge Changeset: fca8869ccfd0 Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/fca8869ccfd0 Merge Changeset: a6e2adde013e Author: chegar Date: 2013-08-30 10:15 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/a6e2adde013e Merge Changeset: f6376ba97cea Author: chegar Date: 2013-09-06 09:55 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/f6376ba97cea Merge Changeset: d3a65e8912c9 Author: chegar Date: 2013-09-14 20:43 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/d3a65e8912c9 Merge Changeset: da8141b6e344 Author: chegar Date: 2013-10-03 19:18 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/da8141b6e344 Merge Changeset: 2dc8ae7eb53b Author: chegar Date: 2013-10-11 19:24 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/2dc8ae7eb53b Merge Changeset: 01facfebe17b Author: chegar Date: 2013-10-15 13:46 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/01facfebe17b Merge Changeset: be7d1f874b96 Author: lana Date: 2013-10-17 16:12 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/be7d1f874b96 Merge Changeset: 17f1b13cd401 Author: simonis Date: 2013-10-21 15:11 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/17f1b13cd401 8026874: During JAXWS build the newly built JAXP classes should be in the bootclasspath (not only in the classpath) Reviewed-by: erikj ! makefiles/BuildJaxws.gmk Changeset: f20820d1582f Author: katleman Date: 2013-10-22 16:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/f20820d1582f Merge Changeset: 9261f342aa73 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/9261f342aa73 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 9ad289610fc6 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/9ad289610fc6 Added tag jdk8-b113 for changeset 9261f342aa73 ! .hgtags From lana.steuck at oracle.com Fri Oct 25 12:27:37 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 25 Oct 2013 19:27:37 +0000 Subject: hg: jdk8/awt/jaxp: 31 new changesets Message-ID: <20131025193257.2560862766@hg.openjdk.java.net> Changeset: acae2e8a46df Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/acae2e8a46df 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildJaxp.gmk ! makefiles/Makefile Changeset: c1f9158fbb9c Author: katleman Date: 2013-10-16 11:56 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/c1f9158fbb9c Merge Changeset: e85dd07c0eea Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/e85dd07c0eea Added tag jdk8-b112 for changeset c1f9158fbb9c ! .hgtags Changeset: b76629725522 Author: joehw Date: 2013-10-10 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/b76629725522 8003262: reverse translation required changes in xalan resource bundles Reviewed-by: lancea, dfuchs ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ca.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_cs.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sk.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ca.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_cs.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sk.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_TW.java Changeset: 2107c9baa457 Author: lana Date: 2013-10-10 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/2107c9baa457 Merge Changeset: cff4e3bf530a Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/cff4e3bf530a Merge Changeset: 46ccc5fbc523 Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/46ccc5fbc523 Merge Changeset: de8c803d4958 Author: aefimov Date: 2013-10-13 13:50 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/de8c803d4958 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc Reviewed-by: alanb, shade ! src/com/sun/org/apache/xpath/internal/XPathContext.java Changeset: 4712979714d1 Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/4712979714d1 Merge Changeset: 91ae0f2045bc Author: lana Date: 2013-10-14 09:52 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/91ae0f2045bc Merge Changeset: eb169222d3f2 Author: joehw Date: 2013-10-14 22:07 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/eb169222d3f2 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Reviewed-by: lancea, alanb ! src/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java Changeset: ecb66dc473c1 Author: joehw Date: 2013-07-16 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/ecb66dc473c1 8012425: Transform TransformerFactory Reviewed-by: alanb, dfuchs, mullan ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: 7a2014318343 Author: joehw Date: 2013-07-17 09:31 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/7a2014318343 8017298: Better XML support Reviewed-by: alanb, dfuchs, mullan, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java - src/com/sun/org/apache/xerces/internal/util/SecurityManager.java ! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java + src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/xml/internal/stream/Entity.java Changeset: a59549c3ad60 Author: dfuchs Date: 2013-07-17 18:46 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/a59549c3ad60 8013502: Improve stream factories Reviewed-by: joehw, mullan, lancea ! src/javax/xml/stream/FactoryFinder.java Changeset: 4b0b2b5c4cc8 Author: chegar Date: 2013-07-22 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/4b0b2b5c4cc8 Merge Changeset: 40b8abe19642 Author: chegar Date: 2013-07-29 14:07 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/40b8abe19642 Merge ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: 720db2e27962 Author: joehw Date: 2013-07-31 00:37 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/720db2e27962 8014530: Better digital signature processing Reviewed-by: alanb, dfuchs, mullan, lancea ! src/com/sun/org/apache/xalan/internal/XalanConstants.java + src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java + src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: cd9347628c7c Author: joehw Date: 2013-07-31 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/cd9347628c7c 8021366: java_util/Properties/PropertiesWithOtherEncodings fails during 7u45 nightly testing Reviewed-by: lancea, alanb, dfuchs, mullan ! src/com/sun/xml/internal/stream/Entity.java Changeset: ecbddaa85462 Author: chegar Date: 2013-08-02 11:10 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/ecbddaa85462 Merge Changeset: c5e80c1fa32f Author: chegar Date: 2013-08-09 14:31 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/c5e80c1fa32f Merge ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java Changeset: f952c33ebfdb Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/f952c33ebfdb Merge Changeset: ce16a5aa1507 Author: joehw Date: 2013-08-20 09:02 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/ce16a5aa1507 8022682: Supporting XOM Reviewed-by: alanb, chegar, lancea ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/parsers/DOMParser.java ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/parsers/XMLParser.java + src/com/sun/org/apache/xerces/internal/util/SecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java Changeset: cc3b64366048 Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/cc3b64366048 Merge Changeset: 2b77e12ff69d Author: chegar Date: 2013-10-11 19:49 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/2b77e12ff69d Merge ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/util/SecurityManager.java Changeset: 6f220761f643 Author: chegar Date: 2013-10-15 14:16 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/6f220761f643 Merge Changeset: 0c3f951630fe Author: joehw Date: 2013-10-17 11:22 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/0c3f951630fe 8015243: SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/util/URI.java Changeset: 951c1f7fdb10 Author: joehw Date: 2013-10-17 16:35 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/951c1f7fdb10 8016500: Unlocalized warnigs. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/jaxp/DefaultValidationErrorHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java Changeset: 31c82bc71ae3 Author: lana Date: 2013-10-17 15:45 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/31c82bc71ae3 Merge Changeset: 2f1e1e2c2242 Author: lana Date: 2013-10-17 17:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/2f1e1e2c2242 Merge Changeset: 0046d2278204 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/0046d2278204 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 1b1e12117fe2 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/1b1e12117fe2 Added tag jdk8-b113 for changeset 0046d2278204 ! .hgtags From lana.steuck at oracle.com Fri Oct 25 12:27:37 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 25 Oct 2013 19:27:37 +0000 Subject: hg: jdk8/awt/nashorn: 32 new changesets Message-ID: <20131025193036.CF5E962764@hg.openjdk.java.net> Changeset: 45399f3ef717 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/45399f3ef717 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildNashorn.gmk ! makefiles/Makefile Changeset: 6a4fdb3bb4e3 Author: katleman Date: 2013-10-16 12:05 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/6a4fdb3bb4e3 Merge Changeset: 103590fc1e0a Author: cl Date: 2013-10-17 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/103590fc1e0a Added tag jdk8-b112 for changeset 6a4fdb3bb4e3 ! .hgtags Changeset: 8d29733ad609 Author: sundar Date: 2013-10-09 10:47 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/8d29733ad609 8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8026112.js Changeset: 1e03d7caa68b Author: sundar Date: 2013-10-09 13:26 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/1e03d7caa68b 8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be cast to jdk.nashorn.internal.runtime.ScriptObject Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8026125.js Changeset: ec3094d9d5d5 Author: hannesw Date: 2013-10-09 14:50 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/ec3094d9d5d5 8026008: Constant folding removes var statement Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/FoldConstants.java + test/script/basic/JDK-8026008.js + test/script/basic/JDK-8026008.js.EXPECTED Changeset: 03a68e7ca1d5 Author: lagergren Date: 2013-10-09 17:53 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/03a68e7ca1d5 8026137: Fix Issues with Binary Evaluation Order Reviewed-by: hannesw, jlaskey Contributed-by: marcus.lagergren at oracle.com, attila.szegedi at oracle.com ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java - src/jdk/nashorn/internal/ir/TypeOverride.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/arrays/JavaArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseJavaArrayIterator.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + test/script/basic/JDK-8026137.js + test/script/basic/JDK-8026137.js.EXPECTED Changeset: 7cc5ff16380f Author: sundar Date: 2013-10-10 11:48 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/7cc5ff16380f 8026167: Class cache/reuse of 'eval' scripts results in ClassCastException in some cases. Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! test/script/assert.js ! test/script/basic/JDK-8019508.js ! test/script/basic/JDK-8019508.js.EXPECTED ! test/script/basic/JDK-8019553.js ! test/script/basic/JDK-8019553.js.EXPECTED ! test/script/basic/JDK-8019791.js ! test/script/basic/JDK-8019791.js.EXPECTED ! test/script/basic/JDK-8019805.js ! test/script/basic/JDK-8019805.js.EXPECTED + test/script/basic/JDK-8026167.js ! test/script/basic/NASHORN-100.js ! test/script/basic/NASHORN-100.js.EXPECTED ! test/script/basic/NASHORN-293.js ! test/script/basic/NASHORN-293.js.EXPECTED ! test/script/basic/NASHORN-40.js ! test/script/basic/NASHORN-40.js.EXPECTED ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-51.js.EXPECTED ! test/script/basic/NASHORN-98.js ! test/script/basic/NASHORN-98.js.EXPECTED ! test/script/basic/eval.js ! test/script/basic/eval.js.EXPECTED Changeset: e60bbcf2f6b6 Author: sundar Date: 2013-10-10 13:17 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/e60bbcf2f6b6 8026248: importClass has to be a varargs function Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8026248.js + test/script/basic/JDK-8026248.js.EXPECTED Changeset: f6263ae511c2 Author: lana Date: 2013-10-10 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/f6263ae511c2 Merge Changeset: 34f7a699cdef Author: sundar Date: 2013-10-10 14:43 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/34f7a699cdef 8026162: "this" in SAM adapter functions is wrong Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java + test/script/basic/JDK-8026162.js Changeset: ed3da7a574a0 Author: lagergren Date: 2013-10-10 16:16 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/ed3da7a574a0 8026250: Logging nullpointer bugfix and javadoc warnings Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/WithObject.java Changeset: a781ea074521 Author: sundar Date: 2013-10-10 21:43 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/a781ea074521 8026264: Getter, setter function name mangling issues Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java + test/script/basic/JDK-8026264.js Changeset: 375c2f2d41c8 Author: sundar Date: 2013-10-11 06:50 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/375c2f2d41c8 8026263: [NASHORN] Test test/script/basic/JDK-8025488.js fails in nightly builds Reviewed-by: jlaskey ! test/script/basic/JDK-8025488.js Changeset: 56be5161f0d2 Author: sundar Date: 2013-10-11 09:09 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/56be5161f0d2 Merge Changeset: 1c154cee43d9 Author: hannesw Date: 2013-10-11 10:56 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/1c154cee43d9 8026292: Megamorphic setter fails with boolean value Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + test/script/basic/JDK-8026292.js Changeset: fb091f9052a6 Author: sundar Date: 2013-10-11 11:15 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/fb091f9052a6 8026302: source representation of getter and setter methods is wrong Reviewed-by: lagergren, hannesw, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8026302.js + test/script/basic/JDK-8026302.js.EXPECTED ! test/script/basic/objects.js.EXPECTED Changeset: 062579f50371 Author: sundar Date: 2013-10-11 14:11 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/062579f50371 8026317: $ in the function name results in wrong function being invoked Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/Namespace.java + test/script/basic/JDK-8026317.js + test/script/basic/JDK-8026317.js.EXPECTED Changeset: b35d175207f6 Author: sundar Date: 2013-10-11 14:13 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/b35d175207f6 Merge Changeset: 1b0a71a9920a Author: lana Date: 2013-10-11 23:31 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/1b0a71a9920a Merge Changeset: 6cb4f20d971f Author: jlaskey Date: 2013-10-11 14:54 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/6cb4f20d971f 8026309: latest runsunspider.js tests contains several bugs Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! test/script/basic/runsunspider.js Changeset: 8c617a092d68 Author: hannesw Date: 2013-10-14 11:45 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/8c617a092d68 8026016: too many relinks dominate avatar.js http benchmark Reviewed-by: sundar, jlaskey, attila ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8026016.js + test/script/basic/JDK-8026016.js.EXPECTED Changeset: d155c4a7703c Author: attila Date: 2013-10-14 12:41 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/d155c4a7703c 8026113: Nashorn arrays should automatically convert to Java arrays Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java + test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java Changeset: 64e841576c68 Author: attila Date: 2013-10-15 15:57 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/64e841576c68 8026397: Fix ambiguity with array conversion, including passing JS NativeArrays in Java variable arity methods' vararg array position Reviewed-by: jlaskey, sundar ! src/jdk/internal/dynalink/beans/SingleDynamicMethod.java ! src/jdk/internal/dynalink/support/Guards.java ! src/jdk/internal/dynalink/support/messages.properties ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java Changeset: aa452eb4a5d0 Author: hannesw Date: 2013-10-15 17:37 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/aa452eb4a5d0 8026367: Add a sync keyword to mozilla_compat Reviewed-by: sundar, attila, lagergren ! src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8026367.js ! test/script/sandbox/loadcompat.js Changeset: b3ee112a328e Author: jlaskey Date: 2013-10-15 13:14 -0300 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/b3ee112a328e 8026498: Revert: latest runsunspider.js tests contains several bugs Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! test/script/basic/runsunspider.js Changeset: 9a13e95cc40f Author: sundar Date: 2013-10-15 22:13 +0530 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/9a13e95cc40f Merge Changeset: 1899da5c71d3 Author: hannesw Date: 2013-10-16 10:12 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/1899da5c71d3 8026692: eval() throws NullPointerException with --compile-only Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Lower.java + test/script/basic/JDK-8026692.js Changeset: 2d5f9f77c199 Author: hannesw Date: 2013-10-16 10:15 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/2d5f9f77c199 8026693: getType() called on DISCARD node Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java + test/script/basic/JDK-8026693.js Changeset: adc5639fc4b9 Author: sundar Date: 2013-10-17 13:02 +0530 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/adc5639fc4b9 Merge Changeset: 676cd7bf5e09 Author: lana Date: 2013-10-17 16:19 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/676cd7bf5e09 Merge Changeset: 79f7b79bf97b Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/nashorn/rev/79f7b79bf97b Added tag jdk8-b113 for changeset 676cd7bf5e09 ! .hgtags From lana.steuck at oracle.com Fri Oct 25 12:32:27 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 25 Oct 2013 19:32:27 +0000 Subject: hg: jdk8/awt/hotspot: 128 new changesets Message-ID: <20131025194154.1794962768@hg.openjdk.java.net> Changeset: deec468baebd Author: amurillo Date: 2013-10-04 14:19 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/deec468baebd 8025859: new hotspot build - hs25-b54 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5b3b75d9eb2f Author: coleenp Date: 2013-10-01 14:23 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5b3b75d9eb2f 8025570: Naked oop in test/serviceability/ParserTest Summary: Fix for two naked objArrayOop(s) oops causing test failure Reviewed-by: coleenp, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/prims/wbtestmethods/parserTests.cpp Changeset: f21415c32ca1 Author: coleenp Date: 2013-10-01 15:41 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f21415c32ca1 Merge Changeset: d574419c5372 Author: mseledtsov Date: 2013-10-02 15:17 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d574419c5372 8025671: Test name changed, test list not updated. Test6878713.sh Summary: Removed the obsolete test from the test group file Reviewed-by: sla, ctornqvi, dholmes ! test/TEST.groups Changeset: 931f105563c5 Author: coleenp Date: 2013-10-02 13:02 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/931f105563c5 8025569: -XX:+CheckUnhandledOops crashes on Windows Summary: Disable CHECK_UNHANDLED_OOPS in fastdebug builds for JDK 8 on WIndows 32 & 64 bit machines Reviewed-by: coleenp, ctornqvi, zgu Contributed-by: lois.foltan at oracle.com ! make/windows/makefiles/fastdebug.make Changeset: 6f73bc5df986 Author: coleenp Date: 2013-10-02 15:06 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6f73bc5df986 Merge Changeset: 2bd38d594b9a Author: dsamersoff Date: 2013-10-02 20:58 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2bd38d594b9a 8025283: Nits in os_bsd file breaks compilation of open hotspot Summary: Couple of nits in os_bsd.cpp brake compilation of open hotspot on non-apple platforms Reviewed-by: sla, sspitsyn ! src/os/bsd/vm/os_bsd.cpp Changeset: 9855f17334d8 Author: dsamersoff Date: 2013-10-03 01:12 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9855f17334d8 Merge Changeset: 5705c7ee6dd7 Author: dsamersoff Date: 2013-10-02 22:27 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5705c7ee6dd7 8025250: SA: Sync linux and bsd versions of ps_core file Summary: linux/ps_core.c and bsd/ps_core.c share most of code, but it has different formatting, comments etc. Reviewed-by: sla, minqi ! agent/src/os/bsd/ps_core.c ! agent/src/os/linux/ps_core.c Changeset: 7ae82c3a781a Author: dsamersoff Date: 2013-10-03 04:42 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7ae82c3a781a Merge Changeset: faff125a1ead Author: dsamersoff Date: 2013-10-03 12:39 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/faff125a1ead 8022616: u4 should not be used as a type for thread_id Summary: Usage of u4 as a type for thread_id cause a compilation error on platform, where thread_id is a pointer Reviewed-by: sla, sspitsyn, minqi ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp Changeset: 07f8c2a453f8 Author: coleenp Date: 2013-10-03 18:53 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/07f8c2a453f8 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Summary: Redefined class in stack trace may not be found by method_idnum so handle null. Reviewed-by: sla, dcubed, sspitsyn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 3374b92de2d9 Author: coleenp Date: 2013-10-03 18:50 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3374b92de2d9 8025004: -XX:+CheckUnhandledOops asserts for JDK 8 Solaris fastdebug binaries Summary: Remove unnecessary volatile keyword on stack locals within instanceKlass.cpp to work around Solaris Studio C++ compiler issue Reviewed-by: coleenp, dcubed Contributed-by: lois.foltan at oracle.com ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 3bf767171ea4 Author: coleenp Date: 2013-10-05 00:53 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3bf767171ea4 Merge Changeset: 675ffabf3798 Author: mikael Date: 2013-10-02 09:18 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/675ffabf3798 8024087: Remove dead JVM_{Get,Set}PrimitiveFieldValues functions Summary: The two functions were used to support JDK 1.3 but are no longer in use Reviewed-by: coleenp, ctornqvi, twisti, dsamersoff ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/nativeLookup.cpp Changeset: a1fd44b003c7 Author: coleenp Date: 2013-10-05 00:58 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a1fd44b003c7 Merge Changeset: 4212bfb33d76 Author: coleenp Date: 2013-10-05 03:14 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/4212bfb33d76 Merge Changeset: 2720ab7a0d70 Author: ccheung Date: 2013-10-04 21:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2720ab7a0d70 Merge ! src/share/vm/prims/jvm.cpp Changeset: febab3a8f203 Author: erikj Date: 2013-10-04 12:45 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/febab3a8f203 8007446: Add /MP to cl.exe speeds up windows builds of OpenJDK. Reviewed-by: sla, ctornqvi ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: 763705f0fec3 Author: sla Date: 2013-10-04 13:01 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/763705f0fec3 8016845: SA is unable to use hsdis on windows Summary: Added sadis.c to the build to provide missing symbols in sawindbg.dll. Added code to use the correct hsdisXXX.dll filename on different windows platforms. Reviewed-by: sla, mgerdin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! make/windows/makefiles/sa.make Changeset: f9be370a7d54 Author: sla Date: 2013-10-05 15:18 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f9be370a7d54 8025922: JNI access to Strings need to check if the value field is non-null Reviewed-by: dholmes, dcubed ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp Changeset: 8ef918538e22 Author: sla Date: 2013-10-04 13:44 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8ef918538e22 6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2" Summary: Adds support for large(>4G) heap dumps in hprof format. Adds tests and updates testlibrary. Reviewed-by: sla, allwin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! test/TEST.groups + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapProc.java + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 9c63ad02c0a4 Author: sla Date: 2013-10-05 10:56 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9c63ad02c0a4 Merge Changeset: cc4f5f8d885e Author: mseledtsov Date: 2013-10-06 16:13 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/cc4f5f8d885e 8023796: [TESTBUG] Add -XX:-TransmitErrorReport to runtime/6888954/vmerrors.sh Summary: added -XX:-TransmitErrorReport to the test Reviewed-by: stefank, ctornqvi ! test/runtime/6888954/vmerrors.sh ! test/runtime/memory/ReserveMemory.java Changeset: ac9cb1d5a202 Author: acorn Date: 2013-10-07 12:20 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ac9cb1d5a202 8009130: Lambda: Fix access controls, loader constraints. Summary: New default methods list with inherited superinterface methods Reviewed-by: minqi, sspitsyn, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 615d83933195 Author: dholmes Date: 2013-10-08 02:56 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/615d83933195 8026025: JVM_GetCallerClass allows Reflection.getCallerClass(int depth) to use Reviewed-by: alanb, dholmes, twisti Contributed-by: mandy.chung at oracle.com ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: c90e76575b03 Author: kevinw Date: 2013-10-08 09:33 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c90e76575b03 8019375: Internal symbol table size should be tunable. Reviewed-by: coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: ced68a57cdbd Author: kevinw Date: 2013-10-08 11:37 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ced68a57cdbd Merge Changeset: c72075c2883e Author: acorn Date: 2013-10-08 16:58 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c72075c2883e 8026022: Verifier: allow anon classes to invokespecial host class/intf methods. Reviewed-by: coleenp, bharadwaj ! src/share/vm/classfile/verifier.cpp Changeset: d25557d03ec0 Author: acorn Date: 2013-10-09 17:57 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d25557d03ec0 8026185: nsk/jvmit/GetMethodDeclaringClass/declcls001 failed Summary: Missed initialization. Thanks Coleen. Reviewed-by: coleenp, minqi ! src/share/vm/oops/instanceKlass.cpp Changeset: c01f4910f5f5 Author: ccheung Date: 2013-10-10 13:25 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c01f4910f5f5 Merge Changeset: 9b4d0569f2f4 Author: jwilhelm Date: 2013-10-03 21:36 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9b4d0569f2f4 8025852: Remove unnecessary setters in collector policy classes Summary: Use instance variables directly within the collector policy classes and remove unused setters. Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: 087f02e22fc2 Author: jwilhelm Date: 2013-10-04 22:08 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/087f02e22fc2 8025854: Use "young gen" instead of "eden" Summary: Changed a few descriptions and variable names to young gen. Reviewed-by: tschatzl, jcoomes ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 263f2c796d6c Author: stefank Date: 2013-10-05 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/263f2c796d6c 8024838: Significant slowdown due to transparent huge pages Summary: Don't turn on transparent huge pages (-XX:+UseTransparentHugePages) unless explicitly specified on the command line. This has the effect that large pages are never turned on Linux unless the user has explicitly enabled any of the large pages flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, -XX:+UseHugeTLBFS, and -XX:+UseSHM. Reviewed-by: jwilhelm, tschatzl, brutisso ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp + test/runtime/memory/LargePages/TestLargePagesFlags.java Changeset: 8618e0d7735b Author: stefank Date: 2013-10-05 08:01 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8618e0d7735b Merge Changeset: 04b18a42c2f3 Author: mgerdin Date: 2013-10-04 13:33 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/04b18a42c2f3 8025526: VirtualSpace should support per-instance disabling of large pages Summary: Add a new initialization function to VirtualSpace which allows the caller to override the max commit granularity. Reviewed-by: stefank, ehelin, tschatzl ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 69944b868a32 Author: mgerdin Date: 2013-10-08 17:35 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/69944b868a32 8014555: G1: Memory ordering problem with Conc refinement and card marking Summary: Add a StoreLoad barrier in the G1 post-barrier to fix a race with concurrent refinement. Also-reviewed-by: martin.doerr at sap.com Reviewed-by: iveresov, tschatzl, brutisso, roland, kvn ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/opto/graphKit.cpp Changeset: b4d8a3d4db73 Author: tamao Date: 2013-10-09 11:18 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b4d8a3d4db73 8010506: Typos and errors in descriptions of vm options in globals.hpp Summary: Fix typos and errors in descriptions of vm options in globals.hpp Reviewed-by: jmasa, jwilhelm ! src/share/vm/runtime/globals.hpp Changeset: 82af7d7a0128 Author: tschatzl Date: 2013-10-09 10:57 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/82af7d7a0128 8003420: NPG: make new GC root for pd_set Summary: Move protection domain oops from system dictionary entries into a seperate set; the system dictionary references entries in that set now. This allows fast iteration during non-classunloading garbage collection. Implementation based on initial prototype from Ioi Lam (iklam). Reviewed-by: coleenp, iklam + agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainCacheEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainEntry.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 85c1ca43713f Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/85c1ca43713f 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces Reviewed-by: brutisso, jmasa, coleenp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a6414751d537 Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a6414751d537 8025996: Track metaspace usage when metaspace is expanded Reviewed-by: coleenp, ehelin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/services/memoryService.hpp Changeset: aa6f2ea19d8f Author: jcoomes Date: 2013-10-11 08:27 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/aa6f2ea19d8f Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4a845c7a4638 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/4a845c7a4638 Merge Changeset: 0ed9a90f45e1 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/0ed9a90f45e1 Added tag hs25-b54 for changeset 4a845c7a4638 ! .hgtags Changeset: aeae561a6d0b Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/aeae561a6d0b Added tag jdk8-b112 for changeset 0ed9a90f45e1 ! .hgtags Changeset: 5c599c419c1d Author: hseigel Date: 2013-07-11 12:59 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5c599c419c1d 8016256: Make finalization final Summary: Add private methods to final methods check Reviewed-by: coleenp, acorn, ahgross Contributed-by: harold.seigel at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: d840f02d03b4 Author: chegar Date: 2013-07-15 11:07 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d840f02d03b4 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: 7ec210434b3c Author: chegar Date: 2013-07-22 14:01 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7ec210434b3c Merge - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ca9029490fce Author: chegar Date: 2013-07-25 17:35 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ca9029490fce Merge Changeset: 8f66130f7b5c Author: chegar Date: 2013-08-02 11:10 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8f66130f7b5c Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 38f9393d1847 Author: sgabdura Date: 2013-08-09 11:03 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/38f9393d1847 8020789: Disable exporting of gc.heap_dump diagnostic command Reviewed-by: fparain, ahgross ! src/share/vm/services/diagnosticCommand.cpp Changeset: ee7a7aa7c6bb Author: chegar Date: 2013-08-09 14:30 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ee7a7aa7c6bb Merge Changeset: 8f3c59225a5c Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8f3c59225a5c Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 7638e35cabc6 Author: erikj Date: 2013-08-19 17:47 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7638e35cabc6 8015614: Update build settings Reviewed-by: tbell, dholmes, ahgross ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: d4fa23d6c35b Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d4fa23d6c35b Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 07b5f47d7a18 Author: chegar Date: 2013-08-30 09:50 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/07b5f47d7a18 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 98a2169ed7ac Author: iklam Date: 2013-08-24 00:14 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/98a2169ed7ac 8023683: Enhance class file parsing Summary: Use the value returned by REALLOC_RESOURCE_ARRAY() Reviewed-by: coleenp, ahgross ! src/share/vm/classfile/classFileParser.cpp Changeset: 8321dcc18438 Author: chegar Date: 2013-10-13 21:14 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8321dcc18438 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 1a93f2c5945a Author: lana Date: 2013-10-17 14:20 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/1a93f2c5945a Merge ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make ! src/share/vm/classfile/classFileParser.cpp Changeset: 7c26dced065e Author: amurillo Date: 2013-10-11 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7c26dced065e 8026265: new hotspot build - hs25-b55 Reviewed-by: jcoomes ! make/hotspot_version Changeset: b4a4fdc1f464 Author: coleenp Date: 2013-10-09 21:45 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b4a4fdc1f464 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::compare_entry_to and copy_entry_to Summary: Add missing cases. Reviewed-by: sspitsyn, dcubed ! src/share/vm/oops/constantPool.cpp Changeset: e831448418ac Author: coleenp Date: 2013-10-09 22:01 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e831448418ac Merge Changeset: cd7ea1d79dac Author: sla Date: 2013-10-11 13:48 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/cd7ea1d79dac 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed Summary: Fixed a compilation failure due to changed method name Reviewed-by: sla, jbachorik Contributed-by: fredrik.arvidsson at oracle.com ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 539144972c1e Author: sla Date: 2013-10-11 14:08 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/539144972c1e 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump Summary: Switched from using SystemDictionary to using ClassLoaderDataGraph to get the anonymous classes included. Reviewed-by: sla, sspitsyn Contributed-by: fredrik.arvidsson at oracle.com ! src/share/vm/services/heapDumper.cpp Changeset: 301ece1880ad Author: sla Date: 2013-10-11 14:57 +0000 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/301ece1880ad Merge Changeset: 28ca974cc21a Author: coleenp Date: 2013-10-11 11:23 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/28ca974cc21a 8022592: assert at constantTag.cpp:57: ShouldNotReachHere() Summary: more missing cases for JVM_CONSTANT_Method{Handle,Type}InError Reviewed-by: hseigel, dcubed ! src/share/vm/oops/constantPool.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 26ae62bc26c4 Author: coleenp Date: 2013-10-11 15:04 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/26ae62bc26c4 Merge Changeset: 0db3ba3f6870 Author: hseigel Date: 2013-10-11 15:33 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/0db3ba3f6870 8026041: JVM crashes with assert "assert(is_updated()) failed: must not be clear" with -XX:+PrintGCApplicationConcurrentTime in -Xcomp mode Summary: Prior to printing the time interval in RuntimeService::record_safepoint_begin(), check first that VM initialization is complete. Reviewed-by: coleenp, dholmes, sla, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/services/runtimeService.cpp Changeset: df268195b0ea Author: hseigel Date: 2013-10-11 17:08 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/df268195b0ea Merge Changeset: 41459da469ae Author: ccheung Date: 2013-10-11 18:23 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/41459da469ae Merge Changeset: 83dbf427fedd Author: ccheung Date: 2013-10-11 22:22 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/83dbf427fedd Merge Changeset: 3e265ce4d2dd Author: hseigel Date: 2013-10-12 13:09 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3e265ce4d2dd 8025942: os::Bsd::available_memory() needs implementation Summary: Implement using the host_statistics64() api. Reviewed-by: dsamersoff, morris, dholmes, coleenp, hseigel, dcubed Contributed-by: gerard.ziemski at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: d37a0525c0fe Author: hseigel Date: 2013-10-12 15:39 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d37a0525c0fe 8024667: VM crashes with "assert(method() != NULL) failed: must have set method" Summary: Check if data is in shared spaces before deallocating it. Reviewed-by: coleenp, dcubed ! src/share/vm/memory/metadataFactory.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 2f8728d92483 Author: acorn Date: 2013-10-14 21:52 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2f8728d92483 8026299: invokespecial gets ICCE when it should get AME. Reviewed-by: ccheung, coleenp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp Changeset: f509b8f4699b Author: dcubed Date: 2013-10-15 08:25 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f509b8f4699b 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/universal.gmk ! make/bsd/makefiles/vm.make ! make/defs.make Changeset: e8703d708e6e Author: ccheung Date: 2013-10-16 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e8703d708e6e Merge Changeset: 1e814e391ee8 Author: anoll Date: 2013-10-04 09:19 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/1e814e391ee8 8025656: compiler/8013496/Test8013496.sh fails on assert Summary: Ensure the thread is in correct state; rewrote test in Java Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp - test/compiler/8013496/Test8013496.sh + test/compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java Changeset: 0c4c40f5c399 Author: twisti Date: 2013-10-04 10:11 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/0c4c40f5c399 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods Reviewed-by: kvn, roland ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: 5f1241525a01 Author: twisti Date: 2013-10-04 19:05 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5f1241525a01 Merge Changeset: bf8a21c3ab3b Author: vlivanov Date: 2013-10-07 14:10 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/bf8a21c3ab3b 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) Reviewed-by: twisti, azeemj ! src/share/vm/utilities/ostream.cpp Changeset: 5cc2d82aa82a Author: vlivanov Date: 2013-10-07 14:11 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5cc2d82aa82a 8024943: ciReplay: fails to dump replay data during safepointing Reviewed-by: kvn, twisti ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/utilities/vmError.cpp Changeset: f478c98e8114 Author: vlivanov Date: 2013-10-07 14:12 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f478c98e8114 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range Reviewed-by: iveresov, roland, kvn, twisti ! src/share/vm/opto/parse2.cpp Changeset: 5741fc86a2ee Author: vlivanov Date: 2013-10-07 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5741fc86a2ee 8025845: Default methods are unnecessarily marked w/ force_inline directive in some situations Reviewed-by: acorn, kvn ! src/share/vm/classfile/defaultMethods.cpp Changeset: c775af091fe9 Author: twisti Date: 2013-10-07 10:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c775af091fe9 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/parseHelper.cpp Changeset: d9043b88eeb3 Author: roland Date: 2013-10-03 10:55 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d9043b88eeb3 8024067: Missing replace_in_map() calls following null checks Summary: add replace_in_map() calls following some null checks in type checks Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp Changeset: 17cda06bcb7d Author: iveresov Date: 2013-10-08 07:08 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/17cda06bcb7d Merge ! src/share/vm/classfile/defaultMethods.cpp - test/compiler/8013496/Test8013496.sh Changeset: 6171eb9da4fd Author: twisti Date: 2013-10-08 19:57 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6171eb9da4fd 8007923: Tests on references fails Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/opto/escape.cpp Changeset: 98692a2d36d7 Author: adlertz Date: 2013-10-09 13:00 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/98692a2d36d7 8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument Summary: Replace uninitialised pointer with NULL at argument. Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 4e7f99b70d9d Author: adlertz Date: 2013-10-09 05:03 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/4e7f99b70d9d Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: 46ef27bcacb3 Author: twisti Date: 2013-10-09 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/46ef27bcacb3 8020750: Node::get_int: guarantee(t != NULL) failed: must be con Reviewed-by: kvn, roland ! src/share/vm/opto/ifnode.cpp Changeset: d13d7aba8c12 Author: roland Date: 2013-10-09 16:32 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d13d7aba8c12 8023657: New type profiling points: arguments to call Summary: x86 interpreter and c1 type profiling for arguments at calls Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp Changeset: 8b80b262e501 Author: twisti Date: 2013-10-11 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8b80b262e501 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/thread.hpp Changeset: d8a449d2f5b2 Author: adlertz Date: 2013-10-11 13:10 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d8a449d2f5b2 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: Summary: Increased the LRG AllStack mask size since the previous size was not big enough when compiling huge methods (60k+ nodes) Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/ifg.cpp Changeset: 2348b2726e1d Author: adlertz Date: 2013-10-11 19:16 +0000 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2348b2726e1d Merge Changeset: dd2cf1d1248b Author: adlertz Date: 2013-10-12 01:29 +0000 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/dd2cf1d1248b Merge Changeset: 469216acdb28 Author: anoll Date: 2013-10-10 15:44 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/469216acdb28 8023014: CodeSweeperSweepNoFlushTest.java fails with HS crash Summary: Ensure ensure correct initialization of compiler runtime Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp + test/compiler/startup/SmallCodeCacheStartup.java Changeset: ed2c74787eb5 Author: twisti Date: 2013-10-11 19:51 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ed2c74787eb5 Merge Changeset: ce0cc25bc5e2 Author: roland Date: 2013-10-12 12:12 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ce0cc25bc5e2 8026054: New type profiling points: type of return values at calls Summary: x86 interpreter and c1 type profiling for return values at calls Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp Changeset: f50418dfb1b7 Author: iveresov Date: 2013-10-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f50418dfb1b7 Merge ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh Changeset: e504cd481ec0 Author: twisti Date: 2013-10-14 19:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e504cd481ec0 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set Reviewed-by: kvn ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 8df6f123d35e Author: drchase Date: 2013-10-12 17:26 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8df6f123d35e 8026124: JSR-292 bug: java.nio.file.Path.toString cores dump Summary: catch problem case, assert it matches valid input, new test Reviewed-by: jrose, twisti, kvn ! src/share/vm/interpreter/linkResolver.cpp + test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java + test/compiler/jsr292/createsInterfaceDotEqualsCallInfo.js Changeset: f91a9a696e5e Author: kvn Date: 2013-10-15 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f91a9a696e5e 8026293: Schedule part of G1 pre-barrier late Summary: move rare executed part of G1 write barrier from hot path. Reviewed-by: kvn, twisti, roland Contributed-by: staffan.friberg at oracle.com ! src/share/vm/opto/graphKit.cpp Changeset: 1263c7e17e1c Author: kvn Date: 2013-10-15 17:47 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/1263c7e17e1c Merge Changeset: 4a2acfb16e97 Author: rbackman Date: 2013-10-11 12:06 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/4a2acfb16e97 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 Reviewed-by: kvn, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp + test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 90abdd727e64 Author: iveresov Date: 2013-10-16 11:13 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/90abdd727e64 8009303: Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 Summary: Do memory flow analysis in string concat optimizier to exclude cases when computation of arguments to StringBuffer::append has side effects Reviewed-by: kvn, twisti ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 8f4bb1773fd9 Author: iveresov Date: 2013-10-17 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8f4bb1773fd9 Merge ! src/share/vm/interpreter/linkResolver.cpp - test/compiler/8013496/Test8013496.sh Changeset: 7114c4597ae3 Author: acorn Date: 2013-10-17 23:30 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7114c4597ae3 8026365: NoClassDefinitionFound for anonymous class invokespecial. Reviewed-by: dcubed, kamg ! src/share/vm/classfile/verifier.cpp ! test/TEST.groups Changeset: 9c8289162268 Author: jwilhelm Date: 2013-10-11 16:18 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9c8289162268 8024776: Max/MinHeapFreeRatio descriptions should be more precise Summary: Descriptions for Max/MinHeapFreeRatio updated Reviewed-by: ehelin, jmasa ! src/share/vm/runtime/globals.hpp Changeset: 2382ff14d889 Author: jwilhelm Date: 2013-10-12 05:08 +0000 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2382ff14d889 Merge ! src/share/vm/runtime/globals.hpp Changeset: 24f32d09a0d7 Author: jwilhelm Date: 2013-10-12 00:49 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/24f32d09a0d7 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize Summary: Exit with an error if incompatible NewSize and MaxNeSize are set Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: d6818f623792 Author: tschatzl Date: 2013-10-15 11:18 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d6818f623792 8026186: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java Compilation failed Summary: After a method rename in JDK-8014905 the mentioned test did not compile any more. Fix the uses of the affected method. Reviewed-by: jwilhelm, mgerdin, jmasa ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 027006a47a6d Author: sjohanss Date: 2013-10-14 14:21 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/027006a47a6d 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 Summary: Using strtod() instead of atof() when parsing -Xminf and -Xmaxf. Reviewed-by: brutisso, pliden ! src/share/vm/runtime/arguments.cpp + test/gc/arguments/TestHeapFreeRatio.java Changeset: 82fcc0567fef Author: mgerdin Date: 2013-10-15 04:29 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/82fcc0567fef Merge Changeset: 6f1919cfd18c Author: pliden Date: 2013-10-15 11:38 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6f1919cfd18c 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, expect 0 full gcs Reviewed-by: brutisso, tschatzl ! test/TEST.groups - test/gc/7168848/HumongousAlloc.java + test/gc/g1/TestHumongousAllocInitialMark.java Changeset: bfd52054aeb8 Author: pliden Date: 2013-10-15 11:42 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/bfd52054aeb8 8024632: Description of InitialSurvivorRatio flag in globals.hpp is incorrect Reviewed-by: brutisso, tschatzl, kmo, tamao ! src/share/vm/runtime/globals.hpp Changeset: 041c5da41ac4 Author: pliden Date: 2013-10-15 11:44 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/041c5da41ac4 8024634: gc/startup_warnings tests can fail due to unrelated warnings Reviewed-by: brutisso, jwilhelm, tamao ! test/gc/startup_warnings/TestCMS.java ! test/gc/startup_warnings/TestCMSNoIncrementalMode.java ! test/gc/startup_warnings/TestG1.java ! test/gc/startup_warnings/TestParNewCMS.java ! test/gc/startup_warnings/TestParallelGC.java ! test/gc/startup_warnings/TestParallelScavengeSerialOld.java ! test/gc/startup_warnings/TestSerialGC.java Changeset: f16726924734 Author: stefank Date: 2013-10-15 07:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f16726924734 Merge - test/gc/7168848/HumongousAlloc.java Changeset: bdfbb1fb19ca Author: stefank Date: 2013-10-15 14:28 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/bdfbb1fb19ca 8026391: The Metachunk header wastes memory Reviewed-by: coleenp, jmasa ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ec2e26e26183 Author: stefank Date: 2013-10-15 14:32 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ec2e26e26183 8026392: Metachunks and Metablocks are using a too large alignment Reviewed-by: coleenp, jmasa ! src/share/vm/memory/metachunk.cpp Changeset: 9e5fadad7fdf Author: tschatzl Date: 2013-10-16 11:46 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9e5fadad7fdf 8025925: jmap fails with "field _length not found in type HeapRegionSeq" Summary: The change JDK-7163191 changed the data layout of a class that is referenced by the java code of the SA agent. This fix synchronizes the SA agent with that change. Reviewed-by: sla, mgerdin + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1HeapRegionTable.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java Changeset: 28df60a5badf Author: stefank Date: 2013-10-17 08:41 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/28df60a5badf 8026707: JDK-8026391 broke the optimized build target Reviewed-by: mgerdin, coleenp ! src/share/vm/memory/metachunk.hpp Changeset: 94c0343b1887 Author: stefank Date: 2013-10-17 08:42 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/94c0343b1887 8026715: Remove the MetaDataDeallocateALot develop flag Reviewed-by: coleenp, mgerdin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/globals.hpp Changeset: bf9e50c573ad Author: jmasa Date: 2013-10-17 06:29 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/bf9e50c573ad 8025635: SoftReferences are not cleared before metaspace OOME are thrown Reviewed-by: jcoomes, tamao, tschatzl, stefank ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: c51cd6af7e61 Author: jcoomes Date: 2013-10-18 12:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c51cd6af7e61 Merge ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 23b8db5ea31d Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/23b8db5ea31d Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: e8cbdc701bfb Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e8cbdc701bfb Added tag hs25-b55 for changeset 23b8db5ea31d ! .hgtags Changeset: 4589b398ab03 Author: amurillo Date: 2013-10-22 13:56 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/4589b398ab03 Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 4a1128861221 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/4a1128861221 Added tag jdk8-b113 for changeset 4589b398ab03 ! .hgtags From lana.steuck at oracle.com Fri Oct 25 12:30:40 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 25 Oct 2013 19:30:40 +0000 Subject: hg: jdk8/awt/langtools: 50 new changesets Message-ID: <20131025193701.BFD2462767@hg.openjdk.java.net> Changeset: 343aeb2033f0 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/343aeb2033f0 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildLangtools.gmk ! makefiles/Makefile Changeset: 954dd199d6ff Author: katleman Date: 2013-10-16 12:05 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/954dd199d6ff Merge Changeset: 8f54b4231c28 Author: cl Date: 2013-10-17 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/8f54b4231c28 Added tag jdk8-b112 for changeset 954dd199d6ff ! .hgtags Changeset: ea000904db62 Author: alundblad Date: 2013-10-08 15:33 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/ea000904db62 8024415: Bug in javac Pretty: Wrong precedence in JCConditional trees Summary: Fixed precedence and associativity issues with pretty printing of JCConditional expressions. Reviewed-by: jfranck Contributed-by: Andreas Lundblad , Matthew Dempsky ! src/share/classes/com/sun/tools/javac/tree/Pretty.java + test/tools/javac/tree/T8024415.java Changeset: 0be3f1820e8b Author: jlahoda Date: 2013-10-09 13:06 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/0be3f1820e8b 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) Summary: Should not generate non-public $assertionsDisabled field into interfaces Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/defaultMethods/Assertions.java + test/tools/javac/defaultMethods/CannotChangeAssertionsStateAfterInitialized.java Changeset: 1b469fd31e35 Author: jlahoda Date: 2013-10-09 13:09 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/1b469fd31e35 8025087: Annotation processing api returns default modifier for interface static method Summary: ClassReader must not set Flags.DEFAULT for interface static methods Reviewed-by: vromero, jjg ! make/build.xml ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/BadClassfile.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/InvalidDefaultInterface/InvalidDefaultInterface.java + test/tools/javac/diags/examples/InvalidDefaultInterface/processors/CreateBadClassFile.java + test/tools/javac/diags/examples/InvalidStaticInterface/InvalidStaticInterface.java + test/tools/javac/diags/examples/InvalidStaticInterface/processors/CreateBadClassFile.java ! test/tools/javac/processing/model/element/TestExecutableElement.java Changeset: 1e7ad879f15e Author: alundblad Date: 2013-10-10 08:51 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/1e7ad879f15e 8021237: clean up JavacAnnotatedConstruct Summary: Refactored the static helper methods in JavacAnnoConstructs into ordinary methods and put them in a common superclass (AnnoConstruct) of Symbol and Type. Reviewed-by: jjg, vromero, jfranck + src/share/classes/com/sun/tools/javac/code/AnnoConstruct.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java - src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java Changeset: 933ba3f81a87 Author: bpatel Date: 2013-10-10 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/933ba3f81a87 8025633: Fix javadoc to generate valid anchor names Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java + src/share/classes/com/sun/tools/doclets/formats/html/SectionName.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! test/com/sun/javadoc/AccessSkipNav/AccessSkipNav.java + test/com/sun/javadoc/testAnchorNames/TestAnchorNames.java + test/com/sun/javadoc/testAnchorNames/pkg1/DeprMemClass.java + test/com/sun/javadoc/testAnchorNames/pkg1/RegClass.java ! test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java ! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNavigation/TestNavigation.java ! test/com/sun/javadoc/testNestedGenerics/TestNestedGenerics.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java ! test/com/sun/javadoc/testWarnings/TestWarnings.java Changeset: 6dcf94e32a3a Author: emc Date: 2013-10-10 13:55 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/6dcf94e32a3a 8019461: Clean up javac diagnostics 7196553: Review error messages for repeating annotations Summary: Changes to the diagnostic messages to improve clarity and JLS coherence Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/DuplicateAnnotation.java + test/tools/javac/diags/examples/InterfaceOrArrayExpected.java + test/tools/javac/diags/examples/RepeatableAnnotationsNotSupported.java Changeset: b1b4a6dcc282 Author: emc Date: 2013-10-10 20:12 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/b1b4a6dcc282 8008762: Type annotation on inner class in anonymous class show up as regular type annotations 8015257: type annotation with TYPE_USE and FIELD attributed differently if repeated. 8013409: test failures for type annotations Summary: Fixes to address some problems in type annotations Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/annotations/typeAnnotations/classfile/TestAnonInnerClasses.java + test/tools/javac/annotations/typeAnnotations/classfile/testanoninner.template ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java Changeset: f068d235c4f7 Author: jjg Date: 2013-10-10 17:13 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/f068d235c4f7 8026294: 8025633 breaks langtools/test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java Reviewed-by: darcy ! test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java Changeset: 8f293c710369 Author: lana Date: 2013-10-10 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/8f293c710369 Merge Changeset: bf33f4f81b40 Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/bf33f4f81b40 Merge - test/tools/javac/diags/examples/DuplicateAnnotation.java Changeset: 1ce8405af5fe Author: rfield Date: 2013-10-10 23:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/1ce8405af5fe 8012557: Implement lambda methods on interfaces as private 8016320: Method reference in subinterface of type I.super::foo produces exception at runtime Summary: Now that the VM supports interface instance private methods, lambda methods and lambda bridges are always private. Access is now through invokespecial. Reviewed-by: vromero, jlahoda ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java + test/tools/javac/lambda/8012557/A.java + test/tools/javac/lambda/8012557/B.java + test/tools/javac/lambda/8012557/C.java + test/tools/javac/lambda/8012557/PrivateLambdas.java + test/tools/javac/lambda/8012557/SAM.java + test/tools/javac/lambda/8016320/IllegalBridgeModifier.java Changeset: 872c4a898b38 Author: jlahoda Date: 2013-10-11 15:49 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/872c4a898b38 6278240: Exception from AnnotationValue.getValue() should list the found type not the required type Reviewed-by: darcy, jfranck, jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Processor.java + test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Source.java + test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Source.out Changeset: f329c374da4b Author: lana Date: 2013-10-11 23:31 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/f329c374da4b Merge Changeset: b024fe427d24 Author: jjg Date: 2013-10-14 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/b024fe427d24 8026368: doclint does not report empty tags when tag closed implicitly Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! test/tools/doclint/HtmlAttrsTest.java ! test/tools/doclint/HtmlAttrsTest.out ! test/tools/doclint/tidy/BadEnd.out ! test/tools/doclint/tidy/TrimmingEmptyTag.java ! test/tools/doclint/tidy/TrimmingEmptyTag.out Changeset: 87b5bfef7edb Author: jlahoda Date: 2013-10-14 22:11 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/87b5bfef7edb 8014016: javac is too late detecting invalid annotation usage Summary: Adding new queue to Annotate for validation tasks, performing annotation validation during enter Reviewed-by: jjg, emc, jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateFunctionalInterface.java + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateSuperInterfaceProcessor.java + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/Processor.java + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/Source.java Changeset: b9e3b55a908c Author: jjg Date: 2013-10-14 16:28 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/b9e3b55a908c 8026371: "tidy" issues in langtools/src/**/*.html files Reviewed-by: darcy + src/share/classes/com/sun/javadoc/package-info.java - src/share/classes/com/sun/javadoc/package.html + src/share/classes/com/sun/tools/classfile/package-info.java - src/share/classes/com/sun/tools/classfile/package.html + src/share/classes/com/sun/tools/doclets/formats/html/markup/package-info.java - src/share/classes/com/sun/tools/doclets/formats/html/markup/package.html + src/share/classes/com/sun/tools/doclets/formats/html/package-info.java - src/share/classes/com/sun/tools/doclets/formats/html/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package.html + src/share/classes/com/sun/tools/doclets/package-info.java - src/share/classes/com/sun/tools/doclets/package.html + src/share/classes/com/sun/tools/javap/package-info.java - src/share/classes/com/sun/tools/javap/package.html ! src/share/classes/javax/lang/model/overview.html ! src/share/classes/javax/tools/overview.html Changeset: 7d266a2b31b2 Author: jjg Date: 2013-10-14 22:34 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/7d266a2b31b2 8025693: recent javadoc changes cause com/sun/javadoc/testLinkOption/TestLinkOption.java to fail Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java + test/tools/javadoc/8025693/Test.java Changeset: 09a414673570 Author: jjg Date: 2013-10-14 23:07 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/09a414673570 8025998: Missing LV table in lambda bodies Reviewed-by: vromero ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/lambda/LocalVariableTable.java Changeset: 79649bf21a92 Author: jlahoda Date: 2013-10-15 16:23 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/79649bf21a92 8026180: com.sun.source.tree.NewArrayTree refers to com.sun.tools.javac.util.List Summary: Correcting import in NewArrayTree, adding test protecting againts improper types in API signatures Reviewed-by: jjg ! src/share/classes/com/sun/source/tree/NewArrayTree.java + test/tools/javac/tree/NoPrivateTypesExported.java Changeset: bf6b11347b1a Author: bpatel Date: 2013-10-15 11:20 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/bf6b11347b1a 8026370: javadoc creates empty Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java + test/com/sun/javadoc/testTagOutput/TestTagOutput.java + test/com/sun/javadoc/testTagOutput/pkg1/DeprecatedTag.java Changeset: 70a301b35e71 Author: vromero Date: 2013-10-15 19:36 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/70a301b35e71 8025816: javac crash with method reference with a type variable as the site Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/T8025816/CrashMethodReferenceWithSiteTypeVarTest.java Changeset: d8d6b58f1ebf Author: vromero Date: 2013-10-15 21:02 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/d8d6b58f1ebf 8024947: javac should issue the potentially ambiguous overload warning only where the problem appears Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest.java + test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest.out Changeset: 84df20dc604a Author: bpatel Date: 2013-07-24 15:18 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/84df20dc604a 8016675: Make Javadoc pages more robust Reviewed-by: jlaskey, ksrini ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java + test/com/sun/javadoc/testWindowTitle/TestWindowTitle.java + test/com/sun/javadoc/testWindowTitle/p1/C1.java + test/com/sun/javadoc/testWindowTitle/p2/C2.java Changeset: 8b3e2cc5f1de Author: chegar Date: 2013-07-25 19:06 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/8b3e2cc5f1de Merge - test/tools/javac/generics/6723444/T6723444.out - test/tools/javac/generics/7015430/T7015430.out Changeset: 0d75d3b96477 Author: chegar Date: 2013-08-02 11:11 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/0d75d3b96477 Merge Changeset: 2d1a54d213c2 Author: chegar Date: 2013-08-09 14:44 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/2d1a54d213c2 Merge Changeset: 84b6d75ff2c9 Author: chegar Date: 2013-08-15 21:34 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/84b6d75ff2c9 Merge Changeset: a540e2a926cf Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/a540e2a926cf Merge Changeset: a8f0c3583a86 Author: chegar Date: 2013-08-30 10:17 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/a8f0c3583a86 Merge - test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java Changeset: 6250a7f0aba6 Author: chegar Date: 2013-09-06 10:05 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/6250a7f0aba6 Merge - test/com/sun/javadoc/testNavagation/TestNavagation.java - test/com/sun/javadoc/testNavagation/pkg/A.java - test/com/sun/javadoc/testNavagation/pkg/C.java - test/com/sun/javadoc/testNavagation/pkg/E.java - test/com/sun/javadoc/testNavagation/pkg/I.java - test/tools/javac/8015701/AnonymousParameters.java Changeset: a6901af8a2e4 Author: chegar Date: 2013-09-14 20:46 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/a6901af8a2e4 Merge Changeset: 2c13a5da6854 Author: chegar Date: 2013-10-03 19:28 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/2c13a5da6854 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java - src/share/classes/com/sun/tools/javac/code/Annotations.java - test/tools/javac/diags/examples/CyclicInference.java - test/tools/javac/diags/examples/MrefStat.java.rej - test/tools/javac/diags/examples/MrefStat1.java.rej - test/tools/javac/lambda/TargetType10.out - test/tools/javac/lambda/typeInference/InferenceTest5.java - test/tools/javac/lambda/typeInference/InferenceTest_neg5.java - test/tools/javac/lambda/typeInference/InferenceTest_neg5.out Changeset: 86e57f576e65 Author: chegar Date: 2013-10-11 19:05 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/86e57f576e65 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java Changeset: 46feacb99698 Author: chegar Date: 2013-10-15 14:17 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/46feacb99698 Merge - src/share/classes/com/sun/javadoc/package.html - src/share/classes/com/sun/tools/classfile/package.html - src/share/classes/com/sun/tools/doclets/formats/html/markup/package.html - src/share/classes/com/sun/tools/doclets/formats/html/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package.html - src/share/classes/com/sun/tools/doclets/package.html - src/share/classes/com/sun/tools/javap/package.html Changeset: 90c9ae4bc756 Author: chegar Date: 2013-10-15 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/90c9ae4bc756 Merge Changeset: dd073728085d Author: chegar Date: 2013-10-15 21:12 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/dd073728085d Merge Changeset: 19e8eebfbe52 Author: jlahoda Date: 2013-10-15 22:15 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/19e8eebfbe52 8026510: The name of com.sun.tools.javac.comp.Annotate.Annotator is confusing Summary: A mostly automated rename Annotate.Annotator->Annotate.Worker and enterAnnotation->run. Reviewed-by: emc, jjg ! src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java Changeset: b0c086cd4520 Author: jjg Date: 2013-10-15 15:57 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/b0c086cd4520 8026564: import changes from type-annotations forest Reviewed-by: jjg Contributed-by: wdietl at gmail.com, steve.sides at oracle.com ! make/build.properties ! make/build.xml ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java ! test/tools/javac/T7042623.java ! test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java + test/tools/javac/annotations/typeAnnotations/classfile/Scopes.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.out ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.out ! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion7.out ! test/tools/javac/annotations/typeAnnotations/failures/BadCast.java ! test/tools/javac/annotations/typeAnnotations/failures/BadCast.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.out ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java - test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.out ! test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.java ! test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.out - test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.java - test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.out ! test/tools/javac/annotations/typeAnnotations/failures/IndexArray.java ! test/tools/javac/annotations/typeAnnotations/failures/IndexArray.out ! test/tools/javac/annotations/typeAnnotations/failures/LintCast.out ! test/tools/javac/annotations/typeAnnotations/failures/OldArray.java + test/tools/javac/annotations/typeAnnotations/failures/OldArray.out ! test/tools/javac/annotations/typeAnnotations/failures/Scopes.java ! test/tools/javac/annotations/typeAnnotations/failures/Scopes.out ! test/tools/javac/annotations/typeAnnotations/failures/StaticFields.java ! test/tools/javac/annotations/typeAnnotations/failures/StaticFields.out - test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java - test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out ! test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.out - test/tools/javac/diags/examples/CantAnnotateNestedType.java + test/tools/javac/diags/examples/CantAnnotateScoping.java + test/tools/javac/diags/examples/CantAnnotateScoping1.java - test/tools/javac/diags/examples/CantAnnotateStaticClass.java ! test/tools/javac/lib/DPrinter.java ! test/tools/javac/processing/model/type/BasicAnnoTests.java Changeset: d7e155f874a7 Author: jjg Date: 2013-10-16 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/d7e155f874a7 8026704: Build failure with --enable-debug Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java - test/tools/javac/lambda/LocalVariableTable.java Changeset: 7f6481e5fe3a Author: emc Date: 2013-10-16 16:33 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/7f6481e5fe3a 8026286: Improper locking of annotation queues causes assertion failures. 8026063: Calls to annotate.flush() cause incorrect type annotations to be generated. Summary: Fix locking in ClassReader.java Reviewed-by: jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/annotations/typeAnnotations/TestAnonInnerInstance1.java ! test/tools/javac/annotations/typeAnnotations/classfile/T8008762.java Changeset: a48d3b981083 Author: mnunez Date: 2013-10-17 13:27 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/a48d3b981083 8015372: Update tests for Method Parameter Reflection API to check whether a parameter is final Reviewed-by: jjg, jfranck ! test/tools/javac/MethodParameters/AnnotationTest.java + test/tools/javac/MethodParameters/AnnotationTest.out ! test/tools/javac/MethodParameters/AnonymousClass.java + test/tools/javac/MethodParameters/AnonymousClass.out ! test/tools/javac/MethodParameters/ClassFileVisitor.java ! test/tools/javac/MethodParameters/Constructors.java + test/tools/javac/MethodParameters/Constructors.out ! test/tools/javac/MethodParameters/EnumTest.java + test/tools/javac/MethodParameters/EnumTest.out ! test/tools/javac/MethodParameters/InstanceMethods.java + test/tools/javac/MethodParameters/InstanceMethods.out ! test/tools/javac/MethodParameters/LambdaTest.java + test/tools/javac/MethodParameters/LambdaTest.out ! test/tools/javac/MethodParameters/LocalClassTest.java + test/tools/javac/MethodParameters/LocalClassTest.out ! test/tools/javac/MethodParameters/MemberClassTest.java + test/tools/javac/MethodParameters/MemberClassTest.out ! test/tools/javac/MethodParameters/ReflectionVisitor.java ! test/tools/javac/MethodParameters/StaticMethods.java + test/tools/javac/MethodParameters/StaticMethods.out ! test/tools/javac/MethodParameters/Tester.java ! test/tools/javac/MethodParameters/UncommonParamNames.java + test/tools/javac/MethodParameters/UncommonParamNames.out Changeset: 4d8af6fda907 Author: mnunez Date: 2013-10-17 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/4d8af6fda907 8008192: Better ordering checks needed in repeatingAnnotations/combo/ReflectionTest Reviewed-by: jjg, jfranck ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java ! test/tools/javac/annotations/repeatingAnnotations/combo/ReflectionTest.java Changeset: defadd528513 Author: mchung Date: 2013-10-17 13:19 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/defadd528513 8015912: jdeps support to output in dot file format 8026255: Switch jdeps to follow traditional Java option style Reviewed-by: alanb ! src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/Archive.java ! src/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java + src/share/classes/com/sun/tools/jdeps/Profile.java - src/share/classes/com/sun/tools/jdeps/Profiles.java ! src/share/classes/com/sun/tools/jdeps/resources/jdeps.properties + test/tools/jdeps/APIDeps.java ! test/tools/jdeps/Basic.java ! test/tools/jdeps/Test.java + test/tools/jdeps/b/B.java + test/tools/jdeps/c/C.java + test/tools/jdeps/c/I.java + test/tools/jdeps/d/D.java + test/tools/jdeps/e/E.java + test/tools/jdeps/f/F.java + test/tools/jdeps/g/G.java + test/tools/jdeps/m/Bar.java + test/tools/jdeps/m/Foo.java + test/tools/jdeps/m/Gee.java Changeset: bca97b47f0a2 Author: lana Date: 2013-10-17 16:13 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/bca97b47f0a2 Merge Changeset: 127c2e74d2cf Author: tbell Date: 2013-10-22 16:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/127c2e74d2cf 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 54150586ba78 Author: katleman Date: 2013-10-23 08:50 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/54150586ba78 Merge Changeset: 850d2602ae98 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/850d2602ae98 Added tag jdk8-b113 for changeset 54150586ba78 ! .hgtags From lana.steuck at oracle.com Fri Oct 25 12:49:02 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 25 Oct 2013 19:49:02 +0000 Subject: hg: jdk8/awt/jdk: 172 new changesets Message-ID: <20131025204515.3153D6276C@hg.openjdk.java.net> Changeset: 28191d3ff921 Author: erikj Date: 2013-10-09 16:22 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/28191d3ff921 8026144: Missing mkdir in Images.gmk Reviewed-by: tbell ! makefiles/Images.gmk Changeset: 86df2e879eca Author: tbell Date: 2013-10-09 18:50 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/86df2e879eca 8023611: Win32 and win64: Remove all the WARNINGS in JDK 8 builds for Windows 2008 and MSVS 2010 SP1 Reviewed-by: erikj ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk Changeset: 98d98ec01f07 Author: tbell Date: 2013-10-09 23:19 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/98d98ec01f07 Merge Changeset: 9c60860b1812 Author: ihse Date: 2013-10-10 15:06 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9c60860b1812 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildJdk.gmk ! makefiles/Bundles.gmk ! 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/GendataTZDB.gmk ! makefiles/GendataTimeZone.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateData.gmk ! makefiles/GenerateJavaSources.gmk ! makefiles/GensrcBuffer.gmk ! makefiles/GensrcCLDR.gmk ! makefiles/GensrcCharacterData.gmk ! makefiles/GensrcCharsetCoder.gmk ! makefiles/GensrcCharsetMapping.gmk ! makefiles/GensrcExceptions.gmk ! makefiles/GensrcIcons.gmk ! makefiles/GensrcJDWP.gmk ! makefiles/GensrcJObjC.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcSwing.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk ! makefiles/Makefile ! makefiles/PatchList.solaris ! makefiles/ProfileNames.gmk ! makefiles/Profiles.gmk ! makefiles/Setup.gmk ! makefiles/SignJars.gmk ! makefiles/Tools.gmk ! makefiles/jpda/jdwp/jdwp.spec ! makefiles/jprt.gmk ! makefiles/jprt.properties ! makefiles/mapfiles/libawt/mapfile-mawt-vers ! makefiles/mapfiles/libawt/mapfile-vers ! makefiles/mapfiles/libawt/mapfile-vers-linux ! makefiles/mapfiles/libawt_headless/mapfile-vers ! makefiles/mapfiles/libawt_xawt/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk ! makefiles/mapfiles/libj2pcsc/mapfile-vers ! makefiles/mapfiles/libjdga/mapfile-vers ! makefiles/mapfiles/libjli/mapfile-vers ! makefiles/mapfiles/libverify/mapfile-vers ! makefiles/profile-includes.txt ! makefiles/profile-rtjar-includes.txt ! makefiles/scripts/addNotices.sh ! makefiles/scripts/genCharsetProvider.sh ! makefiles/scripts/genExceptions.sh ! makefiles/scripts/localelist.sh ! makefiles/sun/awt/ToBin.java Changeset: cf3ee0e2c1a5 Author: erikj Date: 2013-10-14 11:36 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/cf3ee0e2c1a5 8025612: rt.jar still has old specification value in the manifest Reviewed-by: alanb, dholmes, tbell, wetmore ! make/tools/manifest.mf Changeset: 986acae7efe9 Author: ihse Date: 2013-10-15 13:06 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/986acae7efe9 8001933: Move Gensrc*.gmk and Gendata*.gmk into separate directories. Reviewed-by: erikj, tbell ! makefiles/BuildJdk.gmk ! makefiles/CreateJars.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk ! makefiles/GenerateData.gmk - makefiles/GenerateJavaSources.gmk + makefiles/GenerateSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk + makefiles/gendata/GendataBreakIterator.gmk + makefiles/gendata/GendataFontConfig.gmk + makefiles/gendata/GendataHtml32dtd.gmk + makefiles/gendata/GendataTZDB.gmk + makefiles/gendata/GendataTimeZone.gmk + makefiles/gensrc/GensrcBuffer.gmk + makefiles/gensrc/GensrcCLDR.gmk + makefiles/gensrc/GensrcCharacterData.gmk + makefiles/gensrc/GensrcCharsetCoder.gmk + makefiles/gensrc/GensrcCharsetMapping.gmk + makefiles/gensrc/GensrcExceptions.gmk + makefiles/gensrc/GensrcIcons.gmk + makefiles/gensrc/GensrcJDWP.gmk + makefiles/gensrc/GensrcJObjC.gmk + makefiles/gensrc/GensrcLocaleDataMetaInfo.gmk + makefiles/gensrc/GensrcMisc.gmk + makefiles/gensrc/GensrcProperties.gmk + makefiles/gensrc/GensrcSwing.gmk + makefiles/gensrc/GensrcX11Wrappers.gmk Changeset: eef656e1bdeb Author: ksrini Date: 2013-10-16 07:37 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/eef656e1bdeb 8026500: [infra] remove extraneous docs in solaris images Reviewed-by: erikj, mchung, tbell ! makefiles/Images.gmk - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 Changeset: f002f5f3a16c Author: katleman Date: 2013-10-16 12:02 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f002f5f3a16c Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk - makefiles/GenerateJavaSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk ! makefiles/Profiles.gmk ! makefiles/profile-includes.txt - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 Changeset: bef8f6d429de Author: cl Date: 2013-10-17 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bef8f6d429de Added tag jdk8-b112 for changeset f002f5f3a16c ! .hgtags Changeset: f1e31376f419 Author: robm Date: 2013-10-09 00:10 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f1e31376f419 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs Reviewed-by: chegar, dsamersoff ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 2ea162b2ff55 Author: alanb Date: 2013-10-09 09:20 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2ea162b2ff55 8008662: Add @jdk.Exported to JDK-specific/exported APIs Reviewed-by: chegar, vinnie, dfuchs, mchung, mullan, darcy ! src/share/classes/com/sun/jdi/AbsentInformationException.java ! src/share/classes/com/sun/jdi/Accessible.java ! src/share/classes/com/sun/jdi/ArrayReference.java ! src/share/classes/com/sun/jdi/ArrayType.java ! src/share/classes/com/sun/jdi/BooleanType.java ! src/share/classes/com/sun/jdi/BooleanValue.java ! src/share/classes/com/sun/jdi/Bootstrap.java ! src/share/classes/com/sun/jdi/ByteType.java ! src/share/classes/com/sun/jdi/ByteValue.java ! src/share/classes/com/sun/jdi/CharType.java ! src/share/classes/com/sun/jdi/CharValue.java ! src/share/classes/com/sun/jdi/ClassLoaderReference.java ! src/share/classes/com/sun/jdi/ClassNotLoadedException.java ! src/share/classes/com/sun/jdi/ClassNotPreparedException.java ! src/share/classes/com/sun/jdi/ClassObjectReference.java ! src/share/classes/com/sun/jdi/ClassType.java ! src/share/classes/com/sun/jdi/DoubleType.java ! src/share/classes/com/sun/jdi/DoubleValue.java ! src/share/classes/com/sun/jdi/Field.java ! src/share/classes/com/sun/jdi/FloatType.java ! src/share/classes/com/sun/jdi/FloatValue.java ! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java ! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java ! src/share/classes/com/sun/jdi/IntegerType.java ! src/share/classes/com/sun/jdi/IntegerValue.java ! src/share/classes/com/sun/jdi/InterfaceType.java ! src/share/classes/com/sun/jdi/InternalException.java ! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java ! src/share/classes/com/sun/jdi/InvalidLineNumberException.java ! src/share/classes/com/sun/jdi/InvalidStackFrameException.java ! src/share/classes/com/sun/jdi/InvalidTypeException.java ! src/share/classes/com/sun/jdi/InvocationException.java ! src/share/classes/com/sun/jdi/JDIPermission.java ! src/share/classes/com/sun/jdi/LocalVariable.java ! src/share/classes/com/sun/jdi/Locatable.java ! src/share/classes/com/sun/jdi/Location.java ! src/share/classes/com/sun/jdi/LongType.java ! src/share/classes/com/sun/jdi/LongValue.java ! src/share/classes/com/sun/jdi/Method.java ! src/share/classes/com/sun/jdi/Mirror.java ! src/share/classes/com/sun/jdi/MonitorInfo.java ! src/share/classes/com/sun/jdi/NativeMethodException.java ! src/share/classes/com/sun/jdi/ObjectCollectedException.java ! src/share/classes/com/sun/jdi/ObjectReference.java ! src/share/classes/com/sun/jdi/PathSearchingVirtualMachine.java ! src/share/classes/com/sun/jdi/PrimitiveType.java ! src/share/classes/com/sun/jdi/PrimitiveValue.java ! src/share/classes/com/sun/jdi/ReferenceType.java ! src/share/classes/com/sun/jdi/ShortType.java ! src/share/classes/com/sun/jdi/ShortValue.java ! src/share/classes/com/sun/jdi/StackFrame.java ! src/share/classes/com/sun/jdi/StringReference.java ! src/share/classes/com/sun/jdi/ThreadGroupReference.java ! src/share/classes/com/sun/jdi/ThreadReference.java ! src/share/classes/com/sun/jdi/Type.java ! src/share/classes/com/sun/jdi/TypeComponent.java ! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java ! src/share/classes/com/sun/jdi/VMDisconnectedException.java ! src/share/classes/com/sun/jdi/VMMismatchException.java ! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java ! src/share/classes/com/sun/jdi/Value.java ! src/share/classes/com/sun/jdi/VirtualMachine.java ! src/share/classes/com/sun/jdi/VirtualMachineManager.java ! src/share/classes/com/sun/jdi/VoidType.java ! src/share/classes/com/sun/jdi/VoidValue.java ! src/share/classes/com/sun/jdi/connect/AttachingConnector.java ! src/share/classes/com/sun/jdi/connect/Connector.java ! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java ! src/share/classes/com/sun/jdi/connect/LaunchingConnector.java ! src/share/classes/com/sun/jdi/connect/ListeningConnector.java ! src/share/classes/com/sun/jdi/connect/Transport.java ! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java ! src/share/classes/com/sun/jdi/connect/VMStartException.java + src/share/classes/com/sun/jdi/connect/package-info.java - src/share/classes/com/sun/jdi/connect/package.html ! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/share/classes/com/sun/jdi/connect/spi/Connection.java ! src/share/classes/com/sun/jdi/connect/spi/TransportService.java + src/share/classes/com/sun/jdi/connect/spi/package-info.java - src/share/classes/com/sun/jdi/connect/spi/package.html ! src/share/classes/com/sun/jdi/event/AccessWatchpointEvent.java ! src/share/classes/com/sun/jdi/event/BreakpointEvent.java ! src/share/classes/com/sun/jdi/event/ClassPrepareEvent.java ! src/share/classes/com/sun/jdi/event/ClassUnloadEvent.java ! src/share/classes/com/sun/jdi/event/Event.java ! src/share/classes/com/sun/jdi/event/EventIterator.java ! src/share/classes/com/sun/jdi/event/EventQueue.java ! src/share/classes/com/sun/jdi/event/EventSet.java ! src/share/classes/com/sun/jdi/event/ExceptionEvent.java ! src/share/classes/com/sun/jdi/event/LocatableEvent.java ! src/share/classes/com/sun/jdi/event/MethodEntryEvent.java ! src/share/classes/com/sun/jdi/event/MethodExitEvent.java ! src/share/classes/com/sun/jdi/event/ModificationWatchpointEvent.java ! src/share/classes/com/sun/jdi/event/MonitorContendedEnterEvent.java ! src/share/classes/com/sun/jdi/event/MonitorContendedEnteredEvent.java ! src/share/classes/com/sun/jdi/event/MonitorWaitEvent.java ! src/share/classes/com/sun/jdi/event/MonitorWaitedEvent.java ! src/share/classes/com/sun/jdi/event/StepEvent.java ! src/share/classes/com/sun/jdi/event/ThreadDeathEvent.java ! src/share/classes/com/sun/jdi/event/ThreadStartEvent.java ! src/share/classes/com/sun/jdi/event/VMDeathEvent.java ! src/share/classes/com/sun/jdi/event/VMDisconnectEvent.java ! src/share/classes/com/sun/jdi/event/VMStartEvent.java ! src/share/classes/com/sun/jdi/event/WatchpointEvent.java + src/share/classes/com/sun/jdi/event/package-info.java - src/share/classes/com/sun/jdi/event/package.html + src/share/classes/com/sun/jdi/package-info.java - src/share/classes/com/sun/jdi/package.html ! src/share/classes/com/sun/jdi/request/AccessWatchpointRequest.java ! src/share/classes/com/sun/jdi/request/BreakpointRequest.java ! src/share/classes/com/sun/jdi/request/ClassPrepareRequest.java ! src/share/classes/com/sun/jdi/request/ClassUnloadRequest.java ! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java ! src/share/classes/com/sun/jdi/request/EventRequest.java ! src/share/classes/com/sun/jdi/request/EventRequestManager.java ! src/share/classes/com/sun/jdi/request/ExceptionRequest.java ! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java ! src/share/classes/com/sun/jdi/request/MethodEntryRequest.java ! src/share/classes/com/sun/jdi/request/MethodExitRequest.java ! src/share/classes/com/sun/jdi/request/ModificationWatchpointRequest.java ! src/share/classes/com/sun/jdi/request/MonitorContendedEnterRequest.java ! src/share/classes/com/sun/jdi/request/MonitorContendedEnteredRequest.java ! src/share/classes/com/sun/jdi/request/MonitorWaitRequest.java ! src/share/classes/com/sun/jdi/request/MonitorWaitedRequest.java ! src/share/classes/com/sun/jdi/request/StepRequest.java ! src/share/classes/com/sun/jdi/request/ThreadDeathRequest.java ! src/share/classes/com/sun/jdi/request/ThreadStartRequest.java ! src/share/classes/com/sun/jdi/request/VMDeathRequest.java ! src/share/classes/com/sun/jdi/request/WatchpointRequest.java + src/share/classes/com/sun/jdi/request/package-info.java - src/share/classes/com/sun/jdi/request/package.html ! src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java ! src/share/classes/com/sun/management/GarbageCollectorMXBean.java ! src/share/classes/com/sun/management/GcInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/com/sun/management/OperatingSystemMXBean.java ! src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/com/sun/management/UnixOperatingSystemMXBean.java ! src/share/classes/com/sun/management/VMOption.java + src/share/classes/com/sun/management/package-info.java - src/share/classes/com/sun/management/package.html ! src/share/classes/com/sun/net/httpserver/Authenticator.java ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/com/sun/net/httpserver/Filter.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/HttpContext.java ! src/share/classes/com/sun/net/httpserver/HttpExchange.java ! src/share/classes/com/sun/net/httpserver/HttpHandler.java ! src/share/classes/com/sun/net/httpserver/HttpPrincipal.java ! src/share/classes/com/sun/net/httpserver/HttpServer.java ! src/share/classes/com/sun/net/httpserver/HttpsConfigurator.java ! src/share/classes/com/sun/net/httpserver/HttpsExchange.java ! src/share/classes/com/sun/net/httpserver/HttpsParameters.java ! src/share/classes/com/sun/net/httpserver/HttpsServer.java ! src/share/classes/com/sun/net/httpserver/package-info.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/httpserver/spi/package-info.java ! src/share/classes/com/sun/nio/sctp/AbstractNotificationHandler.java ! src/share/classes/com/sun/nio/sctp/Association.java ! src/share/classes/com/sun/nio/sctp/AssociationChangeNotification.java ! src/share/classes/com/sun/nio/sctp/HandlerResult.java ! src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java ! src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java ! src/share/classes/com/sun/nio/sctp/InvalidStreamException.java ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/Notification.java ! src/share/classes/com/sun/nio/sctp/NotificationHandler.java ! src/share/classes/com/sun/nio/sctp/PeerAddressChangeNotification.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java ! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java ! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java ! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java ! src/share/classes/com/sun/nio/sctp/SendFailedNotification.java ! src/share/classes/com/sun/nio/sctp/ShutdownNotification.java ! src/share/classes/com/sun/nio/sctp/package-info.java ! src/share/classes/com/sun/security/auth/LdapPrincipal.java ! src/share/classes/com/sun/security/auth/NTDomainPrincipal.java ! src/share/classes/com/sun/security/auth/NTNumericCredential.java ! src/share/classes/com/sun/security/auth/NTSid.java ! src/share/classes/com/sun/security/auth/NTSidDomainPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidGroupPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidPrimaryGroupPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidUserPrincipal.java ! src/share/classes/com/sun/security/auth/NTUserPrincipal.java ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/PrincipalComparator.java ! src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java ! src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java ! src/share/classes/com/sun/security/auth/SolarisPrincipal.java ! src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java ! src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java ! src/share/classes/com/sun/security/auth/UnixPrincipal.java ! src/share/classes/com/sun/security/auth/UserPrincipal.java ! src/share/classes/com/sun/security/auth/X500Principal.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java + src/share/classes/com/sun/security/auth/callback/package-info.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java + src/share/classes/com/sun/security/auth/login/package-info.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/share/classes/com/sun/security/auth/module/NTLoginModule.java ! src/share/classes/com/sun/security/auth/module/NTSystem.java ! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java ! src/share/classes/com/sun/security/auth/module/SolarisSystem.java ! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java ! src/share/classes/com/sun/security/auth/module/UnixSystem.java + src/share/classes/com/sun/security/auth/module/package-info.java + src/share/classes/com/sun/security/auth/package-info.java ! src/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java ! src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java ! src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java ! src/share/classes/com/sun/security/jgss/GSSUtil.java ! src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java ! src/share/classes/com/sun/security/jgss/InquireType.java + src/share/classes/com/sun/security/jgss/package-info.java ! src/share/classes/com/sun/tools/attach/AgentInitializationException.java ! src/share/classes/com/sun/tools/attach/AgentLoadException.java ! src/share/classes/com/sun/tools/attach/AttachNotSupportedException.java ! src/share/classes/com/sun/tools/attach/AttachPermission.java ! src/share/classes/com/sun/tools/attach/VirtualMachine.java ! src/share/classes/com/sun/tools/attach/VirtualMachineDescriptor.java + src/share/classes/com/sun/tools/attach/package-info.java - src/share/classes/com/sun/tools/attach/package.html ! src/share/classes/com/sun/tools/attach/spi/AttachProvider.java + src/share/classes/com/sun/tools/attach/spi/package-info.java - src/share/classes/com/sun/tools/attach/spi/package.html ! src/share/classes/com/sun/tools/jconsole/JConsoleContext.java ! src/share/classes/com/sun/tools/jconsole/JConsolePlugin.java + src/share/classes/com/sun/tools/jconsole/package-info.java - src/share/classes/com/sun/tools/jconsole/package.html ! src/solaris/classes/com/sun/management/OSMBeanFactory.java Changeset: 91a752e3d50b Author: vinnie Date: 2013-10-09 10:48 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/91a752e3d50b 8008171: Refactor KeyStore.DomainLoadStoreParameter as a standalone class Reviewed-by: mullan, weijun + src/share/classes/java/security/DomainLoadStoreParameter.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/sun/security/provider/DomainKeyStore.java ! test/sun/security/provider/KeyStore/DKSTest.java Changeset: 1cd20806fd5c Author: psandoz Date: 2013-10-09 15:19 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1cd20806fd5c 8020061: Clarify reporting characteristics between splits Reviewed-by: alanb, chegar ! src/share/classes/java/util/Spliterator.java Changeset: cf6e39cfdf50 Author: mchung Date: 2013-10-09 06:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/cf6e39cfdf50 8026027: Level.parse should return the custom Level instance instead of the mirrored Level Reviewed-by: dfuchs, chegar ! src/share/classes/java/util/logging/Level.java + test/java/util/logging/Level/CustomLevel.java + test/java/util/logging/Level/myresource.properties Changeset: e3b70e601c1c Author: rriggs Date: 2013-10-09 11:02 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e3b70e601c1c 8024612: java/time/tck/java/time/format/TCKDateTimeFormatters.java failed Summary: The test should be using the Locale.Category.FORMAT to verify the test data Reviewed-by: lancea ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java Changeset: 09e2a73aa1dc Author: rriggs Date: 2013-09-26 15:19 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/09e2a73aa1dc 8025718: Enhance error messages for parsing Summary: Add values and types to exception messages Reviewed-by: lancea Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/format/Parsed.java ! test/java/time/test/java/time/format/TestDateTimeFormatter.java Changeset: c070001c4f60 Author: henryjen Date: 2013-10-09 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c070001c4f60 8023524: Mechanism to dump generated lambda classes / log lambda code generation Reviewed-by: plevart, mchung, forax, jjb Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + src/share/classes/java/lang/invoke/ProxyClassesDumper.java + test/java/lang/invoke/lambda/LogGeneratedClassesTest.java Changeset: d42fe440bda8 Author: rriggs Date: 2013-10-09 13:34 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d42fe440bda8 8024076: Incorrect 2 -> 4 year parsing and resolution in DateTimeFormatter Summary: Add appendValueReduced method based on a ChronoLocalDate to provide context for the value Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestReducedParser.java ! test/java/time/test/java/time/format/TestReducedPrinter.java Changeset: b86e6700266e Author: bpb Date: 2013-10-09 11:47 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b86e6700266e 8016252: More defensive HashSet.readObject Summary: Add data validation checks in readObject(). Reviewed-by: alanb, mduigou, chegar Contributed-by: Brian Burkhalter ! src/share/classes/java/util/HashSet.java + test/java/util/HashSet/Serialization.java Changeset: 1597066b58ee Author: valeriep Date: 2013-10-08 11:07 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1597066b58ee 7196382: PKCS11 provider should support 2048-bit DH Summary: Query and enforce range checking using the values from native PKCS11 library. Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java + test/sun/security/pkcs11/KeyPairGenerator/TestDH2048.java Changeset: 3da8be8d13bf Author: valeriep Date: 2013-10-08 11:17 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3da8be8d13bf 8012900: CICO ignores AAD in GCM mode Summary: Change GCM decryption to not return result until tag verification passed Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/CipherBlockChaining.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/CipherFeedback.java ! src/share/classes/com/sun/crypto/provider/CounterMode.java ! src/share/classes/com/sun/crypto/provider/ElectronicCodeBook.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java ! src/share/classes/com/sun/crypto/provider/GCTR.java ! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/share/classes/com/sun/crypto/provider/OutputFeedback.java ! src/share/classes/com/sun/crypto/provider/PCBC.java ! src/share/classes/javax/crypto/CipherSpi.java + test/com/sun/crypto/provider/Cipher/AES/TestCICOWithGCMAndAAD.java Changeset: f4305254f92f Author: valeriep Date: 2013-10-08 11:35 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f4305254f92f 8014374: Cannot initialize "AES/GCM/NoPadding" on wrap/unseal on solaris with OracleUcrypto Summary: Removed OracleUcrypto provider regression tests from OpenJDK Reviewed-by: xuelei - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java Changeset: e044b0151858 Author: valeriep Date: 2013-10-08 14:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e044b0151858 8025967: addition of -Werror broke the old build Summary: Fixed and suppressed compiler warnings on rawtypes Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java ! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java ! src/share/classes/java/lang/instrument/Instrumentation.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/javax/crypto/JceSecurityManager.java ! src/share/classes/sun/instrument/InstrumentationImpl.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java ! src/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java ! src/share/classes/sun/reflect/misc/MethodUtil.java ! src/share/classes/sun/security/provider/AuthPolicyFile.java ! src/share/classes/sun/security/provider/SubjectCodeSource.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java Changeset: 7a7b73a40bb1 Author: valeriep Date: 2013-10-09 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7a7b73a40bb1 Merge - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html Changeset: 673f8045311e Author: bpb Date: 2013-10-09 17:22 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/673f8045311e 7189139: BigInteger's staticRandom field can be a source of bottlenecks. Summary: Use ThreadLocalRandom instead of SecureRandom. Reviewed-by: shade, psandoz Contributed-by: Brian Burkhalter ! src/share/classes/java/math/BigInteger.java Changeset: eab3c09745b6 Author: bchristi Date: 2013-10-09 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/eab3c09745b6 8024709: TreeMap.DescendingKeyIterator 'remove' confuses iterator position Summary: Override remove() method in DescendingKeyIterator Reviewed-by: alanb, mduigou, psandoz ! src/share/classes/java/util/TreeMap.java ! test/java/util/Collection/MOAT.java Changeset: c13309f658e1 Author: darcy Date: 2013-10-09 18:31 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c13309f658e1 8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation Reviewed-by: mduigou, briangoetz ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/stream/DoubleStream.java Changeset: e901a618dcff Author: sjiang Date: 2013-10-10 08:37 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e901a618dcff 8025207: Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java Reviewed-by: dfuchs, dholmes ! test/javax/management/monitor/CounterMonitorThresholdTest.java Changeset: e8097e1e18a7 Author: sjiang Date: 2013-10-10 08:49 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e8097e1e18a7 8025206: Intermittent test failure: javax/management/monitor/NullAttributeValueTest.java Reviewed-by: dholmes, dfuchs, jbachorik ! test/javax/management/monitor/NullAttributeValueTest.java Changeset: a30f6fd581b3 Author: sjiang Date: 2013-10-10 09:01 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a30f6fd581b3 8025205: Intermittent test failure: javax/management/remote/mandatory/connection/BrokenConnectionTest.java Reviewed-by: dholmes, dfuchs, jbachorik ! test/javax/management/remote/mandatory/connection/BrokenConnectionTest.java Changeset: 74b4d20769fd Author: weijun Date: 2013-10-10 15:24 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/74b4d20769fd 8026235: keytool NSS test should use 64 bit lib on Solaris Reviewed-by: vinnie ! test/sun/security/tools/keytool/autotest.sh Changeset: 6aa637dde16e Author: sla Date: 2013-10-10 09:38 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6aa637dde16e 8025427: jstat tests fails on 32-bit platforms Reviewed-by: ehelin, dsamersoff, dholmes, sspitsyn ! src/share/classes/sun/tools/jstat/RowClosure.java ! test/ProblemList.txt ! test/sun/tools/jstat/gcCauseOutput1.awk ! test/sun/tools/jstat/lineCounts1.awk ! test/sun/tools/jstat/lineCounts2.awk ! test/sun/tools/jstat/lineCounts3.awk ! test/sun/tools/jstat/lineCounts4.awk ! test/sun/tools/jstat/timeStamp1.awk ! test/sun/tools/jstatd/jstatGcutilOutput1.awk Changeset: 998560cccefc Author: allwin Date: 2013-10-10 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/998560cccefc 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java Reviewed-by: sla, mgronlun, dholmes, jbachorik, chegar ! test/com/sun/jdi/NoLaunchOptionTest.java Changeset: 254173b48dcb Author: dholmes Date: 2013-10-10 04:57 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/254173b48dcb 8026232: Move libnpt from profile compact1 to compact3 Reviewed-by: mchung, alanb ! makefiles/profile-includes.txt Changeset: 99b7bbe0474f Author: dl Date: 2013-10-10 09:57 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/99b7bbe0474f 7011859: java/util/concurrent/Semaphore/RacingReleases.java failing Reviewed-by: alanb, dholmes ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java Changeset: 8294c49d23b3 Author: michaelm Date: 2013-10-10 12:36 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8294c49d23b3 7076487: (sctp) SCTP API classes does not exist in JDK for Mac Reviewed-by: alanb, chegar ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk + src/macosx/classes/sun/nio/ch/sctp/SctpChannelImpl.java + src/macosx/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java + src/macosx/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java Changeset: cab80088c671 Author: sjiang Date: 2013-10-10 17:47 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/cab80088c671 8025204: Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java Reviewed-by: dholmes, jbachorik ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java Changeset: f25d9d8811ca Author: jfranck Date: 2013-10-10 18:11 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f25d9d8811ca 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays Reviewed-by: darcy, psandoz ! src/share/classes/java/lang/reflect/Array.java + test/java/lang/Class/forName/arrayClass/Class1.java + test/java/lang/Class/forName/arrayClass/Class2.java + test/java/lang/Class/forName/arrayClass/Class3.java + test/java/lang/Class/forName/arrayClass/Class4.java + test/java/lang/Class/forName/arrayClass/ExceedMaxDim.java ! test/java/lang/reflect/Array/ExceedMaxDim.java Changeset: 4abfcbac1cb6 Author: emc Date: 2013-10-10 18:56 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4abfcbac1cb6 8026011: java.lang.reflect.MalformedParametersException introduces doclint warnings Summary: Add javadoc comments to members of MalformedParametersException Reviewed-by: darcy ! src/share/classes/java/lang/reflect/MalformedParametersException.java Changeset: a1d91e198ddf Author: lana Date: 2013-10-10 13:33 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a1d91e198ddf Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so ! test/sun/security/tools/keytool/autotest.sh Changeset: 1863a7e3a1c9 Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1863a7e3a1c9 Merge Changeset: 1a067bc31098 Author: lana Date: 2013-10-10 21:23 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1a067bc31098 Merge Changeset: 4ad76262bac8 Author: mullan Date: 2013-10-11 08:43 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4ad76262bac8 8007292: Add JavaFX internal packages to package.access Summary: build hooks to allow closed restricted packages to be added to java.security file Reviewed-by: erikj, dholmes, tbell ! make/java/security/Makefile ! make/tools/Makefile + make/tools/addtorestrictedpkgs/Makefile + make/tools/src/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java ! makefiles/CopyFiles.gmk ! makefiles/Tools.gmk ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 76df579c0b93 Author: mullan Date: 2013-10-11 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/76df579c0b93 Merge ! makefiles/Tools.gmk - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: cb373cf43294 Author: dxu Date: 2013-10-11 09:47 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/cb373cf43294 8025712: (props) Possible memory leak in java_props_md.c / ParseLocale Reviewed-by: naoto, chegar ! src/solaris/native/java/lang/java_props_md.c Changeset: d23247aa7462 Author: vinnie Date: 2013-10-11 20:35 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d23247aa7462 8026301: DomainKeyStore doesn't cleanup correctly when storing to keystore Reviewed-by: mullan ! src/share/classes/sun/security/provider/DomainKeyStore.java Changeset: 94493b5800bb Author: vinnie Date: 2013-10-11 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/94493b5800bb Merge Changeset: 9632de07d963 Author: alanb Date: 2013-10-11 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9632de07d963 8019526: (fs) Files.lines, etc without Charset parameter Reviewed-by: psandoz, henryjen ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java ! test/java/nio/file/Files/StreamTest.java Changeset: 4561460bf570 Author: rfield Date: 2013-10-11 15:21 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4561460bf570 8026213: Reflection support for private interface methods Reviewed-by: forax, psandoz, dholmes, jfranck Contributed-by: karen.kinnear at oracle.com ! src/share/classes/sun/reflect/AccessorGenerator.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java + test/java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java Changeset: fb202a8e83c9 Author: xuelei Date: 2013-10-13 21:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/fb202a8e83c9 8026119: Regression test DHEKeySizing.java failing intermittently Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java Changeset: 9f8bfdd99129 Author: dfuchs Date: 2013-10-14 10:42 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9f8bfdd99129 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. Reviewed-by: alanb, psandoz, mchung ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/util/ServiceLoader.java Changeset: 077237e4613f Author: tyan Date: 2013-10-14 11:47 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/077237e4613f 8023555: test/java/net/Socks/SocksProxyVersion.java fails when machine name is localhost Reviewed-by: chegar, alanb ! test/java/net/Socks/SocksProxyVersion.java Changeset: f15a0087181e Author: stefank Date: 2013-10-14 14:28 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f15a0087181e 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 Reviewed-by: coleenp, sla Contributed-by: stefan.karlsson at oracle.com, coleen.phillimore at oracle.com ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh Changeset: 96644227daed Author: lana Date: 2013-10-11 23:27 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/96644227daed Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk Changeset: 3a5c987ff3a0 Author: lana Date: 2013-10-14 09:52 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3a5c987ff3a0 Merge Changeset: dd0deeb04933 Author: michaelm Date: 2013-10-14 22:09 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dd0deeb04933 8014719: HttpClient/ProxyTest.java failing with IAE HttpURLPermission.parseURI Reviewed-by: alanb, chegar + src/share/classes/java/net/HostPortrange.java ! src/share/classes/java/net/HttpURLConnection.java - src/share/classes/java/net/HttpURLPermission.java + src/share/classes/java/net/URLPermission.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 + test/java/net/URLPermission/URLPermissionTest.java + test/java/net/URLPermission/URLTest.java + test/java/net/URLPermission/policy.1 + test/java/net/URLPermission/policy.2 + test/java/net/URLPermission/policy.3 Changeset: 94d4aa2fb414 Author: henryjen Date: 2013-10-14 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/94d4aa2fb414 8026362: java/lang/invoke/lambda/LogGeneratedClassesTest.java failed on windows, jtreg report Fail to org.testng.SkipException Reviewed-by: chegar ! test/java/lang/invoke/lambda/LogGeneratedClassesTest.java Changeset: 50e88f25255f Author: joehw Date: 2013-10-14 22:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/50e88f25255f 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Reviewed-by: lancea, alanb + test/javax/xml/jaxp/validation/8015092/XPathWhiteSpaceTest.java + test/javax/xml/jaxp/validation/8015092/idIxpns.xsd + test/javax/xml/jaxp/validation/8015092/idIxpns1.xsd + test/javax/xml/jaxp/validation/8015092/idJ029.xsd + test/javax/xml/jaxp/validation/8015092/idJimp.xsd Changeset: abe8d432f714 Author: jbachorik Date: 2013-10-15 10:26 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/abe8d432f714 6804470: JvmstatCountersTest.java test times out on slower machines Summary: Increasing the default timeout to cater for the slower machines Reviewed-by: alanb ! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java Changeset: 0b6632e570b0 Author: alanb Date: 2013-10-15 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0b6632e570b0 8026398: Can't load jdk.Exported, ClassNotFoundException Reviewed-by: chegar, mchung ! make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java Changeset: 2c16140fb515 Author: dfuchs Date: 2013-10-15 13:01 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2c16140fb515 8026404: Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") Summary: The test 'threadGroup.getParent() == null' can sometimes throw ACE and needs to be wrapped in doPrivileged. Reviewed-by: alanb, mchung, dholmes ! src/share/classes/sun/awt/AppContext.java ! test/TEST.groups + test/java/util/logging/TestMainAppContext.java Changeset: ea422834f880 Author: rriggs Date: 2013-09-26 23:05 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ea422834f880 8025720: Separate temporal interface layer Summary: Remove ZoneId and Chronology from TemporalField interface Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/WeekFields.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java Changeset: 110107410393 Author: scolebourne Date: 2013-07-09 21:35 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/110107410393 8025719: Change Chronology to an interface Summary: Split Chronology and add AbstractChronology Reviewed-by: darcy Contributed-by: scolebourne at joda.org + src/share/classes/java/time/chrono/AbstractChronology.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/Ser.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! test/java/time/tck/java/time/chrono/CopticChronology.java Changeset: 087c8c1d2631 Author: rriggs Date: 2013-10-15 13:14 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/087c8c1d2631 8025722: TemporalAdjusters and TemporalQueries Summary: Move static from interfaces methods to supporting classes Reviewed-by: sherman ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/chrono/AbstractChronology.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimePrintContext.java ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java ! src/share/classes/java/time/temporal/TemporalAdjusters.java ! src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalQueries.java ! src/share/classes/java/time/temporal/TemporalQuery.java ! src/share/classes/java/time/temporal/package-info.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/util/Formatter.java ! test/java/time/tck/java/time/TCKDayOfWeek.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonth.java ! test/java/time/tck/java/time/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/TestIsoChronology.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKIsoChronology.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java ! test/java/time/tck/java/time/format/TCKChronoPrinterParser.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java ! test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java ! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java ! test/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java ! test/java/time/test/java/time/format/TestCharLiteralParser.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/format/TestNumberParser.java ! test/java/time/test/java/time/format/TestStringLiteralParser.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java ! test/java/time/test/java/util/TestFormatter.java Changeset: b3baca585b7f Author: jbachorik Date: 2013-04-23 09:37 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b3baca585b7f 8011081: Improve jhat Summary: Properly escape HTML output Reviewed-by: alanb, mschoene, sundar ! src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/HttpReader.java ! src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLHelp.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/QueryHandler.java ! src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java Changeset: 37f6f4dbfc6d Author: ksrini Date: 2013-05-07 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/37f6f4dbfc6d 8013506: Better Pack200 data handling Reviewed-by: jrose, kizune, mschoene ! src/share/native/com/sun/java/util/jar/pack/zip.cpp Changeset: 139a01719eec Author: jchen Date: 2013-05-09 09:52 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/139a01719eec 8013510: Augment image writing code Reviewed-by: bae, prr ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: f2068f4244a5 Author: bae Date: 2013-05-14 12:51 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f2068f4244a5 8014093: Improve parsing of images Reviewed-by: prr, jgodinez ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/awt_parseImage.h ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: 65d5a6e53d12 Author: alexsch Date: 2013-05-20 14:39 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/65d5a6e53d12 8013744: Better tabling for AWT Reviewed-by: art, malenkov, skoivu ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/sun/swing/SwingLazyValue.java ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 52be85d5149b Author: bae Date: 2013-05-20 15:26 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/52be85d5149b 8014102: Improve image conversion Reviewed-by: mschoene, prr, jgodinez ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: 08b88f831dd1 Author: malenkov Date: 2013-05-20 19:49 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/08b88f831dd1 8012071: Better Building of Beans Reviewed-by: art, skoivu ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/MetaData.java Changeset: 140c474ab8b9 Author: malenkov Date: 2013-05-31 21:25 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/140c474ab8b9 8012277: Improve AWT DataFlavor Reviewed-by: art, skoivu ! src/share/classes/java/awt/datatransfer/DataFlavor.java Changeset: 23fe888b698d Author: weijun Date: 2013-05-08 09:21 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/23fe888b698d 8014341: Better service from Kerberos servers Summary: read incoming data safely and take care of null return value Reviewed-by: valeriep, ahgross ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/internal/NetClient.java Changeset: 532343ec60b7 Author: weijun Date: 2013-06-13 10:21 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/532343ec60b7 8013739: Better LDAP resource management Reviewed-by: ahgross, mchung, xuelei ! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/sun/misc/JavaLangAccess.java Changeset: 6d9ec6877a7f Author: weijun Date: 2013-06-13 10:31 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6d9ec6877a7f 8015731: Subject java.security.auth.subject to improvements Reviewed-by: skoivu, mullan ! src/share/classes/javax/security/auth/Subject.java Changeset: ccca37ca416a Author: jchen Date: 2013-06-13 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ccca37ca416a 8014098: Better profile validation Reviewed-by: bae, mschoene, prr ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c Changeset: 5a14ecd30b4e Author: msheppar Date: 2013-06-14 15:49 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5a14ecd30b4e 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! make/com/sun/jmx/Makefile ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java Changeset: 7addece3f21e Author: jbachorik Date: 2013-06-20 08:51 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7addece3f21e 8014085: Better serialization support in JMX classes Reviewed-by: alanb, dfuchs, skoivu ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/remote/JMXPrincipal.java ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/management/remote/NotificationResult.java ! src/share/classes/javax/management/remote/TargetedNotification.java Changeset: eb29deb3c1db Author: chegar Date: 2013-06-27 10:37 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/eb29deb3c1db Merge Changeset: 0a06ec55aacd Author: bae Date: 2013-07-01 15:17 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0a06ec55aacd 8017287: Better resource disposal Reviewed-by: prr, vadim, skoivu ! src/share/classes/sun/java2d/Disposer.java Changeset: 51204df822d3 Author: erikj Date: 2013-07-03 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/51204df822d3 8012146: Improve tool support Reviewed-by: ksrini, dholmes, alanb, anthony ! makefiles/CompileLaunchers.gmk ! makefiles/Images.gmk ! test/Makefile Changeset: 888fd0ad7e1e Author: ascarpino Date: 2013-07-03 15:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/888fd0ad7e1e 8011071: Better crypto provider handling Reviewed-by: hawtin, valeriep ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/sun/security/ec/ECPrivateKeyImpl.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/pkcs/PKCS8Key.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/provider/DSAPrivateKey.java ! src/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java ! src/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java Changeset: a06b764cc2d0 Author: dsamersoff Date: 2013-07-08 16:15 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a06b764cc2d0 8008589: Better MBean permission validation Summary: Better MBean permission validation Reviewed-by: skoivu, dfuchs, mchung, sjiang ! src/share/classes/javax/management/MBeanTrustPermission.java Changeset: 9c6de162771c Author: smarks Date: 2013-07-11 13:32 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9c6de162771c 8014987: Augment serialization handling Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java Changeset: c40752886882 Author: jfranck Date: 2013-07-15 14:44 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c40752886882 8014349: (cl) Class.getDeclaredClass problematic in some class loader configurations Reviewed-by: mchung, ahgross, darcy ! src/share/classes/java/lang/Class.java ! src/share/native/java/lang/Class.c Changeset: 48548e40187a Author: mchung Date: 2013-07-15 20:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/48548e40187a 8017291: Cast Proxies Aside Reviewed-by: alanb, ahgross ! src/share/classes/java/lang/ClassLoader.java Changeset: 047c99b53994 Author: chegar Date: 2013-07-15 18:17 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/047c99b53994 Merge ! src/share/classes/java/lang/Thread.java - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/swing/SwingUtilities2.java - test/java/util/Comparators/BasicTest.java Changeset: 3062c96e79e0 Author: chegar Date: 2013-07-16 12:23 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3062c96e79e0 Merge Changeset: e1497f102a8a Author: malenkov Date: 2013-07-16 21:11 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e1497f102a8a 8019617: Better view of objects Reviewed-by: art, skoivu ! src/share/classes/javax/swing/text/html/ObjectView.java Changeset: 69a2dc92fefe Author: michaelm Date: 2013-07-18 18:52 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/69a2dc92fefe 8015743: Address internet addresses Reviewed-by: alanb, khazra, skoivu ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/native/java/net/Inet6Address.c ! src/share/native/java/net/net_util.c ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/net_util_md.c ! test/java/net/Inet6Address/serialize/Serialize.java Changeset: 5d8f1e697cd8 Author: okutsu Date: 2013-07-19 12:14 +0900 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5d8f1e697cd8 8001029: Add new date/time capability Reviewed-by: mchung, hawtin ! src/share/classes/java/util/TimeZone.java + test/java/util/TimeZone/SetDefaultSecurityTest.java Changeset: fe90bd20865b Author: sjiang Date: 2013-07-19 13:35 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/fe90bd20865b 8014534: Better profiling support Summary: Validation of parameters Reviewed-by: sspitsyn, skoivu, mchung ! src/share/classes/com/sun/demo/jvmti/hprof/Tracker.java ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_event.c Changeset: 0a51ccf778b3 Author: chegar Date: 2013-07-22 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0a51ccf778b3 Merge Changeset: 3725e8a70ae9 Author: mchung Date: 2013-07-22 19:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3725e8a70ae9 8017196: Ensure Proxies are handled appropriately Reviewed-by: dfuchs, jrose, jdn, ahgross, chegar ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: 5bde952bf23c Author: sgabdura Date: 2013-07-23 09:30 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5bde952bf23c 8016357: Update hotspot diagnostic class Summary: Add security check to HotSpotDiagnostic.dumpHeap Reviewed-by: fparain, sla, ahgross ! make/java/management/mapfile-vers ! makefiles/mapfiles/libmanagement/mapfile-vers ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/native/sun/management/HotSpotDiagnostic.c Changeset: 5bdc55e87cae Author: weijun Date: 2013-07-17 18:46 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5bdc55e87cae 8020696: Merge problem for KdcComm.java Reviewed-by: chegar ! src/share/classes/sun/security/krb5/KdcComm.java Changeset: 490c67c5d9a2 Author: jchen Date: 2013-07-24 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/490c67c5d9a2 8020293: JVM crash Reviewed-by: prr, jgodinez ! src/share/classes/sun/font/GlyphLayout.java ! src/share/native/sun/font/layout/SunLayoutEngine.cpp Changeset: bcce47d9d8da Author: jbachorik Date: 2013-07-19 16:29 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bcce47d9d8da 8019584: javax/management/remote/mandatory/loading/MissingClassTest.java failed in nightly against jdk7u45: java.io.InvalidObjectException: Invalid notification: null Reviewed-by: mchung, sjiang, dfuchs, ahgross ! src/share/classes/javax/management/remote/NotificationResult.java ! src/share/classes/javax/management/remote/TargetedNotification.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java Changeset: d7a0bbf526f8 Author: jbachorik Date: 2013-07-29 04:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d7a0bbf526f8 8021577: JCK test api/javax_management/jmx_serial/modelmbean/ModelMBeanNotificationInfo/serial/index.html#Input has failed since jdk 7u45 b01 Reviewed-by: alanb, dfuchs, ahgross ! src/share/classes/javax/management/MBeanNotificationInfo.java Changeset: 1a1e42c8e988 Author: chegar Date: 2013-07-25 19:03 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1a1e42c8e988 Merge ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java - src/share/classes/java/util/stream/StreamBuilder.java ! src/share/classes/javax/security/auth/Subject.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/security/pkcs11/P11Key.java - test/java/util/Collections/EmptySortedSet.java Changeset: 446bc20447a1 Author: chegar Date: 2013-07-29 14:58 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/446bc20447a1 Merge Changeset: e537b7f5f39b Author: naoto Date: 2013-08-01 14:09 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e537b7f5f39b 8021286: Improve MacOS resourcing Reviewed-by: okutsu - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk ! make/sun/awt/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m Changeset: 44a063555ccd Author: chegar Date: 2013-08-02 11:11 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/44a063555ccd Merge Changeset: 17e1675e3d1e Author: serb Date: 2013-08-04 02:50 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/17e1675e3d1e 8021282: Better recycling of object instances Reviewed-by: art ! src/macosx/classes/com/apple/laf/AquaUtils.java Changeset: ba7566de89c6 Author: sjiang Date: 2013-08-06 10:33 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ba7566de89c6 8019292: Better Attribute Value Exceptions Reviewed-by: dfuchs, dholmes, ahgross ! src/share/classes/javax/management/BadAttributeValueExpException.java Changeset: 23476862c55b Author: malenkov Date: 2013-08-07 14:37 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/23476862c55b 8021969: The index_AccessAllowed jnlp can not load successfully with exception thrown in the log. Reviewed-by: art, skoivu ! src/share/classes/java/awt/datatransfer/DataFlavor.java Changeset: db9539b0061d Author: jbachorik Date: 2013-08-08 19:16 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/db9539b0061d 8021360: object not exported" on start of JMXConnectorServer for RMI-IIOP protocol with security manager Reviewed-by: alanb, ahgross, smarks, coffeys ! src/share/classes/com/sun/jmx/remote/protocol/iiop/IIOPProxyImpl.java Changeset: 077d8c2cc5f6 Author: chegar Date: 2013-08-09 14:43 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/077d8c2cc5f6 Merge ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java - src/share/classes/java/net/package.html ! src/share/classes/java/util/TimeZone.java ! src/share/native/java/net/net_util.c ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! test/Makefile Changeset: e82ddcc1b2fb Author: serb Date: 2013-08-12 19:57 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e82ddcc1b2fb 8021275: Better screening for ScreenMenu Reviewed-by: art ! src/macosx/classes/com/apple/laf/ScreenMenu.java Changeset: 3e3cbd93f4f1 Author: twisti Date: 2013-08-12 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3e3cbd93f4f1 8022066: Evaluation of method reference to signature polymorphic method crashes VM Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/MethodHandleConstants.java Changeset: e173b8786362 Author: ksrini Date: 2013-08-14 10:17 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e173b8786362 8021355: REGRESSION: Five closed/java/awt/SplashScreen tests fail since 7u45 b01 on Linux, Solaris Reviewed-by: dholmes, anthony, ahgross, erikj ! src/solaris/bin/java_md_solinux.c Changeset: 31010ca3da3e Author: chegar Date: 2013-08-15 21:44 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/31010ca3da3e Merge ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh Changeset: 3f85c96eafcc Author: weijun Date: 2013-08-14 15:25 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3f85c96eafcc 8022931: Enhance Kerberos exceptions Reviewed-by: xuelei, ahgross ! src/share/classes/javax/security/auth/kerberos/KeyTab.java Changeset: 50bdb9577b27 Author: erikj Date: 2013-08-19 12:30 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/50bdb9577b27 8022719: tools/launcher/RunpathTest.java fails after 8012146 Reviewed-by: chegar ! test/tools/launcher/RunpathTest.java Changeset: 0f279113c95a Author: erikj Date: 2013-08-19 14:48 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0f279113c95a 8023231: Remove comma from jtreg bug line Reviewed-by: alanb, chegar ! test/tools/launcher/RunpathTest.java Changeset: ad35b4b6ce8e Author: chegar Date: 2013-08-23 12:32 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ad35b4b6ce8e Merge Changeset: 29f73bc50bd4 Author: chegar Date: 2013-08-30 09:37 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/29f73bc50bd4 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java ! src/share/classes/java/net/InetAddress.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java ! src/solaris/native/java/net/NetworkInterface.c - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: a8593bc7c29d Author: chegar Date: 2013-09-06 09:41 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a8593bc7c29d Merge ! src/share/classes/java/lang/Class.java - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: 22ea25e71b4c Author: chegar Date: 2013-09-14 19:21 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/22ea25e71b4c Merge Changeset: 240072825ada Author: chegar Date: 2013-10-03 19:06 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/240072825ada Merge ! make/sun/awt/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/Images.gmk - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandles.java - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/font/layout/SunLayoutEngine.cpp ! src/solaris/bin/java_md_solinux.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/util/Collection/ListDefaults.java - test/java/util/Map/CheckRandomHashSeed.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/java/util/concurrent/ConcurrentHashMap/toArray.java - test/java/util/regex/PatternTest.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh ! test/tools/launcher/RunpathTest.java Changeset: adbf6d61c820 Author: chegar Date: 2013-10-07 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/adbf6d61c820 8025991: tools/launcher/RunpathTest.java fails Reviewed-by: erikj ! test/tools/launcher/RunpathTest.java Changeset: 99832c718cb8 Author: chegar Date: 2013-10-15 09:27 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/99832c718cb8 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 3dbfab65c17e Author: chegar Date: 2013-10-15 13:54 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3dbfab65c17e Merge ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/lang/ClassLoader.java - src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 27ac58b9a62a Author: chegar Date: 2013-10-15 20:46 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/27ac58b9a62a 8026513: ProblemList.txt Updates (10/2013) Reviewed-by: alanb ! test/ProblemList.txt Changeset: 78ffa90c77b2 Author: chegar Date: 2013-10-15 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/78ffa90c77b2 Merge Changeset: 3676f04e6553 Author: bpb Date: 2013-10-15 16:45 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3676f04e6553 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown Summary: Modify UHE exception message for EAI_AGAIN failures. Reviewed-by: alanb, chegar, michaelm, dsamersoff Contributed-by: Brian Burkhalter ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c Changeset: e33aea66caa3 Author: dholmes Date: 2013-10-15 20:54 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e33aea66caa3 8026378: TEST_BUG: Clean up TEST.groups Reviewed-by: mduigou, mchung, alanb ! test/TEST.groups Changeset: a70aab9b373e Author: weijun Date: 2013-10-16 14:39 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a70aab9b373e 8025124: InitialToken.useNullKey incorrectly applies NULL_KEY in some cases Reviewed-by: xuelei ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/krb5/KrbCred.java Changeset: 9ea6a464c147 Author: igerasim Date: 2013-10-15 21:15 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9ea6a464c147 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed Summary: Properly close PipedStreams. Additional testing for malformed input Reviewed-by: darcy, sherman ! test/java/util/zip/GZIP/GZIPInZip.java Changeset: 76a7c0bc74fd Author: erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/76a7c0bc74fd 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! makefiles/GendataBreakIterator.gmk ! makefiles/GenerateClasses.gmk ! makefiles/Setup.gmk ! src/share/classes/sun/tools/tree/Node.java Changeset: e078fd8a78f6 Author: erikj Date: 2013-10-16 15:53 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e078fd8a78f6 Merge Changeset: d8eec0e3a023 Author: robm Date: 2013-10-16 15:06 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d8eec0e3a023 8026245: InetAddress.getLocalHost crash if IPv6 disabled (macosx) Reviewed-by: chegar, alanb ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! test/java/net/InetAddress/GetLocalHostWithSM.java ! test/java/net/Socket/GetLocalAddress.java Changeset: 445667b19e32 Author: dfuchs Date: 2013-10-16 17:19 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/445667b19e32 8011638: Remove deprecated methods in sun.util.logging.PlatformLogger Reviewed-by: psandoz, mchung, alanb, chegar ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/util/logging/PlatformLoggerTest.java Changeset: 2ef43f3a901c Author: dfuchs Date: 2013-10-16 20:47 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2ef43f3a901c 8013839: Enhance Logger API for handling of resource bundles 4814565: (rb) add method to get basename from a ResourceBundle Summary: adds Logger.setResourceBundle(ResourceBundle) and ResourceBundle.getBaseBundleName() Reviewed-by: mchung, naoto ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java + test/java/util/ResourceBundle/getBaseBundleName/resources/ListBundle.java + test/java/util/ResourceBundle/getBaseBundleName/resources/ListBundle_fr.java + test/java/util/ResourceBundle/getBaseBundleName/resources/PropertyBundle.properties + test/java/util/ResourceBundle/getBaseBundleName/resources/PropertyBundle_fr.properties + test/java/util/logging/Logger/logrb/TestLogrbResourceBundle.java + test/java/util/logging/Logger/logrb/resources/ListBundle.java + test/java/util/logging/Logger/logrb/resources/ListBundle_fr.java + test/java/util/logging/Logger/logrb/resources/PropertyBundle.properties + test/java/util/logging/Logger/logrb/resources/PropertyBundle_fr.properties + test/java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java + test/java/util/logging/Logger/setResourceBundle/resources/ListBundle.java + test/java/util/logging/Logger/setResourceBundle/resources/ListBundle_fr.java + test/java/util/logging/Logger/setResourceBundle/resources/PropertyBundle.properties + test/java/util/logging/Logger/setResourceBundle/resources/PropertyBundle_fr.properties Changeset: cf9cb3d241a3 Author: mduigou Date: 2013-10-16 13:03 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/cf9cb3d241a3 8025910: rename substream(long) -> skip and remove substream(long,long) Reviewed-by: psandoz, henryjen ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java Changeset: 60e3cdbe8cdf Author: aefimov Date: 2013-10-13 14:19 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/60e3cdbe8cdf 8025255: (tz) Support tzdata2013g Reviewed-by: okutsu, mfang ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/backward ! test/sun/util/calendar/zi/tzdata/etcetera ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/iso3166.tab ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/zone.tab Changeset: e2e3c2c249e2 Author: henryjen Date: 2013-10-16 21:34 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e2e3c2c249e2 8026768: java.util.Map.Entry comparingBy methods missing @since 1.8 Reviewed-by: dholmes ! src/share/classes/java/util/Map.java Changeset: ce266885222d Author: peytoia Date: 2013-10-17 13:57 +0900 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ce266885222d 8025703: Update LSR datafile for BCP 47 Reviewed-by: okutsu ! src/share/classes/sun/util/locale/LocaleEquivalentMaps.java + test/java/util/Locale/Bug8025703.java ! test/java/util/Locale/tools/language-subtag-registry.txt Changeset: a45acc8de0f3 Author: wetmore Date: 2013-10-16 23:32 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a45acc8de0f3 8026762: jdk8-tl builds windows builds failing in corba - javac: no source files Reviewed-by: katleman, dholmes ! makefiles/GenerateClasses.gmk Changeset: 37e3dcb798c3 Author: weijun Date: 2013-10-17 20:56 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/37e3dcb798c3 8026712: TEST_BUG: update sun/security/tools/keytool/autotest.sh with a new location to find of libsoftokn3.so Reviewed-by: vinnie ! test/sun/security/tools/keytool/autotest.sh Changeset: 0a6730b5e192 Author: drchase Date: 2013-10-16 17:55 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0a6730b5e192 8022718: Runtime accessibility checking: protected class, if extended, should be accessible from another package Summary: Modify accessibility check; it was muddled about Java vs JVM protection terminology. Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/reflect/Reflection.java + test/java/lang/invoke/accessProtectedSuper/BogoLoader.java + test/java/lang/invoke/accessProtectedSuper/MethodInvoker.java + test/java/lang/invoke/accessProtectedSuper/Test.java + test/java/lang/invoke/accessProtectedSuper/anotherpkg/MethodSupplierOuter.java Changeset: 36fe6a9bd43e Author: rriggs Date: 2013-10-17 10:37 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/36fe6a9bd43e 8026516: javadoc errors in java.time Summary: Corrected links to TemporalQuery and TemporalField.resolve Reviewed-by: mduigou, darcy, lancea ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/IsoEra.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoEra.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistEra.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java Changeset: 5d866df64ae3 Author: mullan Date: 2013-10-17 10:18 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5d866df64ae3 8026346: test/java/lang/SecurityManager/CheckPackageAccess.java failing Reviewed-by: vinnie ! src/share/lib/security/java.security-macosx ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 04e8b8fc6906 Author: mullan Date: 2013-10-17 10:37 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/04e8b8fc6906 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/java/net/HttpURLPermission.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 85a73ad28c53 Author: mullan Date: 2013-10-17 11:34 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/85a73ad28c53 Merge Changeset: 456a9b199208 Author: rriggs Date: 2013-10-17 13:43 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/456a9b199208 8026183: minor documentation problems in java.lang.invoke 8015808: Typo in MethodHandle javadoc Summary: Fix typos and javadoc markup and extraneous paragraph tags Reviewed-by: lancea ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java Changeset: bc04f561bb78 Author: joehw Date: 2013-10-17 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bc04f561bb78 8015243: SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI Reviewed-by: lancea + test/javax/xml/jaxp/validation/8015243/AnyURITest.java + test/javax/xml/jaxp/validation/8015243/anyURI_b006.xsd Changeset: fa38f8e0accd Author: juh Date: 2013-10-17 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/fa38f8e0accd 8026233: test/sun/security/tools/keytool/StorePasswords.java needs to clean up files Reviewed-by: vinnie ! test/sun/security/tools/keytool/StorePasswords.java Changeset: 64c0ac7cd936 Author: lancea Date: 2013-10-17 15:14 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/64c0ac7cd936 8026812: doclint clean up for java.sql and javax.sql Reviewed-by: mduigou ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Connection.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLException.java ! src/share/classes/java/sql/SQLFeatureNotSupportedException.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/sql/SQLWarning.java ! src/share/classes/java/sql/SQLXML.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/javax/sql/CommonDataSource.java ! src/share/classes/javax/sql/RowSet.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/FilteredRowSet.java ! src/share/classes/javax/sql/rowset/JdbcRowSet.java ! src/share/classes/javax/sql/rowset/JoinRowSet.java ! src/share/classes/javax/sql/rowset/Joinable.java ! src/share/classes/javax/sql/rowset/Predicate.java ! src/share/classes/javax/sql/rowset/WebRowSet.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java ! src/share/classes/javax/sql/rowset/spi/SyncResolver.java Changeset: 3735d81552a7 Author: mchung Date: 2013-10-17 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3735d81552a7 8015912: jdeps support to output in dot file format 8026255: Switch jdeps to follow traditional Java option style Reviewed-by: alanb ! test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java Changeset: c1af85c48819 Author: mduigou Date: 2013-10-17 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c1af85c48819 8004138: ForkJoinTask leaks exceptions Reviewed-by: chegar, mduigou, psandoz, martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/ForkJoinTask.java + test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java Changeset: e76bb2436b04 Author: bpb Date: 2013-10-17 15:05 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e76bb2436b04 8026832: Clean up straggling doclint warnings in java.math Summary: Fix empty paragraph tag warnings. Reviewed-by: lancea ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/RoundingMode.java Changeset: 187d5ccb5b18 Author: lana Date: 2013-10-17 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/187d5ccb5b18 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CreateJars.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk ! makefiles/GenerateClasses.gmk - makefiles/GenerateJavaSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Setup.gmk ! makefiles/Tools.gmk + makefiles/gendata/GendataBreakIterator.gmk ! makefiles/profile-includes.txt - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 Changeset: b73fb7920645 Author: lana Date: 2013-10-17 15:53 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b73fb7920645 Merge - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk - makefiles/GenerateJavaSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 Changeset: c1616a944d1c Author: weijun Date: 2013-10-18 08:57 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c1616a944d1c 7025699: Policy Tool is not accessible by keyboard Reviewed-by: alexp, weijun Contributed-by: Leif Samuelsson ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/tools/policytool/Resources.java ! test/sun/security/tools/policytool/Alias.html ! test/sun/security/tools/policytool/OpenPolicy.html ! test/sun/security/tools/policytool/UpdatePermissions.html Changeset: 01b81253f2d5 Author: dcubed Date: 2013-10-15 08:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/01b81253f2d5 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! make/common/Defs-macosx.gmk ! make/common/Defs.gmk ! make/java/redist/Makefile ! makefiles/Import.gmk ! makefiles/Tools.gmk Changeset: 969e8c6c26cc Author: amurillo Date: 2013-10-19 08:51 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/969e8c6c26cc Merge ! makefiles/Import.gmk ! makefiles/Tools.gmk Changeset: c4ab67d1e0ce Author: amurillo Date: 2013-10-22 13:56 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c4ab67d1e0ce Merge ! makefiles/Tools.gmk Changeset: a5b57fca66da Author: ihse Date: 2013-10-16 20:24 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a5b57fca66da 8025715: Split CompileNativeLibraries.gmk Reviewed-by: erikj ! makefiles/CompileNativeLibraries.gmk + makefiles/lib/Awt2dLibraries.gmk + makefiles/lib/CoreLibraries.gmk + makefiles/lib/NetworkingLibraries.gmk + makefiles/lib/NioLibraries.gmk + makefiles/lib/PlatformLibraries.gmk + makefiles/lib/SecurityLibraries.gmk + makefiles/lib/ServiceabilityLibraries.gmk + makefiles/lib/SoundLibraries.gmk Changeset: 1e99d539088d Author: katleman Date: 2013-10-18 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1e99d539088d Merge Changeset: 7ec4ddc36ad6 Author: erikj Date: 2013-10-17 16:15 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7ec4ddc36ad6 8019540: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. Reviewed-by: dholmes, sla ! makefiles/CopyIntoClasses.gmk Changeset: 11e90e4167d4 Author: erikj Date: 2013-10-21 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/11e90e4167d4 Merge Changeset: 3a6ac3484b05 Author: cl Date: 2013-10-21 23:33 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3a6ac3484b05 8026974: solaris build missing java-rmi.cgi Reviewed-by: ksrini ! makefiles/CompileLaunchers.gmk Changeset: b121e84392fa Author: erikj Date: 2013-10-22 11:59 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b121e84392fa 8026966: Most native libs broken on mac in jdk8/build Reviewed-by: ihse, anthony ! makefiles/lib/PlatformLibraries.gmk Changeset: 9850efaedc50 Author: katleman Date: 2013-10-22 16:14 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9850efaedc50 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk + makefiles/lib/Awt2dLibraries.gmk + makefiles/lib/CoreLibraries.gmk + makefiles/lib/NetworkingLibraries.gmk + makefiles/lib/NioLibraries.gmk + makefiles/lib/PlatformLibraries.gmk + makefiles/lib/SecurityLibraries.gmk + makefiles/lib/ServiceabilityLibraries.gmk + makefiles/lib/SoundLibraries.gmk Changeset: 698937f18761 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/698937f18761 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties ! makefiles/jprt.properties Changeset: 81431a7c17cf Author: tbell Date: 2013-10-22 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/81431a7c17cf Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html - src/share/classes/java/net/HttpURLPermission.java - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: aabaae5de1ee Author: ihse Date: 2013-10-23 13:06 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/aabaae5de1ee 8001922: Improve freetype handling. Reviewed-by: erikj ! makefiles/CopyFiles.gmk ! makefiles/lib/Awt2dLibraries.gmk Changeset: ab0e61a57df7 Author: chegar Date: 2013-10-23 13:43 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ab0e61a57df7 8027059: (sctp) fatal warnings overly restrictive with gcc 4.8.1 Reviewed-by: mduigou, dxu, erikj, ihse ! makefiles/lib/NioLibraries.gmk Changeset: 5b4261b4b72a Author: erikj Date: 2013-10-23 17:57 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5b4261b4b72a 8026888: Licensee build failure due to wrong libs being called Reviewed-by: tbell, ihse, simonis ! makefiles/lib/Awt2dLibraries.gmk Changeset: b88aa723a5fa Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b88aa723a5fa Added tag jdk8-b113 for changeset 5b4261b4b72a ! .hgtags Changeset: 162c57b874d4 Author: lana Date: 2013-10-25 10:39 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/162c57b874d4 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk - makefiles/GenerateJavaSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html ! src/share/classes/java/awt/datatransfer/DataFlavor.java - src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/sun/awt/AppContext.java - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 From oleg.pekhovskiy at oracle.com Sun Oct 27 15:41:49 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Mon, 28 Oct 2013 02:41:49 +0400 Subject: [8] Review request for 8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine Message-ID: <526D96AD.3070606@oracle.com> Hi all, please review the fix http://cr.openjdk.java.net/~bagiras/8027151.1/ for https://bugs.openjdk.java.net/browse/JDK-8027151 This issue appeared after the changes made for JDK-7075105. There were two problems: 1. In drop target code, in SunDropTargetContextPeer.getTransferData() method inputStream was closed in finally scope but was not yet used in client code (indirectly). Just its reference stored for the future in DataTransferer.getInstance().translateStream() call. 2. In drop target code, in DataTransferer.translateStream() there was no String object handler (it was moved from DataTransferer.translateBytesOrStream() only to DataTransferer.translateBytes() method). Thanks, Oleg From petr.pchelko at oracle.com Mon Oct 28 01:26:07 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 28 Oct 2013 12:26:07 +0400 Subject: [8] Review Request: JDK-8027152 Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112 In-Reply-To: <956F1DA8-2703-4EF4-9B22-CFDA339679CF@oracle.com> References: <956F1DA8-2703-4EF4-9B22-CFDA339679CF@oracle.com> Message-ID: Hello, AWT Team. Sorry for this mess with reviews, could you please review yet another version of this fix: The bug: http://bugs.openjdk.java.net/browse/JDK-8027152 Th fix: http://cr.openjdk.java.net/~pchelko/8027152/webrev.02/ The alwaysOnTop property would be applied to the owned windows when they would be initialized. With best regards. Petr. On 25.10.2013, at 13:06, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > http://bugs.openjdk.java.net/browse/JDK-8027152 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/8027152/webrev.01/ > > The problem: > After the fix for JDK-7081594 the setAlwaysOnTop needs the ownedWindowList to propagate the alwaysOnTop property to owned windows. However, after the deserialization we get an NPE. In the fix I've moved the > ownedWindowList serialization and deserialization earlier, before we apply the alwaysOnTop. The test shows that owned windows are serialized and deserialized properly. > > With best regards. Petr. From Sergey.Bylokhov at oracle.com Mon Oct 28 03:19:25 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 28 Oct 2013 14:19:25 +0400 Subject: [8] Review Request: JDK-8027152 Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112 In-Reply-To: References: <956F1DA8-2703-4EF4-9B22-CFDA339679CF@oracle.com> Message-ID: <526E3A2D.6020108@oracle.com> Hi, Petr. As far I understand we never check the ownedWindowList to null, since we initialize it even before the constructor call. The problem exists only in deserialisation code before we init this field. So from my point of view the first version of the fix was better. On 28.10.2013 12:26, Petr Pchelko wrote: > Hello, AWT Team. > > Sorry for this mess with reviews, could you please review yet another version of this fix: > The bug: http://bugs.openjdk.java.net/browse/JDK-8027152 > Th fix: http://cr.openjdk.java.net/~pchelko/8027152/webrev.02/ > > The alwaysOnTop property would be applied to the owned windows when they would be initialized. > > With best regards. Petr. > > On 25.10.2013, at 13:06, Petr Pchelko wrote: > >> Hello, AWT Team. >> >> Please review the fix for the issue: >> http://bugs.openjdk.java.net/browse/JDK-8027152 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/8027152/webrev.01/ >> >> The problem: >> After the fix for JDK-7081594 the setAlwaysOnTop needs the ownedWindowList to propagate the alwaysOnTop property to owned windows. However, after the deserialization we get an NPE. In the fix I've moved the >> ownedWindowList serialization and deserialization earlier, before we apply the alwaysOnTop. The test shows that owned windows are serialized and deserialized properly. >> >> With best regards. Petr. -- Best regards, Sergey. From artem.ananiev at oracle.com Mon Oct 28 03:33:25 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 28 Oct 2013 14:33:25 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <526A6FB7.7000800@oracle.com> References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com> <526A6FB7.7000800@oracle.com> Message-ID: <526E3D75.5070308@oracle.com> Hi, Alexander, a few comments: 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here? 2. I'm not sure that the proposed getScaledImageName() implementation in ScalableToolkitImage works perfectly for URLs like this: http://www.exampmle.com/dir/image In this case it will try to find 2x image here: http://www.example at 2x.com/dir/image which doesn't look correct. 3. RenderingHints spec references Retina or non-Retina displays, which should be removed. Thanks, Artem On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/ > > - Scaled image width and height are transformed according to the > AffineTransform type. > - ToolkitImage subclass is used to hold @2x image instance. > > Thanks, > Alexandr. > > On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/ >> >> The JCK failures has been resolved: >> - Some tests tries to draw an image with Integer.MAX_VALUE width >> or height. Passing large values to image.getScaledImage(width, height, >> hints). >> leads that an Image filter is not able to create necessary >> arrays. The fix uses the original image if width or height are equal >> to Integer.MAX_VALUE. >> - Using Image.SCALE_DEFAULT hint for the getScaledImage(width, >> height, hints) method to get the high resolution image interferes with >> JCK tests that expect that the scaled image by certain >> algorithm is returned. This is fixed by invoking the >> super.getScaledImage(width, height, hints) >> method in ToolkitImage in case if a high resolution image is >> not set. >> >> Thanks, >> Alexandr. >> >> >> >> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8011059 >>> webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 >>> >>> The IMAGE_SCALING rendering hint is added to the RenderingHints class. >>> Enabling the image scaling rendering hint forces the SunGraphics2D >>> to use getScaledInstance(width, height, hints) method >>> from Image class with SCALE_DEFAULT hint. >>> >>> By default the image scaling rendering hint is enabled on HiDPI >>> display and disabled for standard displays. >>> >>> User can override the getScaledInstance(width, height, hints) >>> method and return necessary high resolution image >>> according to the given image width and height. >>> >>> For example: >>> --------------------- >>> final Image highResolutionImage = >>> new BufferedImage(2 * WIDTH, 2 * HEIGHT, >>> BufferedImage.TYPE_INT_RGB); >>> Image image = new BufferedImage(WIDTH, HEIGHT, >>> BufferedImage.TYPE_INT_RGB) { >>> >>> @Override >>> public Image getScaledInstance(int width, int height, int >>> hints) { >>> if ((hints & Image.SCALE_DEFAULT) != 0) { >>> return (width <= WIDTH && height <= HEIGHT) >>> ? this : highResolutionImage; >>> } >>> return super.getScaledInstance(width, height, hints); >>> } >>> }; >>> --------------------- >>> >>> The LWCToolkit and ToolkitImage classes are patched to >>> automatically get provided image at 2x.ext images on MacOSX. >>> >>> There are no significant changes in the Java2D demo to make it look >>> perfect on Retina displays. >>> It needs only to put necessary images with the @2x postfix and they >>> will be automatically drawn. >>> >>> Thanks, >>> Alexandr. >>> >> > From petr.pchelko at oracle.com Mon Oct 28 03:42:34 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 28 Oct 2013 14:42:34 +0400 Subject: [8] Review Request: JDK-8027152 Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112 In-Reply-To: <526E3A2D.6020108@oracle.com> References: <956F1DA8-2703-4EF4-9B22-CFDA339679CF@oracle.com> <526E3A2D.6020108@oracle.com> Message-ID: <3CC6B236-03EC-45CB-971B-F1086B597F05@oracle.com> Hello, Sergey. Thank you for the review, here's the updated version: http://cr.openjdk.java.net/~pchelko/8027152/webrev.03/ With best regards. Petr. On 28.10.2013, at 14:19, Sergey Bylokhov wrote: > Hi, Petr. > As far I understand we never check the ownedWindowList to null, since we initialize it even before the constructor call. The problem exists only in deserialisation code before we init this field. So from my point of view the first version of the fix was better. > > On 28.10.2013 12:26, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Sorry for this mess with reviews, could you please review yet another version of this fix: >> The bug: http://bugs.openjdk.java.net/browse/JDK-8027152 >> Th fix: http://cr.openjdk.java.net/~pchelko/8027152/webrev.02/ >> >> The alwaysOnTop property would be applied to the owned windows when they would be initialized. >> >> With best regards. Petr. >> >> On 25.10.2013, at 13:06, Petr Pchelko wrote: >> >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> http://bugs.openjdk.java.net/browse/JDK-8027152 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/8027152/webrev.01/ >>> >>> The problem: >>> After the fix for JDK-7081594 the setAlwaysOnTop needs the ownedWindowList to propagate the alwaysOnTop property to owned windows. However, after the deserialization we get an NPE. In the fix I've moved the >>> ownedWindowList serialization and deserialization earlier, before we apply the alwaysOnTop. The test shows that owned windows are serialized and deserialized properly. >>> >>> With best regards. Petr. > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Mon Oct 28 03:46:53 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 28 Oct 2013 14:46:53 +0400 Subject: [8] Review Request: JDK-8027152 Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112 In-Reply-To: <3CC6B236-03EC-45CB-971B-F1086B597F05@oracle.com> References: <956F1DA8-2703-4EF4-9B22-CFDA339679CF@oracle.com> <526E3A2D.6020108@oracle.com> <3CC6B236-03EC-45CB-971B-F1086B597F05@oracle.com> Message-ID: <526E409D.7000209@oracle.com> Hi, Petr. The fix looks good. On 28.10.2013 14:42, Petr Pchelko wrote: > Hello, Sergey. > > Thank you for the review, here's the updated version: http://cr.openjdk.java.net/~pchelko/8027152/webrev.03/ > > With best regards. Petr. > > On 28.10.2013, at 14:19, Sergey Bylokhov wrote: > >> Hi, Petr. >> As far I understand we never check the ownedWindowList to null, since we initialize it even before the constructor call. The problem exists only in deserialisation code before we init this field. So from my point of view the first version of the fix was better. >> >> On 28.10.2013 12:26, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Sorry for this mess with reviews, could you please review yet another version of this fix: >>> The bug: http://bugs.openjdk.java.net/browse/JDK-8027152 >>> Th fix: http://cr.openjdk.java.net/~pchelko/8027152/webrev.02/ >>> >>> The alwaysOnTop property would be applied to the owned windows when they would be initialized. >>> >>> With best regards. Petr. >>> >>> On 25.10.2013, at 13:06, Petr Pchelko wrote: >>> >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> http://bugs.openjdk.java.net/browse/JDK-8027152 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/8027152/webrev.01/ >>>> >>>> The problem: >>>> After the fix for JDK-7081594 the setAlwaysOnTop needs the ownedWindowList to propagate the alwaysOnTop property to owned windows. However, after the deserialization we get an NPE. In the fix I've moved the >>>> ownedWindowList serialization and deserialization earlier, before we apply the alwaysOnTop. The test shows that owned windows are serialized and deserialized properly. >>>> >>>> With best regards. Petr. >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From anthony.petrov at oracle.com Mon Oct 28 06:29:58 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 28 Oct 2013 17:29:58 +0400 Subject: [8] Review request for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow In-Reply-To: <9A8388F2-3F39-42BB-84D8-0268625F3858@oracle.com> References: <9A8388F2-3F39-42BB-84D8-0268625F3858@oracle.com> Message-ID: <526E66D6.7060208@oracle.com> Hi Leonid, The fix looks somewhat risky so late in the release. But I talked with Sergey and I see that it resolves a lot of real problems. So I'm sort of OK with it. A few comments: src/macosx/native/sun/awt/AWTWindow.m > 255 self.preFullScreenLevel = [self.nsWindow level]; The alwaysOnTop state may be changed dynamically, and thus the value stored in this property might get stale. Either, we don't need this initializer altogether since we need to store the level only after a window enters the full screen mode and don't care about it after we exit the mode, or we should update it dynamically (in -setPropertiesForStyleBits, I suppose). src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java In this View implementation we explicitly made enter/exitFSM() methods no-ops. What are the LWViews used for, and do they now allow entering the full screen mode after your fix? If yes, I think we should find a way to disable that. -- best regards, Anthony On 10/25/2013 09:33 PM, Leonid Romanov wrote: > Hello, > Please review a fix for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow > The problem here is that NSView's -enterFullScreenMode: withOptions: we currently use for entering exclusive full screen mode does it by creating a NSFullScreenWindow instance and moving the view from its window to that newly created full screen window. Since we do not control NSFullScreenWindow creation, we do not get any focus and other notifications from it. > The fix is to stop using -enterFullScreenMode: withOptions: and just achieve the exclusive full screen mode manually. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8013581 > Webrev: http://cr.openjdk.java.net/~leonidr/8013581/webrev.00/ > > Regards, > Leonid. > From artem.ananiev at oracle.com Mon Oct 28 09:39:35 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 28 Oct 2013 20:39:35 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <526A75FA.6010400@oracle.com> References: <5268122B.9010105@oracle.com> <5269301C.6050205@oracle.com> <526935B8.1020609@oracle.com> <526A75FA.6010400@oracle.com> Message-ID: <526E9347.9050807@oracle.com> Thanks. Artem On 10/25/2013 5:45 PM, Anton V. Tarasov wrote: > Hi Artem, > > On 10/24/13 6:59 PM, Artem Ananiev wrote: >> Hi, Anton, >> >> it looks much better now. Is it possible to create a regression test >> for this change? > > Ok, I did that. Here's the test: > > http://cr.openjdk.java.net/~ant/RT-32570.test/webrev.0 > > It persistently passes with the fix (Window/Mac), and fails without > (Windows). > > I'll push it to jfx8 right after this fix gets into jdk8 and jfx8 is > switched to build since that jdk8 build (if that is possible). > > Thanks, > Anton. > >> >> Thanks, >> >> Artem >> >> On 10/24/2013 6:35 PM, Anton V. Tarasov wrote: >>> Hello, >>> >>> Please look at the new version: >>> >>> http://cr.openjdk.java.net/~ant/RT-32570/webrev.1 >>> >>> It eliminates code dependency b/w awt & swing. >>> >>> Thanks, >>> Anton. >>> >>> On 10/23/13 10:15 PM, Anton V. Tarasov wrote: >>>> Hello, >>>> >>>> Please, review the fix: >>>> >>>> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >>>> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >>>> >>>> This is to support SwingNode. On Windows, in the interop mode, when a >>>> popup (JWindow) is shown it doesn't get WM_PAINT native message. >>>> The message should trigger adding a dirty component to RepaintManager >>>> that will eventually paint it. >>>> Currently, a popup is shown blank. Please, see >>>> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >>>> >>>> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >>>> window owned by JLightweightFrame. >>>> >>>> Thanks, >>>> Anton. >>> > From artem.ananiev at oracle.com Tue Oct 29 04:29:32 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 29 Oct 2013 15:29:32 +0400 Subject: [8] Review Request: JDK-8027152 Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112 In-Reply-To: <3CC6B236-03EC-45CB-971B-F1086B597F05@oracle.com> References: <956F1DA8-2703-4EF4-9B22-CFDA339679CF@oracle.com> <526E3A2D.6020108@oracle.com> <3CC6B236-03EC-45CB-971B-F1086B597F05@oracle.com> Message-ID: <526F9C1C.5060803@oracle.com> Looks fine to me. Thanks, Artem On 10/28/2013 2:42 PM, Petr Pchelko wrote: > Hello, Sergey. > > Thank you for the review, here's the updated version: http://cr.openjdk.java.net/~pchelko/8027152/webrev.03/ > > With best regards. Petr. > > On 28.10.2013, at 14:19, Sergey Bylokhov wrote: > >> Hi, Petr. >> As far I understand we never check the ownedWindowList to null, since we initialize it even before the constructor call. The problem exists only in deserialisation code before we init this field. So from my point of view the first version of the fix was better. >> >> On 28.10.2013 12:26, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Sorry for this mess with reviews, could you please review yet another version of this fix: >>> The bug: http://bugs.openjdk.java.net/browse/JDK-8027152 >>> Th fix: http://cr.openjdk.java.net/~pchelko/8027152/webrev.02/ >>> >>> The alwaysOnTop property would be applied to the owned windows when they would be initialized. >>> >>> With best regards. Petr. >>> >>> On 25.10.2013, at 13:06, Petr Pchelko wrote: >>> >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> http://bugs.openjdk.java.net/browse/JDK-8027152 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/8027152/webrev.01/ >>>> >>>> The problem: >>>> After the fix for JDK-7081594 the setAlwaysOnTop needs the ownedWindowList to propagate the alwaysOnTop property to owned windows. However, after the deserialization we get an NPE. In the fix I've moved the >>>> ownedWindowList serialization and deserialization earlier, before we apply the alwaysOnTop. The test shows that owned windows are serialized and deserialized properly. >>>> >>>> With best regards. Petr. >> >> >> -- >> Best regards, Sergey. >> > From petr.pchelko at oracle.com Tue Oct 29 05:11:02 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 29 Oct 2013 16:11:02 +0400 Subject: [8] Review request for 8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine In-Reply-To: <526D96AD.3070606@oracle.com> References: <526D96AD.3070606@oracle.com> Message-ID: <5D49FC44-7729-4DBE-A2BD-F3D13287BB3A@oracle.com> Hello, Oleg. The fix looks fine to me. Just one comment: > 1. In drop target code, in SunDropTargetContextPeer.getTransferData() method inputStream was closed in finally scope but was not yet used in client code (indirectly). Just its reference stored for the future in DataTransferer.getInstance().translateStream() call. I think we should file a separate bug for 9 to investigate this case in more details. In case the DataFlavor representation class in not an InputStream closing the underling stream would be completely fine and correct. So we should try to separate the cases where the representation class in an InputStream and not InputStream and close the underling stream for the latter case. This would be too risky to do in 8, but we could do it in 9. With best regards. Petr. On 28.10.2013, at 2:41, Oleg Pekhovskiy wrote: > Hi all, > > please review the fix > http://cr.openjdk.java.net/~bagiras/8027151.1/ > for > https://bugs.openjdk.java.net/browse/JDK-8027151 > > This issue appeared after the changes made for JDK-7075105. > There were two problems: > 1. In drop target code, in SunDropTargetContextPeer.getTransferData() method inputStream was closed in finally scope but was not yet used in client code (indirectly). Just its reference stored for the future in DataTransferer.getInstance().translateStream() call. > > 2. In drop target code, in DataTransferer.translateStream() there was no String object handler (it was moved from DataTransferer.translateBytesOrStream() only to DataTransferer.translateBytes() method). > > Thanks, > Oleg From anton.tarasov at oracle.com Tue Oct 29 05:36:12 2013 From: anton.tarasov at oracle.com (anton.tarasov at oracle.com) Date: Tue, 29 Oct 2013 12:36:12 +0000 Subject: hg: jdk8/awt/jdk: 8027157: [SwingNode] needs explicit expose for JWindow Message-ID: <20131029123715.B3ACC627DB@hg.openjdk.java.net> Changeset: 55cab2211ae9 Author: ant Date: 2013-10-29 16:35 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/55cab2211ae9 8027157: [SwingNode] needs explicit expose for JWindow Reviewed-by: art, anthony ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WLightweightFramePeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java From anthony.petrov at oracle.com Tue Oct 29 05:41:45 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 29 Oct 2013 16:41:45 +0400 Subject: [8] Review request for 8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine In-Reply-To: <526D96AD.3070606@oracle.com> References: <526D96AD.3070606@oracle.com> Message-ID: <526FAD09.1000008@oracle.com> Hi Oleg, I'm not an expert in this code so I may ask some silly questions. I'm OK with the change #2. Regarding #1: could you please clarify what code is responsible for closing the stream now, after your fix? Is this documented/enforced anywhere (i.e. a finally{} block or something)? Have you run any regression tests to make sure this change doesn't introduce any memory leaks? Why was this not a problem before that we decided to fix this particular piece now, so late in the release? -- best regards, Anthony On 10/28/2013 02:41 AM, Oleg Pekhovskiy wrote: > Hi all, > > please review the fix > http://cr.openjdk.java.net/~bagiras/8027151.1/ > for > https://bugs.openjdk.java.net/browse/JDK-8027151 > > This issue appeared after the changes made for JDK-7075105. > There were two problems: > 1. In drop target code, in SunDropTargetContextPeer.getTransferData() > method inputStream was closed in finally scope but was not yet used in > client code (indirectly). Just its reference stored for the future in > DataTransferer.getInstance().translateStream() call. > > 2. In drop target code, in DataTransferer.translateStream() there was no > String object handler (it was moved from > DataTransferer.translateBytesOrStream() only to > DataTransferer.translateBytes() method). > > Thanks, > Oleg From Sergey.Bylokhov at oracle.com Tue Oct 29 06:02:22 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 Oct 2013 17:02:22 +0400 Subject: [8] Review request for 8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine In-Reply-To: <526D96AD.3070606@oracle.com> References: <526D96AD.3070606@oracle.com> Message-ID: <526FB1DE.8000505@oracle.com> Hi, Oleg. Can you recheck please that now translateBytes and translateStream are the same in terms of such IFs; On 28.10.2013 2:41, Oleg Pekhovskiy wrote: > Hi all, > > please review the fix > http://cr.openjdk.java.net/~bagiras/8027151.1/ > for > https://bugs.openjdk.java.net/browse/JDK-8027151 > > This issue appeared after the changes made for JDK-7075105. > There were two problems: > 1. In drop target code, in SunDropTargetContextPeer.getTransferData() > method inputStream was closed in finally scope but was not yet used in > client code (indirectly). Just its reference stored for the future in > DataTransferer.getInstance().translateStream() call. > > 2. In drop target code, in DataTransferer.translateStream() there was > no String object handler (it was moved from > DataTransferer.translateBytesOrStream() only to > DataTransferer.translateBytes() method). > > Thanks, > Oleg -- Best regards, Sergey. From sergey.malenkov at oracle.com Tue Oct 29 06:02:40 2013 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Tue, 29 Oct 2013 13:02:40 +0000 Subject: hg: jdk8/awt/jdk: 8022746: List of spelling errors in API doc Message-ID: <20131029130304.58369627DC@hg.openjdk.java.net> Changeset: bedc29a6d074 Author: malenkov Date: 2013-10-29 17:01 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bedc29a6d074 8022746: List of spelling errors in API doc Reviewed-by: alexsch, smarks ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/AquaMenuPainter.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/macosx/classes/com/apple/laf/AquaTreeUI.java ! src/macosx/classes/java/net/DefaultInterface.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/font/CFontManager.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/CTextPipe.m ! src/share/back/commonRef.c ! src/share/back/eventFilter.c ! src/share/back/util.c ! src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java ! src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java ! src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java ! src/share/classes/com/sun/beans/decoder/ByteElementHandler.java ! src/share/classes/com/sun/beans/decoder/CharElementHandler.java ! src/share/classes/com/sun/beans/decoder/ClassElementHandler.java ! src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java ! src/share/classes/com/sun/beans/decoder/ElementHandler.java ! src/share/classes/com/sun/beans/decoder/FalseElementHandler.java ! src/share/classes/com/sun/beans/decoder/FieldElementHandler.java ! src/share/classes/com/sun/beans/decoder/FloatElementHandler.java ! src/share/classes/com/sun/beans/decoder/IntElementHandler.java ! src/share/classes/com/sun/beans/decoder/JavaElementHandler.java ! src/share/classes/com/sun/beans/decoder/LongElementHandler.java ! src/share/classes/com/sun/beans/decoder/MethodElementHandler.java ! src/share/classes/com/sun/beans/decoder/NewElementHandler.java ! src/share/classes/com/sun/beans/decoder/NullElementHandler.java ! src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java ! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java ! src/share/classes/com/sun/beans/decoder/ShortElementHandler.java ! src/share/classes/com/sun/beans/decoder/StringElementHandler.java ! src/share/classes/com/sun/beans/decoder/TrueElementHandler.java ! src/share/classes/com/sun/beans/decoder/VarElementHandler.java ! src/share/classes/com/sun/beans/decoder/VoidElementHandler.java ! src/share/classes/com/sun/crypto/provider/PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/PBES1Core.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java ! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormat.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextFieldUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextUI.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/jdi/connect/ListeningConnector.java ! src/share/classes/com/sun/jdi/connect/spi/TransportService.java ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/TokenMgrError.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgentMBean.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.java ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/Filter.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapName.java ! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java ! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java ! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java ! src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/HttpExchange.java ! src/share/classes/com/sun/net/ssl/internal/ssl/Provider.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/WebRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/com/sun/rowset/package.html ! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/hat/resources/hat.js ! src/share/classes/com/sun/tools/jdi/SocketAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/SocketListeningConnector.java ! src/share/classes/com/sun/tools/jdi/ThreadListener.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/java/awt/AWTEventMulticaster.java ! src/share/classes/java/awt/AlphaComposite.java ! src/share/classes/java/awt/BasicStroke.java ! src/share/classes/java/awt/BorderLayout.java ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Event.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/Graphics.java ! src/share/classes/java/awt/Graphics2D.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/MediaTracker.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/MultipleGradientPaintContext.java ! src/share/classes/java/awt/Polygon.java ! src/share/classes/java/awt/PopupMenu.java ! src/share/classes/java/awt/RenderingHints.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/java/awt/Shape.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/datatransfer/FlavorMap.java ! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java ! src/share/classes/java/awt/dnd/DragGestureListener.java ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSourceContext.java ! src/share/classes/java/awt/dnd/DragSourceEvent.java ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/java/awt/font/FontRenderContext.java ! src/share/classes/java/awt/font/GlyphMetrics.java ! src/share/classes/java/awt/font/GlyphVector.java ! src/share/classes/java/awt/font/OpenType.java ! src/share/classes/java/awt/font/TextLayout.java ! src/share/classes/java/awt/font/TransformAttribute.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/awt/geom/Path2D.java ! src/share/classes/java/awt/geom/QuadCurve2D.java ! src/share/classes/java/awt/im/InputMethodRequests.java ! src/share/classes/java/awt/image/BandedSampleModel.java ! src/share/classes/java/awt/image/BufferStrategy.java ! src/share/classes/java/awt/image/BufferedImage.java ! src/share/classes/java/awt/image/ComponentColorModel.java ! src/share/classes/java/awt/image/ComponentSampleModel.java ! src/share/classes/java/awt/image/ImageConsumer.java ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/PixelInterleavedSampleModel.java ! src/share/classes/java/awt/image/renderable/RenderableImage.java ! src/share/classes/java/awt/image/renderable/RenderableImageOp.java ! src/share/classes/java/beans/AppletInitializer.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/java/beans/PropertyEditorSupport.java ! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java ! src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java ! src/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/share/classes/java/beans/beancontext/BeanContextSupport.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/ObjectStreamConstants.java ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/management/CompilationMXBean.java ! src/share/classes/java/lang/management/MemoryPoolMXBean.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/ThreadMXBean.java ! src/share/classes/java/net/Authenticator.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/CookieStore.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/InetSocketAddress.java ! src/share/classes/java/net/InterfaceAddress.java ! src/share/classes/java/net/JarURLConnection.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/StandardSocketOptions.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/net/URLDecoder.java ! src/share/classes/java/net/URLEncoder.java ! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/MembershipKey.java ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/security/AccessControlException.java ! src/share/classes/java/security/DigestOutputStream.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/cert/CertificateRevokedException.java ! src/share/classes/java/security/spec/ECFieldF2m.java ! src/share/classes/java/sql/Array.java ! src/share/classes/java/sql/BatchUpdateException.java ! src/share/classes/java/sql/Blob.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Clob.java ! src/share/classes/java/sql/Connection.java ! src/share/classes/java/sql/DataTruncation.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/DriverPropertyInfo.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLException.java ! src/share/classes/java/sql/SQLFeatureNotSupportedException.java ! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java ! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java ! src/share/classes/java/sql/SQLNonTransientConnectionException.java ! src/share/classes/java/sql/SQLNonTransientException.java ! src/share/classes/java/sql/SQLRecoverableException.java ! src/share/classes/java/sql/SQLSyntaxErrorException.java ! src/share/classes/java/sql/SQLTimeoutException.java ! src/share/classes/java/sql/SQLTransactionRollbackException.java ! src/share/classes/java/sql/SQLTransientConnectionException.java ! src/share/classes/java/sql/SQLTransientException.java ! src/share/classes/java/sql/SQLWarning.java ! src/share/classes/java/sql/SQLXML.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/sql/Struct.java ! src/share/classes/java/sql/package.html ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/text/ChoiceFormat.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/text/FieldPosition.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/RuleBasedCollator.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/zone/ZoneRules.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/MissingFormatWidthException.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ExecutorCompletionService.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/javax/accessibility/AccessibleContext.java ! src/share/classes/javax/accessibility/AccessibleText.java ! src/share/classes/javax/crypto/NullCipher.java ! src/share/classes/javax/crypto/NullCipherSpi.java ! src/share/classes/javax/imageio/IIOParam.java ! src/share/classes/javax/imageio/ImageIO.java ! src/share/classes/javax/imageio/ImageReader.java ! src/share/classes/javax/imageio/ImageWriteParam.java ! src/share/classes/javax/imageio/ImageWriter.java ! src/share/classes/javax/imageio/event/IIOReadProgressListener.java ! src/share/classes/javax/imageio/event/IIOReadUpdateListener.java ! src/share/classes/javax/imageio/event/IIOReadWarningListener.java ! src/share/classes/javax/imageio/event/IIOWriteWarningListener.java ! src/share/classes/javax/imageio/metadata/IIOMetadata.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormat.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html ! src/share/classes/javax/imageio/spi/ImageReaderSpi.java ! src/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java ! src/share/classes/javax/imageio/stream/ImageInputStream.java ! src/share/classes/javax/management/relation/RelationService.java ! src/share/classes/javax/management/relation/RelationServiceMBean.java ! src/share/classes/javax/management/remote/rmi/package.html ! src/share/classes/javax/naming/Binding.java ! src/share/classes/javax/naming/InsufficientResourcesException.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/javax/net/ssl/SSLPeerUnverifiedException.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/print/CancelablePrintJob.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/DocPrintJob.java ! src/share/classes/javax/print/MultiDoc.java ! src/share/classes/javax/print/PrintService.java ! src/share/classes/javax/print/attribute/standard/MediaTray.java ! src/share/classes/javax/print/attribute/standard/PresentationDirection.java ! src/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReason.java ! src/share/classes/javax/print/package.html ! src/share/classes/javax/script/AbstractScriptEngine.java ! src/share/classes/javax/script/CompiledScript.java ! src/share/classes/javax/script/Invocable.java ! src/share/classes/javax/script/ScriptEngine.java ! src/share/classes/javax/script/ScriptEngineFactory.java ! src/share/classes/javax/security/sasl/RealmChoiceCallback.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslClient.java ! src/share/classes/javax/security/sasl/SaslException.java ! src/share/classes/javax/smartcardio/CardChannel.java ! src/share/classes/javax/smartcardio/CardTerminal.java ! src/share/classes/javax/sound/midi/MidiDevice.java ! src/share/classes/javax/sound/midi/MidiMessage.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/midi/ShortMessage.java ! src/share/classes/javax/sound/midi/Soundbank.java ! src/share/classes/javax/sound/midi/Synthesizer.java ! src/share/classes/javax/sound/sampled/AudioFormat.java ! src/share/classes/javax/sound/sampled/AudioSystem.java ! src/share/classes/javax/sound/sampled/ReverbType.java ! src/share/classes/javax/sql/PooledConnection.java ! src/share/classes/javax/sql/RowSet.java ! src/share/classes/javax/sql/StatementEvent.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/JoinRowSet.java ! src/share/classes/javax/sql/rowset/Joinable.java ! src/share/classes/javax/sql/rowset/Predicate.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncResolver.java ! src/share/classes/javax/sql/rowset/spi/TransactionalWriter.java ! src/share/classes/javax/sql/rowset/spi/XmlReader.java ! src/share/classes/javax/sql/rowset/spi/XmlWriter.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/DefaultRowSorter.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/JFormattedTextField.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/LookAndFeel.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/ScrollPaneConstants.java ! src/share/classes/javax/swing/SpinnerDateModel.java ! src/share/classes/javax/swing/SpinnerModel.java ! src/share/classes/javax/swing/SpinnerNumberModel.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/ToolTipManager.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/border/TitledBorder.java ! src/share/classes/javax/swing/event/DocumentEvent.java ! src/share/classes/javax/swing/event/HyperlinkEvent.java ! src/share/classes/javax/swing/event/TableModelEvent.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/filechooser/FileSystemView.java ! src/share/classes/javax/swing/plaf/ComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicBorders.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html ! src/share/classes/javax/swing/table/DefaultTableColumnModel.java ! src/share/classes/javax/swing/table/JTableHeader.java ! src/share/classes/javax/swing/table/TableColumn.java ! src/share/classes/javax/swing/table/TableColumnModel.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/AbstractWriter.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/BoxView.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/DocumentFilter.java ! src/share/classes/javax/swing/text/ElementIterator.java ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/GapVector.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/ParagraphView.java ! src/share/classes/javax/swing/text/StyleConstants.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/AccessibleHTML.java ! src/share/classes/javax/swing/text/html/BlockView.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/CSSParser.java ! src/share/classes/javax/swing/text/html/FormSubmitEvent.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/FrameSetView.java ! src/share/classes/javax/swing/text/html/HTML.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/HTMLFrameHyperlinkEvent.java ! src/share/classes/javax/swing/text/html/HTMLWriter.java ! src/share/classes/javax/swing/text/html/OptionListModel.java ! src/share/classes/javax/swing/text/html/ParagraphView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/TableView.java ! src/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/share/classes/javax/swing/text/html/parser/DocumentParser.java ! src/share/classes/javax/swing/text/html/parser/Element.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/tree/TreeSelectionModel.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/xml/crypto/KeySelector.java ! src/share/classes/javax/xml/crypto/MarshalException.java ! src/share/classes/javax/xml/crypto/dsig/TransformException.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureException.java ! src/share/classes/jdi-overview.html ! src/share/classes/jdk/internal/org/objectweb/asm/Frame.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java ! src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java ! src/share/classes/jdk/internal/util/xml/XMLStreamException.java ! src/share/classes/jdk/internal/util/xml/impl/Parser.java ! src/share/classes/org/ietf/jgss/GSSContext.java ! src/share/classes/org/ietf/jgss/GSSCredential.java ! src/share/classes/org/ietf/jgss/GSSException.java ! src/share/classes/org/ietf/jgss/GSSManager.java ! src/share/classes/org/ietf/jgss/GSSName.java ! src/share/classes/org/ietf/jgss/package.html ! src/share/classes/sun/applet/AppletSecurity.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/awt/GlobalCursorManager.java ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/font/ExtendedTextSourceLabel.java ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/FontRunIterator.java ! src/share/classes/sun/font/LayoutPathImpl.java ! src/share/classes/sun/font/ScriptRun.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/Type1Font.java ! src/share/classes/sun/java2d/SurfaceDataProxy.java ! src/share/classes/sun/java2d/loops/ProcessPath.java ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/pipe/BufferedMaskFill.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/BufferedTextPipe.java ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java ! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java ! src/share/classes/sun/management/counter/perf/InstrumentationException.java ! src/share/classes/sun/management/counter/perf/PerfDataType.java ! src/share/classes/sun/misc/CRC16.java ! src/share/classes/sun/misc/CharacterDecoder.java ! src/share/classes/sun/misc/PerformanceLogger.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/TelnetOutputStream.java ! src/share/classes/sun/net/ftp/FtpClient.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/idn/StringPrep.java ! src/share/classes/sun/net/smtp/SmtpProtocolException.java ! src/share/classes/sun/net/www/http/ChunkedInputStream.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/http/PosterOutputStream.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/print/PSPathGraphics.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/print/PathGraphics.java ! src/share/classes/sun/print/PrintJob2D.java ! src/share/classes/sun/print/RasterPrinterJob.java ! src/share/classes/sun/rmi/rmic/RemoteClass.java ! src/share/classes/sun/rmi/rmic/Util.java ! src/share/classes/sun/rmi/rmic/newrmic/jrmp/StubSkeletonWriter.java ! src/share/classes/sun/rmi/runtime/Log.java ! src/share/classes/sun/rmi/server/Activation.java ! src/share/classes/sun/rmi/transport/ObjectTable.java ! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java ! src/share/classes/sun/rmi/transport/tcp/MultiplexOutputStream.java ! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! src/share/classes/sun/security/jca/GetInstance.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/jgss/krb5/MessageToken.java ! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/DesCbcEType.java ! src/share/classes/sun/security/pkcs11/P11DHKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/share/classes/sun/security/provider/DSA.java ! src/share/classes/sun/security/provider/certpath/AdjacencyList.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/RSASignature.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/util/HostnameChecker.java ! src/share/classes/sun/security/x509/AlgIdDSA.java ! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java ! src/share/classes/sun/swing/plaf/synth/Paint9Painter.java ! src/share/classes/sun/text/normalizer/ReplaceableUCharacterIterator.java ! src/share/classes/sun/text/resources/th/CollationData_th.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jconsole/BorderedComponent.java ! src/share/classes/sun/tools/jconsole/inspector/XTextField.java ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/classes/sun/tools/jstat/ColumnFormat.java ! src/share/classes/sun/tools/jstat/resources/jstat_options ! src/share/classes/sun/tools/tree/ExprExpression.java ! src/share/classes/sun/tools/tree/FieldExpression.java ! src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/share/demo/jfc/Font2DTest/FontPanel.java ! src/share/demo/jfc/TableExample/TableExample4.java ! src/share/demo/jvmti/hprof/debug_malloc.c ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/javavm/export/jvm.h ! src/share/native/com/sun/java/util/jar/pack/zip.cpp ! src/share/native/com/sun/media/sound/PlatformMidi.h ! src/share/native/common/jni_util.h ! src/share/native/java/lang/fdlibm/src/k_rem_pio2.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/sun/awt/image/cvutils/img_dcm.h ! src/share/native/sun/awt/image/cvutils/img_replscale.h ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/image/jpeg/jpegdecoder.c ! src/share/native/sun/awt/libpng/CHANGES ! src/share/native/sun/awt/libpng/png.h ! src/share/native/sun/awt/libpng/pngconf.h ! src/share/native/sun/awt/libpng/pngpriv.h ! src/share/native/sun/awt/libpng/pngrutil.c ! src/share/native/sun/font/layout/ArabicLayoutEngine.h ! src/share/native/sun/font/layout/IndicReordering.h ! src/share/native/sun/font/layout/KhmerReordering.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h ! src/share/native/sun/font/layout/TibetanReordering.cpp ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/share/native/sun/java2d/loops/ProcessPath.c ! src/share/native/sun/java2d/opengl/OGLTextRenderer.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/sample/jmx/jmx-scandir/index.html ! src/share/sample/nio/chatserver/ClientReader.java ! src/share/sample/scripting/scriptpad/src/resources/gui.js ! src/solaris/classes/java/net/DefaultInterface.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XScrollbar.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/font/XMap.java ! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixUriUtils.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_Ports.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_Utils.h ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/multiVis.c ! src/solaris/native/sun/security/smartcardio/MUSCLE/pcsclite.h ! src/windows/classes/com/sun/tools/jdi/SharedMemoryAttachingConnector.java ! src/windows/classes/com/sun/tools/jdi/SharedMemoryListeningConnector.java ! src/windows/classes/java/net/DefaultInterface.java ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/windows/native/java/io/canonicalize_md.c ! src/windows/native/java/net/DualStackPlainSocketImpl.c ! src/windows/native/java/net/icmp.h ! src/windows/native/sun/font/fontpath.c ! src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp ! src/windows/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/native/sun/security/krb5/NativeCreds.c ! src/windows/native/sun/windows/ThemeReader.cpp ! src/windows/native/sun/windows/awt_BitmapUtil.cpp ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Dialog.h ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_Font.h ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp From oleg.pekhovskiy at oracle.com Tue Oct 29 06:37:49 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Tue, 29 Oct 2013 17:37:49 +0400 Subject: [8] Review request for 8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine In-Reply-To: <526FB1DE.8000505@oracle.com> References: <526D96AD.3070606@oracle.com> <526FB1DE.8000505@oracle.com> Message-ID: <526FBA2D.3000500@oracle.com> Hi Sergey, I've got another question: must the number of IFs be equal in these methods? I'm not sure about that. Thanks, Oleg On 29.10.2013 17:02, Sergey Bylokhov wrote: > Hi, Oleg. > Can you recheck please that now translateBytes and translateStream are > the same in terms of such IFs; > > On 28.10.2013 2:41, Oleg Pekhovskiy wrote: >> Hi all, >> >> please review the fix >> http://cr.openjdk.java.net/~bagiras/8027151.1/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8027151 >> >> This issue appeared after the changes made for JDK-7075105. >> There were two problems: >> 1. In drop target code, in SunDropTargetContextPeer.getTransferData() >> method inputStream was closed in finally scope but was not yet used in >> client code (indirectly). Just its reference stored for the future in >> DataTransferer.getInstance().translateStream() call. >> >> 2. In drop target code, in DataTransferer.translateStream() there was >> no String object handler (it was moved from >> DataTransferer.translateBytesOrStream() only to >> DataTransferer.translateBytes() method). >> >> Thanks, >> Oleg > > From oleg.pekhovskiy at oracle.com Tue Oct 29 07:39:57 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Tue, 29 Oct 2013 18:39:57 +0400 Subject: [8] Review request for 8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine In-Reply-To: <526FAD09.1000008@oracle.com> References: <526D96AD.3070606@oracle.com> <526FAD09.1000008@oracle.com> Message-ID: <526FC8BD.4030605@oracle.com> Hi Anthony, I could refer to the fix for JDK-7075105. the finally {} block was added there and had never existed before. Here's the way InputStream passed to DataTransferer.getInstance(). translateStream() gets closed: In out case DataTransferer.translateStream() calls DataTransferer.translateStreamToInputStream() on line 1776 where the stream is passed to ReencodingInputStream constructor. It is then passed to InputStreamReader constructor. Both classes override close() method where ReencodingInputStream closes referenced InputStreamReader and InputStreamReader closes referenced InputStream. ReencodingInputStream is returned by SunDropTargetContextPeer.getTransferData() method, called by DataFlavor.getReaderForText() that returns it to the client code. So it's a client code obligation to call ReencodingInputStream.close(). This is the use case for the test mentioned in the issue description. But in general we should investigate each use case to avoid memory leaks. As Petr pointed out it makes sense to do it for JDK 9, because it could be risky for now. Thanks, Oleg On 29.10.2013 16:41, Anthony Petrov wrote: > Hi Oleg, > > I'm not an expert in this code so I may ask some silly questions. > > I'm OK with the change #2. > > Regarding #1: could you please clarify what code is responsible for > closing the stream now, after your fix? Is this documented/enforced > anywhere (i.e. a finally{} block or something)? Have you run any > regression tests to make sure this change doesn't introduce any memory > leaks? Why was this not a problem before that we decided to fix this > particular piece now, so late in the release? > > -- > best regards, > Anthony > > On 10/28/2013 02:41 AM, Oleg Pekhovskiy wrote: >> Hi all, >> >> please review the fix >> http://cr.openjdk.java.net/~bagiras/8027151.1/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8027151 >> >> This issue appeared after the changes made for JDK-7075105. >> There were two problems: >> 1. In drop target code, in SunDropTargetContextPeer.getTransferData() >> method inputStream was closed in finally scope but was not yet used in >> client code (indirectly). Just its reference stored for the future in >> DataTransferer.getInstance().translateStream() call. >> >> 2. In drop target code, in DataTransferer.translateStream() there was no >> String object handler (it was moved from >> DataTransferer.translateBytesOrStream() only to >> DataTransferer.translateBytes() method). >> >> Thanks, >> Oleg From petr.pchelko at oracle.com Tue Oct 29 07:45:25 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 29 Oct 2013 18:45:25 +0400 Subject: [8] Review request for 8027442: JDK compilation fails on MacOS In-Reply-To: <526FC305.4070408@oracle.com> References: <526FC260.5020505@oracle.com> <526FC305.4070408@oracle.com> Message-ID: <717B81ED-C2E3-4BA8-9A01-6B157B871D96@oracle.com> Hello, Sergey. The fix looks good to me. With best regards. Petr. On 29.10.2013, at 18:15, Alexander Scherbatiy wrote: > > The fix looks good for me. > > Thanks, > Alexandr. > > On 10/29/2013 6:12 PM, sergey malenkov wrote: >> Hello, >> >> Could you please review the following fix: >> fix:http://cr.openjdk.java.net/~malenkov/8027442.8.0/ >> bug:https://bugs.openjdk.java.net/browse/JDK-8027442 >> >> Seems a techwriter's tool adds non-breaking space sometimes. >> This fix replaces 0xA0 with 0x20. >> >> Thanks, >> SAM >> > From sergey.malenkov at oracle.com Tue Oct 29 08:02:45 2013 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Tue, 29 Oct 2013 15:02:45 +0000 Subject: hg: jdk8/awt/jdk: 8027442: JDK compilation fails on MacOS Message-ID: <20131029150435.53601627EB@hg.openjdk.java.net> Changeset: d4eb25382baf Author: malenkov Date: 2013-10-29 19:01 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d4eb25382baf 8027442: JDK compilation fails on MacOS Reviewed-by: alexsch, pchelko ! src/share/classes/java/awt/Component.java From alexandr.scherbatiy at oracle.com Tue Oct 29 09:45:48 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 29 Oct 2013 20:45:48 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <526E3D75.5070308@oracle.com> References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com> <526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com> Message-ID: <526FE63C.1020408@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8011059/webrev.03 On 10/28/2013 2:33 PM, Artem Ananiev wrote: > Hi, Alexander, > > a few comments: > > 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here? The isHiDPIImage() method is used to check that the drawHiDPIImage should be called like: if (isHiDPIImage(img)) { return drawHiDPIImage(...); } > 2. I'm not sure that the proposed getScaledImageName() implementation > in ScalableToolkitImage works perfectly for URLs like this: > > http://www.exampmle.com/dir/image > > In this case it will try to find 2x image here: > > http://www.example at 2x.com/dir/image > > which doesn't look correct. Fixed. Only path part of a URL is converted to path2x. > 3. RenderingHints spec references Retina or non-Retina displays, which > should be removed. Fixed. - devScale is used instead of transform parsing in the drawHiDPIImage() method just to not have performance regression more than 2 times on HiDPI displays - LWCToolkit.ScalableToolkitImage is made public for the fix 8024926 [macosx] AquaIcon HiDPI support. Thanks, Alexandr. > > Thanks, > > Artem > > On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/ >> >> - Scaled image width and height are transformed according to the >> AffineTransform type. >> - ToolkitImage subclass is used to hold @2x image instance. >> >> Thanks, >> Alexandr. >> >> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/ >>> >>> The JCK failures has been resolved: >>> - Some tests tries to draw an image with Integer.MAX_VALUE width >>> or height. Passing large values to image.getScaledImage(width, height, >>> hints). >>> leads that an Image filter is not able to create necessary >>> arrays. The fix uses the original image if width or height are equal >>> to Integer.MAX_VALUE. >>> - Using Image.SCALE_DEFAULT hint for the getScaledImage(width, >>> height, hints) method to get the high resolution image interferes with >>> JCK tests that expect that the scaled image by certain >>> algorithm is returned. This is fixed by invoking the >>> super.getScaledImage(width, height, hints) >>> method in ToolkitImage in case if a high resolution image is >>> not set. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> >>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011059 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 >>>> >>>> The IMAGE_SCALING rendering hint is added to the RenderingHints >>>> class. >>>> Enabling the image scaling rendering hint forces the SunGraphics2D >>>> to use getScaledInstance(width, height, hints) method >>>> from Image class with SCALE_DEFAULT hint. >>>> >>>> By default the image scaling rendering hint is enabled on HiDPI >>>> display and disabled for standard displays. >>>> >>>> User can override the getScaledInstance(width, height, hints) >>>> method and return necessary high resolution image >>>> according to the given image width and height. >>>> >>>> For example: >>>> --------------------- >>>> final Image highResolutionImage = >>>> new BufferedImage(2 * WIDTH, 2 * HEIGHT, >>>> BufferedImage.TYPE_INT_RGB); >>>> Image image = new BufferedImage(WIDTH, HEIGHT, >>>> BufferedImage.TYPE_INT_RGB) { >>>> >>>> @Override >>>> public Image getScaledInstance(int width, int height, int >>>> hints) { >>>> if ((hints & Image.SCALE_DEFAULT) != 0) { >>>> return (width <= WIDTH && height <= HEIGHT) >>>> ? this : highResolutionImage; >>>> } >>>> return super.getScaledInstance(width, height, hints); >>>> } >>>> }; >>>> --------------------- >>>> >>>> The LWCToolkit and ToolkitImage classes are patched to >>>> automatically get provided image at 2x.ext images on MacOSX. >>>> >>>> There are no significant changes in the Java2D demo to make it look >>>> perfect on Retina displays. >>>> It needs only to put necessary images with the @2x postfix and they >>>> will be automatically drawn. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >> From alexandr.scherbatiy at oracle.com Tue Oct 29 09:47:55 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 29 Oct 2013 20:47:55 +0400 Subject: [8] Review request for 8024926 [macosx] AquaIcon HiDPI support Message-ID: <526FE6BB.3010109@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8024926 webrev: http://cr.openjdk.java.net/~alexsch/8024926/webrev.00 The fix returns a high resolution system icon in the overridden getScaledInstance(width, height, hints) method. The fix relies on the fix for the issue JDK-8011059 [macosx] Make JDK demos look perfect on retina displays: http://mail.openjdk.java.net/pipermail/awt-dev/2013-October/006133.html - getScaledInstance(width, height, hints) method is used for the image drawing when IMAGE_SCALING hints are enabled - LWCToolkit.ScalableToolkitImage class is public Thanks, Alexandr. From anthony.petrov at oracle.com Tue Oct 29 10:00:55 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 29 Oct 2013 21:00:55 +0400 Subject: [8] Review request for 8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine In-Reply-To: <526FC8BD.4030605@oracle.com> References: <526D96AD.3070606@oracle.com> <526FAD09.1000008@oracle.com> <526FC8BD.4030605@oracle.com> Message-ID: <526FE9C7.7080709@oracle.com> Thanks for the details, Oleg. I agree that it's a good idea to investigate the close() issue in JDK 9. I've also noticed that DataFlavor.getReaderForText() doesn't mention that user code is responsible for close()'ing the returned Reader. I suggest to update the specification of this method and mention that (please add a note about the spec change to 8027452 which you've just filed). With this done, the fix looks good to me. -- best regards, Anthony On 10/29/2013 06:39 PM, Oleg Pekhovskiy wrote: > Hi Anthony, > > I could refer to the fix for JDK-7075105. the finally {} block was added > there and had never existed before. > > Here's the way InputStream passed to DataTransferer.getInstance(). > translateStream() gets closed: > > In out case DataTransferer.translateStream() calls > DataTransferer.translateStreamToInputStream() on line 1776 where > the stream is passed to ReencodingInputStream constructor. It is then > passed to InputStreamReader constructor. Both classes override close() > method where ReencodingInputStream closes referenced InputStreamReader and > InputStreamReader closes referenced InputStream. > > ReencodingInputStream is returned by > SunDropTargetContextPeer.getTransferData() method, called by > DataFlavor.getReaderForText() that returns it to the client code. > So it's a client code obligation to call ReencodingInputStream.close(). > > This is the use case for the test mentioned in the issue description. > But in general we should investigate each use case to avoid memory > leaks. As Petr pointed out it makes sense to do it for JDK 9, because it > could be risky for now. > > Thanks, > Oleg > > On 29.10.2013 16:41, Anthony Petrov wrote: >> Hi Oleg, >> >> I'm not an expert in this code so I may ask some silly questions. >> >> I'm OK with the change #2. >> >> Regarding #1: could you please clarify what code is responsible for >> closing the stream now, after your fix? Is this documented/enforced >> anywhere (i.e. a finally{} block or something)? Have you run any >> regression tests to make sure this change doesn't introduce any memory >> leaks? Why was this not a problem before that we decided to fix this >> particular piece now, so late in the release? >> >> -- >> best regards, >> Anthony >> >> On 10/28/2013 02:41 AM, Oleg Pekhovskiy wrote: >>> Hi all, >>> >>> please review the fix >>> http://cr.openjdk.java.net/~bagiras/8027151.1/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8027151 >>> >>> This issue appeared after the changes made for JDK-7075105. >>> There were two problems: >>> 1. In drop target code, in SunDropTargetContextPeer.getTransferData() >>> method inputStream was closed in finally scope but was not yet used in >>> client code (indirectly). Just its reference stored for the future in >>> DataTransferer.getInstance().translateStream() call. >>> >>> 2. In drop target code, in DataTransferer.translateStream() there was no >>> String object handler (it was moved from >>> DataTransferer.translateBytesOrStream() only to >>> DataTransferer.translateBytes() method). >>> >>> Thanks, >>> Oleg From oleg.pekhovskiy at oracle.com Tue Oct 29 10:38:51 2013 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Tue, 29 Oct 2013 21:38:51 +0400 Subject: [8] Review request for 8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine In-Reply-To: <526FE9C7.7080709@oracle.com> References: <526D96AD.3070606@oracle.com> <526FAD09.1000008@oracle.com> <526FC8BD.4030605@oracle.com> <526FE9C7.7080709@oracle.com> Message-ID: <526FF2AB.6010307@oracle.com> Thank you for the review, Anthony, I created new issue: https://bugs.openjdk.java.net/browse/JDK-8027469 and linked it together with 8027452. Thanks, Oleg On 29.10.2013 21:00, Anthony Petrov wrote: > Thanks for the details, Oleg. I agree that it's a good idea to > investigate the close() issue in JDK 9. > > I've also noticed that DataFlavor.getReaderForText() doesn't mention > that user code is responsible for close()'ing the returned Reader. I > suggest to update the specification of this method and mention that > (please add a note about the spec change to 8027452 which you've just > filed). > > With this done, the fix looks good to me. > > -- > best regards, > Anthony > > On 10/29/2013 06:39 PM, Oleg Pekhovskiy wrote: >> Hi Anthony, >> >> I could refer to the fix for JDK-7075105. the finally {} block was added >> there and had never existed before. >> >> Here's the way InputStream passed to DataTransferer.getInstance(). >> translateStream() gets closed: >> >> In out case DataTransferer.translateStream() calls >> DataTransferer.translateStreamToInputStream() on line 1776 where >> the stream is passed to ReencodingInputStream constructor. It is then >> passed to InputStreamReader constructor. Both classes override close() >> method where ReencodingInputStream closes referenced InputStreamReader >> and >> InputStreamReader closes referenced InputStream. >> >> ReencodingInputStream is returned by >> SunDropTargetContextPeer.getTransferData() method, called by >> DataFlavor.getReaderForText() that returns it to the client code. >> So it's a client code obligation to call ReencodingInputStream.close(). >> >> This is the use case for the test mentioned in the issue description. >> But in general we should investigate each use case to avoid memory >> leaks. As Petr pointed out it makes sense to do it for JDK 9, because it >> could be risky for now. >> >> Thanks, >> Oleg >> >> On 29.10.2013 16:41, Anthony Petrov wrote: >>> Hi Oleg, >>> >>> I'm not an expert in this code so I may ask some silly questions. >>> >>> I'm OK with the change #2. >>> >>> Regarding #1: could you please clarify what code is responsible for >>> closing the stream now, after your fix? Is this documented/enforced >>> anywhere (i.e. a finally{} block or something)? Have you run any >>> regression tests to make sure this change doesn't introduce any memory >>> leaks? Why was this not a problem before that we decided to fix this >>> particular piece now, so late in the release? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/28/2013 02:41 AM, Oleg Pekhovskiy wrote: >>>> Hi all, >>>> >>>> please review the fix >>>> http://cr.openjdk.java.net/~bagiras/8027151.1/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8027151 >>>> >>>> This issue appeared after the changes made for JDK-7075105. >>>> There were two problems: >>>> 1. In drop target code, in SunDropTargetContextPeer.getTransferData() >>>> method inputStream was closed in finally scope but was not yet used in >>>> client code (indirectly). Just its reference stored for the future in >>>> DataTransferer.getInstance().translateStream() call. >>>> >>>> 2. In drop target code, in DataTransferer.translateStream() there >>>> was no >>>> String object handler (it was moved from >>>> DataTransferer.translateBytesOrStream() only to >>>> DataTransferer.translateBytes() method). >>>> >>>> Thanks, >>>> Oleg From oleg.pekhovskiy at oracle.com Tue Oct 29 10:47:13 2013 From: oleg.pekhovskiy at oracle.com (oleg.pekhovskiy at oracle.com) Date: Tue, 29 Oct 2013 17:47:13 +0000 Subject: hg: jdk8/awt/jdk: 8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine Message-ID: <20131029174834.3ACA6627F8@hg.openjdk.java.net> Changeset: a2b42e558211 Author: bagiras Date: 2013-10-29 21:46 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a2b42e558211 8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine Reviewed-by: anthony, pchelko ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java From Sergey.Bylokhov at oracle.com Tue Oct 29 12:08:30 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 Oct 2013 23:08:30 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <526FE63C.1020408@oracle.com> References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com> <526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com> <526FE63C.1020408@oracle.com> Message-ID: <527007AE.6000401@oracle.com> Hi, Alexander. The fix looks fine to me in general. But there is at least one issue. I build you fix and test it: - Consuming of cpu increased by 500 times Java2Demo on images tab. - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. Note that jdk6 has the same FPS(15) on my system. On 29.10.2013 20:45, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8011059/webrev.03 > > On 10/28/2013 2:33 PM, Artem Ananiev wrote: >> Hi, Alexander, >> >> a few comments: >> >> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here? > The isHiDPIImage() method is used to check that the > drawHiDPIImage should be called like: > if (isHiDPIImage(img)) { > return drawHiDPIImage(...); > } > >> 2. I'm not sure that the proposed getScaledImageName() implementation >> in ScalableToolkitImage works perfectly for URLs like this: >> >> http://www.exampmle.com/dir/image >> >> In this case it will try to find 2x image here: >> >> http://www.example at 2x.com/dir/image >> >> which doesn't look correct. > Fixed. Only path part of a URL is converted to path2x. > >> 3. RenderingHints spec references Retina or non-Retina displays, >> which should be removed. > Fixed. > > - devScale is used instead of transform parsing in the > drawHiDPIImage() method just to not have performance regression more > than 2 times on HiDPI displays > - LWCToolkit.ScalableToolkitImage is made public for the fix > 8024926 [macosx] AquaIcon HiDPI support. > > Thanks, > Alexandr. > >> >> Thanks, >> >> Artem >> >> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/ >>> >>> - Scaled image width and height are transformed according to the >>> AffineTransform type. >>> - ToolkitImage subclass is used to hold @2x image instance. >>> >>> Thanks, >>> Alexandr. >>> >>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/ >>>> >>>> The JCK failures has been resolved: >>>> - Some tests tries to draw an image with Integer.MAX_VALUE width >>>> or height. Passing large values to image.getScaledImage(width, height, >>>> hints). >>>> leads that an Image filter is not able to create necessary >>>> arrays. The fix uses the original image if width or height are equal >>>> to Integer.MAX_VALUE. >>>> - Using Image.SCALE_DEFAULT hint for the getScaledImage(width, >>>> height, hints) method to get the high resolution image interferes with >>>> JCK tests that expect that the scaled image by certain >>>> algorithm is returned. This is fixed by invoking the >>>> super.getScaledImage(width, height, hints) >>>> method in ToolkitImage in case if a high resolution image is >>>> not set. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> >>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011059 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 >>>>> >>>>> The IMAGE_SCALING rendering hint is added to the RenderingHints >>>>> class. >>>>> Enabling the image scaling rendering hint forces the SunGraphics2D >>>>> to use getScaledInstance(width, height, hints) method >>>>> from Image class with SCALE_DEFAULT hint. >>>>> >>>>> By default the image scaling rendering hint is enabled on HiDPI >>>>> display and disabled for standard displays. >>>>> >>>>> User can override the getScaledInstance(width, height, hints) >>>>> method and return necessary high resolution image >>>>> according to the given image width and height. >>>>> >>>>> For example: >>>>> --------------------- >>>>> final Image highResolutionImage = >>>>> new BufferedImage(2 * WIDTH, 2 * HEIGHT, >>>>> BufferedImage.TYPE_INT_RGB); >>>>> Image image = new BufferedImage(WIDTH, HEIGHT, >>>>> BufferedImage.TYPE_INT_RGB) { >>>>> >>>>> @Override >>>>> public Image getScaledInstance(int width, int height, int >>>>> hints) { >>>>> if ((hints & Image.SCALE_DEFAULT) != 0) { >>>>> return (width <= WIDTH && height <= HEIGHT) >>>>> ? this : highResolutionImage; >>>>> } >>>>> return super.getScaledInstance(width, height, hints); >>>>> } >>>>> }; >>>>> --------------------- >>>>> >>>>> The LWCToolkit and ToolkitImage classes are patched to >>>>> automatically get provided image at 2x.ext images on MacOSX. >>>>> >>>>> There are no significant changes in the Java2D demo to make it look >>>>> perfect on Retina displays. >>>>> It needs only to put necessary images with the @2x postfix and they >>>>> will be automatically drawn. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>> > -- Best regards, Sergey. From petr.pchelko at oracle.com Wed Oct 30 00:58:48 2013 From: petr.pchelko at oracle.com (petr.pchelko at oracle.com) Date: Wed, 30 Oct 2013 07:58:48 +0000 Subject: hg: jdk8/awt/jdk: 8027152: Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112 Message-ID: <20131030080018.E99E06281A@hg.openjdk.java.net> Changeset: db2838f25a85 Author: pchelko Date: 2013-10-30 12:00 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/db2838f25a85 8027152: Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112 Reviewed-by: art, serb ! src/share/classes/java/awt/Window.java + test/java/awt/Window/OwnedWindowsSerialization/OwnedWindowsSerialization.java From petr.pchelko at oracle.com Wed Oct 30 05:31:20 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Wed, 30 Oct 2013 16:31:20 +0400 Subject: [8] Review Request: JDK-8027561 [macosx] Cleanup "may not respond to selector" warnings in native code Message-ID: Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8027561 The fix is available at: http://cr.openjdk.java.net/~pchelko/8027561/webrev.00/ This is a cleanup. Some native compilation warnings were fixed. With best regards. Petr. From Sergey.Bylokhov at oracle.com Wed Oct 30 05:48:42 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 30 Oct 2013 16:48:42 +0400 Subject: [8] Review Request: JDK-8027561 [macosx] Cleanup "may not respond to selector" warnings in native code In-Reply-To: References: Message-ID: <5271002A.8020904@oracle.com> Hi, Petr. The fix looks good to me. On 30.10.2013 16:31, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8027561 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/8027561/webrev.00/ > > This is a cleanup. Some native compilation warnings were fixed. > > With best regards. Petr. -- Best regards, Sergey. From leonid.romanov at oracle.com Wed Oct 30 09:53:27 2013 From: leonid.romanov at oracle.com (leonid.romanov at oracle.com) Date: Wed, 30 Oct 2013 16:53:27 +0000 Subject: hg: jdk8/awt/jdk: 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow Message-ID: <20131030165525.ECC7862836@hg.openjdk.java.net> Changeset: 05f04b1c5bd0 Author: leonidr Date: 2013-10-30 20:54 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/05f04b1c5bd0 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CWrapper.m + test/java/awt/FullScreen/8013581/bug8013581.java From anthony.petrov at oracle.com Wed Oct 30 10:19:10 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 30 Oct 2013 21:19:10 +0400 Subject: [8] Review Request: JDK-8027561 [macosx] Cleanup "may not respond to selector" warnings in native code In-Reply-To: References: Message-ID: <52713F8E.6040504@oracle.com> Looks fine. -- best regards, Anthony On 10/30/2013 04:31 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8027561 > The fix is available at: > http://cr.openjdk.java.net/~pchelko/8027561/webrev.00/ > > This is a cleanup. Some native compilation warnings were fixed. > > With best regards. Petr. > From alexandr.scherbatiy at oracle.com Thu Oct 31 09:19:14 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 31 Oct 2013 20:19:14 +0400 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <527007AE.6000401@oracle.com> References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com> <526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com> <526FE63C.1020408@oracle.com> <527007AE.6000401@oracle.com> Message-ID: <52728302.406@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/ The reflection is used to skip the Image.getScaledInstance() method call if it is not overridden by a user. On 10/29/2013 11:08 PM, Sergey Bylokhov wrote: > Hi, Alexander. > The fix looks fine to me in general. But there is at least one issue. > I build you fix and test it: > - Consuming of cpu increased by 500 times Java2Demo on images tab. > - FPS is dropped from 220(jdk8)/35(jdk7u40) to 15 in guimark2. Note > that jdk6 has the same FPS(15) on my system. The main problem is that the Image.SCALE_DEFAULT hint is used to retrieve a scaled image from Image.getScaledInstance() method. It always uses the ReplicateScaleFilter for images which getScaledInstance() method has not been overridden. The ReplicateScaleFilter creates a lot of arrays and consumes the CPU during the image parsing. The better fix would be to introduce the new Image.SCALE_CUSTOM hint which could be used to get a scaled image and does not use filters by default. But it should be a separated bug with a new CCC request. Thanks, Alexandr. > > On 29.10.2013 20:45, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8011059/webrev.03 >> >> On 10/28/2013 2:33 PM, Artem Ananiev wrote: >>> Hi, Alexander, >>> >>> a few comments: >>> >>> 1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here? >> The isHiDPIImage() method is used to check that the >> drawHiDPIImage should be called like: >> if (isHiDPIImage(img)) { >> return drawHiDPIImage(...); >> } >> >>> 2. I'm not sure that the proposed getScaledImageName() >>> implementation in ScalableToolkitImage works perfectly for URLs like >>> this: >>> >>> http://www.exampmle.com/dir/image >>> >>> In this case it will try to find 2x image here: >>> >>> http://www.example at 2x.com/dir/image >>> >>> which doesn't look correct. >> Fixed. Only path part of a URL is converted to path2x. >> >>> 3. RenderingHints spec references Retina or non-Retina displays, >>> which should be removed. >> Fixed. >> >> - devScale is used instead of transform parsing in the >> drawHiDPIImage() method just to not have performance regression more >> than 2 times on HiDPI displays >> - LWCToolkit.ScalableToolkitImage is made public for the fix >> 8024926 [macosx] AquaIcon HiDPI support. >> >> Thanks, >> Alexandr. >> >>> >>> Thanks, >>> >>> Artem >>> >>> On 10/25/2013 5:18 PM, Alexander Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.02/ >>>> >>>> - Scaled image width and height are transformed according to the >>>> AffineTransform type. >>>> - ToolkitImage subclass is used to hold @2x image instance. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 10/23/2013 7:24 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8011059/webrev.01/ >>>>> >>>>> The JCK failures has been resolved: >>>>> - Some tests tries to draw an image with Integer.MAX_VALUE width >>>>> or height. Passing large values to image.getScaledImage(width, >>>>> height, >>>>> hints). >>>>> leads that an Image filter is not able to create necessary >>>>> arrays. The fix uses the original image if width or height are equal >>>>> to Integer.MAX_VALUE. >>>>> - Using Image.SCALE_DEFAULT hint for the getScaledImage(width, >>>>> height, hints) method to get the high resolution image interferes >>>>> with >>>>> JCK tests that expect that the scaled image by certain >>>>> algorithm is returned. This is fixed by invoking the >>>>> super.getScaledImage(width, height, hints) >>>>> method in ToolkitImage in case if a high resolution image is >>>>> not set. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>> >>>>> On 10/22/2013 1:31 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011059 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8011059/webrev.00 >>>>>> >>>>>> The IMAGE_SCALING rendering hint is added to the RenderingHints >>>>>> class. >>>>>> Enabling the image scaling rendering hint forces the SunGraphics2D >>>>>> to use getScaledInstance(width, height, hints) method >>>>>> from Image class with SCALE_DEFAULT hint. >>>>>> >>>>>> By default the image scaling rendering hint is enabled on HiDPI >>>>>> display and disabled for standard displays. >>>>>> >>>>>> User can override the getScaledInstance(width, height, hints) >>>>>> method and return necessary high resolution image >>>>>> according to the given image width and height. >>>>>> >>>>>> For example: >>>>>> --------------------- >>>>>> final Image highResolutionImage = >>>>>> new BufferedImage(2 * WIDTH, 2 * HEIGHT, >>>>>> BufferedImage.TYPE_INT_RGB); >>>>>> Image image = new BufferedImage(WIDTH, HEIGHT, >>>>>> BufferedImage.TYPE_INT_RGB) { >>>>>> >>>>>> @Override >>>>>> public Image getScaledInstance(int width, int height, >>>>>> int >>>>>> hints) { >>>>>> if ((hints & Image.SCALE_DEFAULT) != 0) { >>>>>> return (width <= WIDTH && height <= HEIGHT) >>>>>> ? this : highResolutionImage; >>>>>> } >>>>>> return super.getScaledInstance(width, height, >>>>>> hints); >>>>>> } >>>>>> }; >>>>>> --------------------- >>>>>> >>>>>> The LWCToolkit and ToolkitImage classes are patched to >>>>>> automatically get provided image at 2x.ext images on MacOSX. >>>>>> >>>>>> There are no significant changes in the Java2D demo to make it >>>>>> look >>>>>> perfect on Retina displays. >>>>>> It needs only to put necessary images with the @2x postfix and >>>>>> they >>>>>> will be automatically drawn. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>> >>>> >> > > From peter.levart at gmail.com Thu Oct 31 13:46:35 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 31 Oct 2013 21:46:35 +0100 Subject: [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays In-Reply-To: <526FE63C.1020408@oracle.com> References: <52664607.2090807@oracle.com> <5267EA15.1080103@oracle.com> <526A6FB7.7000800@oracle.com> <526E3D75.5070308@oracle.com> <526FE63C.1020408@oracle.com> Message-ID: <5272C1AB.9030202@gmail.com> On 10/29/2013 05:45 PM, Alexander Scherbatiy wrote: >> 2. I'm not sure that the proposed getScaledImageName() implementation >> in ScalableToolkitImage works perfectly for URLs like this: >> >> http://www.exampmle.com/dir/image >> >> In this case it will try to find 2x image here: >> >> http://www.example at 2x.com/dir/image >> >> which doesn't look correct. > Fixed. Only path part of a URL is converted to path2x. Hi Alexander, URLs like this: http://www.example.com/dir.ext/image will still be translated to: http://www.example.com/dir at 2x.ext/image I think you need to search for last '.' after the last '/' in the getScaledImageName(); Also the following code has some additional bugs: 853 static Image toScalableImage(Image image, URL url) { 854 855 if (url != null && !url.toString().contains("@2x") 856 && !(image instanceof ScalableToolkitImage)) { 857 String protocol = url.getProtocol(); 858 String host = url.getHost(); 859 String file = url.getPath(); 860 String file2x =*host +*getScaledImageName(file); 861 try { 862 URL url2x = new URL(protocol, host, file2x); 863 url2x.openStream(); 864 return new ScalableToolkitImage(image, getDefaultToolkit().getImage(url2x)); 865 } catch (Exception ignore) { 866 } 867 } 868 return image; 869 } Why are you prepending *host* to getScaledImageName(file) in line 860? Let's take the following URL for example: http://www.example.com/dir/image.jpg protocol = "http" host = "www.example.com" file = "/dir/image.jpg" file2x = "*www.example.com*/dir/image at 2x.jpg" url2x = URL("http://www.example.com*www.example.com*/dir/image at 2x.jpg") You are missing a part in URL (de)construction - the optional port! For example in the following URL: http://www.example.com:8080/dir/image.jpg You should extract the port from original URL and use it in new URL construction if present (!= -1). I would also close the stream explicitly after probing for existence of resource rather than delegating to GC which might not be promptly and can cause resource exhaustion (think of MAX. # of open file descriptors): try (InputStream probe = url.openStream()) {} Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20131031/12d0e129/attachment.html