From shashidhara.veerabhadraiah at oracle.com  Thu Mar  1 04:09:44 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Wed, 28 Feb 2018 20:09:44 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <143b8e3a-fc31-d1d9-ebcc-a6df28d08a42@oracle.com>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
 <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
 <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>
 <4396fac6-4870-aad9-6e5f-c4b5e274c423@oracle.com>
 <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>
 <143b8e3a-fc31-d1d9-ebcc-a6df28d08a42@oracle.com>
Message-ID: <37e26222-53e9-4a11-84d3-b973405244d6@default>

Hi Semyon, It is not getting decreased for the case of SCROLLBARS_NEVER. The Boolean flags ?needsHorz? and ?needsVert? are false for the never case and true for the other cases. We decrease by the size of the scroll bars only for the true cases, so in the false case we will use the entire width and height(SM_CXEDGE and SM_CYEDGE).

?

Thanks and regards,
Shashi

?

From: Semyon Sadetsky 
Sent: Thursday, March 1, 2018 12:39 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

Hi Sashi,

The parent with and height shouldn't be decreased by the size of the scrollbars in case of SCROLLBARS_NEVER.

--Semyon

?

On 2/27/2018 12:45 AM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Thanks for your help. I did some debugging from that perspective and could find the problem and the solution. Here is the new webrev, please review it:

?

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.01/"http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/

?

The problem was that in the case of SCROLLBARS_NEVER, scroll bar info was set using setScrollInfo() with SIF_RANGE with ranges being (0, 0). This forced the windows to pick a default value and hence reset it to that value every time. Now the logic is modified in a very similar fashion as the other scroll bar display modes but without displaying it using the new win api ShowScrollBar(). The scroll bar info is supplied with a proper range per the corresponding base component but without the scroll bar pane size(as we don?t display it). This should suffice a good range for the scroll bars to operate and correct itself if there is any out of range value is supplied.

?

Thanks and regards,
Shashi

?

From: Semyon Sadetsky 
Sent: Tuesday, February 27, 2018 1:22 AM
To: shashidhara veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

The bug was failed against Windows platform. So, I'd try to find the root cause why when the scroll is notified with the scrolled component size the scroll position is set to the wrong value.

--Semyon

?

On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:

I think I agree Semyon. Thanks for your detailed explanation. 

?

So how do we approach on this? I see a different behaviour on other platforms. Shouldn?t we have a common behaviour across platforms? I agree with your analysis and hence should we change the behaviour on other platforms so that all of them will have the same behaviour?

?

Thanks and regards,

Shashi

?

On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky <HYPERLINK "mailto:semyon.sadetsky at oracle.com"semyon.sadetsky at oracle.com> wrote:

?

On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Thanks for your review and these questions help us to reach the right requirements.?

?

Without this change, there is different behavior on windows compared to Mac/Linux platforms. Hence this change is required to make the behavior same across the platforms. Since the scroll pane control is not displayed for the SCROLLBARS_NEVER case and if not in the setScrollPosition() then how can the user can move to a different position? Since we used to update/recalculate the scroll pane geometry caused changes to move to a different position other than the setScrollPosition()!! This causes SCROLLBARS_NEVER mode as unusable as the user is unable to control the scrolling movement because neither he can set one setScrollPosition() nor the control is displayed to explicitly set the movement. Hope this answers your question.

You need to think once again about two facts I brought in my previous message.

1. User still may scroll using mouse wheel even when scrollbars are not visible.

2. Visibility of scrollbars doesn't affect the requirement to notify the scroll about the scrolled component size changes. If the scrolled component was 500x500 in size and its position in the 200x200 viewport was (300,300) after the size of the component is changed to 300x300 it may not be shown at the same position because the previously visible component area doesn't exist anymore and the scroll should be moved to (100,100). This should work in the same way regardless the selected scrlollbar visibility policy.

--Semyon





?

Thanks and regards,
Shashi

?

From:?Semyon Sadetsky?
Sent:?Saturday, February 24, 2018 2:12 AM
To:?Shashidhara Veerabhadraiah?HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>;?HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Whenever the container is resized we used to update the scroll pane sizes/geometry regardless of the scroll bar display policies. This resizing make sense for the non SCROLLBARS_NEVER cases as the scroll pane is displayed or needed an update. This additional update posed issues for the SCROLLBARS_NEVER case where we are not supposed to display the scroll pane per the java doc, then why update?

?

Scroll pane geometry gets updated in 2 ways, one thro? setScrollPosition() and childResized(). So I derived the conclusion based on the javadoc information that since we don?t display the scroll pane there is no need to update the scroll pane geometry based on the childResized() as it was altering the position already set by the setScrollPosition(). This behavior is same as the other non SCROLLBARS_NEVER mode and setting the scroll bar display to SCROLLBARS_NEVER didn?t made any difference.

The only difference of SCROLLBARS_NEVER from others I got from javadoc is that the scroll bar controls are hidden. So the scrolling itself happens in the same way as in the case of visible scroll bars but it can be only controlled by mouse wheel or programmatically. In my understanding this means that the notification about the scrolled component size changes should happen in the same way as for all other cases. I see no reason for the differentiation that your fix introduces. What will happen if to remove this notification for visible scroll bars modes?

--Semyon





?

Thanks and regards,
Shashi

?

From:?Semyon Sadetsky?
Sent:?Friday, February 23, 2018 10:17 PM
To:?Shashidhara Veerabhadraiah?HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>;?HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Thanks for your review comments.

?

Here are those different scroll bar pane modes and their description:

Modifier and Type

Field

Description

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS"SCROLLBARS_ALWAYS

Specifies that horizontal/vertical scrollbars should always be shown regardless of the respective sizes of the scrollpane and child.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED"SCROLLBARS_AS_NEEDED

Specifies that horizontal/vertical scrollbar should be shown only when the size of the child exceeds the size of the scrollpane in the horizontal/vertical dimension.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER"SCROLLBARS_NEVER

Specifies that horizontal/vertical scrollbars should never be shown regardless of the respective sizes of the scrollpane and child.

?

This javadoc, you've copy-pasted here, doesn't explain why in your fix the notification about changed child size is disabled for SCROLLBARS_NEVER case.

Thanks and regards,
Shashi

?

From:?Semyon Sadetsky?
Sent:?Thursday, February 22, 2018 11:58 PM
To:?Shashidhara Veerabhadraiah?HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>;?HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

Hi Shashi,

Can you clarify what is the principal difference between SCROLLBARS_NEVER and other scroll policies that requires to avoid updating the scroll geometry according to the inner component size?

--Semyon

On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a code fix for the below bug.

?

Bug:?https://bugs.openjdk.java.net/browse/JDK-8195738

?

Webrev:?HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/

?

Problematic platform: Windows only.

?

Summary: This bug occurs only on windows platform and whereas the behavior is different on Mac/Linux platforms. Now after this fix there is common behavior across the platforms.

The main problem was with resetting the state of the scroll bars even though the scroll bar panes are spawned with SCROLLBARS_NEVER as the scroll bar display policy. This resetting should not occur as the scroll bar display policy makes the?

scroll bar panes invisible. Hence except the setScrollPosition() calls, we don?t need to resize/update the scroll bars state upon calling the scroll bars validation if SCROLLBARS_NEVER policy is used as the scroll bars are not displayed.

?

Thanks and regards,
Shashi

?

?

?

?

?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180228/943deeea/attachment-0001.html>

From shashidhara.veerabhadraiah at oracle.com  Thu Mar  1 10:41:56 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 1 Mar 2018 02:41:56 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <d0bf586b-698e-21d6-c951-cbe53457a360@oracle.com>
References: <b01398ea-f7c1-41a4-8845-20c0da99eccd@default>
 <eb824adb-920b-456e-bbed-a075a408ecd5@default>
 <d0bf586b-698e-21d6-c951-cbe53457a360@oracle.com>
Message-ID: <cd69a05c-c0b1-41eb-be21-9541c6dd07b9@default>

Hi All, I have verified this test by running on Krishna's machine which has windows 10 build 1703 and found that the test is falsely passing there as well. So we can safely say that Windows 10 build 1703 as a "fall creators" build.

Sergey, we have a floating point dpi scale(dpi value/96) and we use it to scale down and up to convert from user space to device space and vice versa. This code is present at awt_Win32GraphicsDevice.cpp. In this code if you see we use clipRound() with ceil() function. Since there float to int involved with ceil operation may cause + or - 1 pixel variation in it's value I think. Please correct me if I am wrong here.

Since there is an issue with windows 10 build 1703 and also the original fix is mac specific, I think my test fix to keep it specific to mac is the right decision to make. Please correct me if I am wrong here.

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, March 1, 2018 2:23 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails

On 27/02/2018 07:51, Shashidhara Veerabhadraiah wrote:
> Threshold is added because I think it is quite possible especially with hidpi(fractional) since convert back and forth from user space to device coordinates which typically results in plus or minus 1 pixel correction(because of division or multiplication). The bug link contains the call stack where it is reported as (29, 29) as the location and hence the test fails.

If we have an incorrect conversion to/from device space somewhere, then we should check the reason of this bug instead of adding some threshold to the test.



--
Best regards, Sergey.

From anton.litvinov at oracle.com  Thu Mar  1 16:30:50 2018
From: anton.litvinov at oracle.com (anton.litvinov at oracle.com)
Date: Thu, 1 Mar 2018 16:30:50 +0000
Subject: <AWT Dev> [11] Review request for 8198605: Touch keyboard is shown
 for a non-focusable text component
Message-ID: <6b137036-dcb8-6b58-0e4c-372a0141ecdd@oracle.com>

Hello,

Could you please review the following fix for the bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198605
Webrev: http://cr.openjdk.java.net/~alitvinov/8198605/jdk11/webrev.00

The fix extends a number of the required conditions in the method 
"sun.awt.windows.WToolkit.showOrHideTouchKeyboard(Component, AWTEvent)", 
which should be satisfied for showing of the touch keyboard, by checking 
if the component is focusable or not.

Thank you,
Anton

From semyon.sadetsky at oracle.com  Thu Mar  1 17:37:58 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Thu, 1 Mar 2018 09:37:58 -0800
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <37e26222-53e9-4a11-84d3-b973405244d6@default>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
 <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
 <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>
 <4396fac6-4870-aad9-6e5f-c4b5e274c423@oracle.com>
 <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>
 <143b8e3a-fc31-d1d9-ebcc-a6df28d08a42@oracle.com>
 <37e26222-53e9-4a11-84d3-b973405244d6@default>
Message-ID: <c8e229a0-2023-814e-3284-59478ea4358a@oracle.com>

On 2/28/18 8:09 PM, Shashidhara Veerabhadraiah wrote:

> Hi Semyon, It is not getting decreased for the case of 
> SCROLLBARS_NEVER. The Boolean flags ?needsHorz? and ?needsVert? are 
> false for the never case and true for the other cases. We decrease by 
> the size of the scroll bars only for the true cases, so in the false 
> case we will use the entire width and height(SM_CXEDGE and SM_CYEDGE).
>
Can you clarify this a bit more? I see the next lines executed without 
any conditions

215     parentWidth -= (horzBorder * 2);
216     parentHeight -= (vertBorder * 2);

--Semyon
>
> Thanks and regards,
> Shashi
>
> *From:*Semyon Sadetsky
> *Sent:* Thursday, March 1, 2018 12:39 AM
> *To:* Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
> *Cc:* awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in 
> ScrollPane is reset after calling validate()
>
> Hi Sashi,
>
> The parent with and height shouldn't be decreased by the size of the 
> scrollbars in case of SCROLLBARS_NEVER.
>
> --Semyon
>
> On 2/27/2018 12:45 AM, Shashidhara Veerabhadraiah wrote:
>
>     Hi Semyon, Thanks for your help. I did some debugging from that
>     perspective and could find the problem and the solution. Here is
>     the new webrev, please review it:
>
>     http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.01/>
>
>     The problem was that in the case of SCROLLBARS_NEVER, scroll bar
>     info was set using setScrollInfo() with SIF_RANGE with ranges
>     being (0, 0). This forced the windows to pick a default value and
>     hence reset it to that value every time. Now the logic is modified
>     in a very similar fashion as the other scroll bar display modes
>     but without displaying it using the new win api ShowScrollBar().
>     The scroll bar info is supplied with a proper range per the
>     corresponding base component but without the scroll bar pane
>     size(as we don?t display it). This should suffice a good range for
>     the scroll bars to operate and correct itself if there is any out
>     of range value is supplied.
>
>     Thanks and regards,
>     Shashi
>
>     *From:*Semyon Sadetsky
>     *Sent:* Tuesday, February 27, 2018 1:22 AM
>     *To:* shashidhara veerabhadraiah
>     <shashidhara.veerabhadraiah at oracle.com>
>     <mailto:shashidhara.veerabhadraiah at oracle.com>
>     *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>     ScrollPane is reset after calling validate()
>
>     The bug was failed against Windows platform. So, I'd try to find
>     the root cause why when the scroll is notified with the scrolled
>     component size the scroll position is set to the wrong value.
>
>     --Semyon
>
>     On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:
>
>         I think I agree Semyon. Thanks for your detailed explanation.
>
>         So how do we approach on this? I see a different behaviour on
>         other platforms. Shouldn?t we have a common behaviour across
>         platforms? I agree with your analysis and hence should we
>         change the behaviour on other platforms so that all of them
>         will have the same behaviour?
>
>         Thanks and regards,
>
>         Shashi
>
>             On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky
>             <semyon.sadetsky at oracle.com
>             <mailto:semyon.sadetsky at oracle.com>> wrote:
>
>             On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:
>
>                 Hi Semyon, Thanks for your review and these questions
>                 help us to reach the right requirements.
>
>                 Without this change, there is different behavior on
>                 windows compared to Mac/Linux platforms. Hence this
>                 change is required to make the behavior same across
>                 the platforms. Since the scroll pane control is not
>                 displayed for the SCROLLBARS_NEVER case and if not in
>                 the setScrollPosition() then how can the user can move
>                 to a different position? Since we used to
>                 update/recalculate the scroll pane geometry caused
>                 changes to move to a different position other than the
>                 setScrollPosition()!! This causes SCROLLBARS_NEVER
>                 mode as unusable as the user is unable to control the
>                 scrolling movement because neither he can set one
>                 setScrollPosition() nor the control is displayed to
>                 explicitly set the movement. Hope this answers your
>                 question.
>
>             You need to think once again about two facts I brought in
>             my previous message.
>
>             1. User still may scroll using mouse wheel even when
>             scrollbars are not visible.
>
>             2. Visibility of scrollbars doesn't affect the requirement
>             to notify the scroll about the scrolled component size
>             changes. If the scrolled component was 500x500 in size and
>             its position in the 200x200 viewport was (300,300) after
>             the size of the component is changed to 300x300 it may not
>             be shown at the same position because the previously
>             visible component area doesn't exist anymore and the
>             scroll should be moved to (100,100). This should work in
>             the same way regardless the selected scrlollbar visibility
>             policy.
>
>             --Semyon
>
>
>
>                 Thanks and regards,
>                 Shashi
>
>                 *From:*Semyon Sadetsky
>                 *Sent:*Saturday, February 24, 2018 2:12 AM
>                 *To:*Shashidhara
>                 Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>                 <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>                 <mailto:awt-dev at openjdk.java.net>
>                 *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>                 poistion in ScrollPane is reset after calling validate()
>
>                 On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:
>
>                     Hi Semyon, Whenever the container is resized we
>                     used to update the scroll pane sizes/geometry
>                     regardless of the scroll bar display policies.
>                     This resizing make sense for the non
>                     SCROLLBARS_NEVER cases as the scroll pane is
>                     displayed or needed an update. This additional
>                     update posed issues for the SCROLLBARS_NEVER case
>                     where we are not supposed to display the scroll
>                     pane per the java doc, then why update?
>
>                     Scroll pane geometry gets updated in 2 ways, one
>                     thro? setScrollPosition() and childResized(). So I
>                     derived the conclusion based on the javadoc
>                     information that since we don?t display the scroll
>                     pane there is no need to update the scroll pane
>                     geometry based on the childResized() as it was
>                     altering the position already set by the
>                     setScrollPosition(). This behavior is same as the
>                     other non SCROLLBARS_NEVER mode and setting the
>                     scroll bar display to SCROLLBARS_NEVER didn?t made
>                     any difference.
>
>                 The only difference of SCROLLBARS_NEVER from others I
>                 got from javadoc is that the scroll bar controls are
>                 hidden. So the scrolling itself happens in the same
>                 way as in the case of visible scroll bars but it can
>                 be only controlled by mouse wheel or programmatically.
>                 In my understanding this means that the notification
>                 about the scrolled component size changes should
>                 happen in the same way as for all other cases. I see
>                 no reason for the differentiation that your fix
>                 introduces. What will happen if to remove this
>                 notification for visible scroll bars modes?
>
>                 --Semyon
>
>
>
>                     Thanks and regards,
>                     Shashi
>
>                     *From:*Semyon Sadetsky
>                     *Sent:*Friday, February 23, 2018 10:17 PM
>                     *To:*Shashidhara
>                     Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>                     <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>                     <mailto:awt-dev at openjdk.java.net>
>                     *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>                     poistion in ScrollPane is reset after calling
>                     validate()
>
>                     On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:
>
>                         Hi Semyon, Thanks for your review comments.
>
>                         Here are those different scroll bar pane modes
>                         and their description:
>
>                         *Modifier and Type*
>
>                         	
>
>                         *Field*
>
>                         	
>
>                         *Description*
>
>                         |static int|
>
>                         	
>
>                         *SCROLLBARS_ALWAYS
>                         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS>*
>
>                         	
>
>                         Specifies that horizontal/vertical scrollbars
>                         should always be shown regardless of the
>                         respective sizes of the scrollpane and child.
>
>                         |static int|
>
>                         	
>
>                         *SCROLLBARS_AS_NEEDED
>                         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED>*
>
>                         	
>
>                         Specifies that horizontal/vertical scrollbar
>                         should be shown only when the size of the
>                         child exceeds the size of the scrollpane in
>                         the horizontal/vertical dimension.
>
>                         |static int|
>
>                         	
>
>                         *SCROLLBARS_NEVER
>                         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER>*
>
>                         	
>
>                         Specifies that horizontal/vertical scrollbars
>                         should never be shown regardless of the
>                         respective sizes of the scrollpane and child.
>
>                     This javadoc, you've copy-pasted here, doesn't
>                     explain why in your fix the notification about
>                     changed child size is disabled for
>                     SCROLLBARS_NEVER case.
>
>                         Thanks and regards,
>                         Shashi
>
>                         *From:*Semyon Sadetsky
>                         *Sent:*Thursday, February 22, 2018 11:58 PM
>                         *To:*Shashidhara
>                         Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>                         <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>                         <mailto:awt-dev at openjdk.java.net>
>                         *Subject:*Re: <AWT Dev> [11] JDK-8195738:
>                         scroll poistion in ScrollPane is reset after
>                         calling validate()
>
>                         Hi Shashi,
>
>                         Can you clarify what is the principal
>                         difference between SCROLLBARS_NEVER and other
>                         scroll policies that requires to avoid
>                         updating the scroll geometry according to the
>                         inner component size?
>
>                         --Semyon
>
>                         On 02/19/2018 11:08 PM, Shashidhara
>                         Veerabhadraiah wrote:
>
>                             Hi All, Please review a code fix for the
>                             below bug.
>
>                             Bug:https://bugs.openjdk.java.net/browse/JDK-8195738
>
>                             Webrev:http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
>                             <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
>
>                             Problematic platform: Windows only.
>
>                             Summary: This bug occurs only on windows
>                             platform and whereas the behavior is
>                             different on Mac/Linux platforms. Now
>                             after this fix there is common behavior
>                             across the platforms.
>
>                             The main problem was with resetting the
>                             state of the scroll bars even though the
>                             scroll bar panes are spawned with
>                             SCROLLBARS_NEVER as the scroll bar display
>                             policy. This resetting should not occur as
>                             the scroll bar display policy makes the
>
>                             scroll bar panes invisible. Hence except
>                             the setScrollPosition() calls, we don?t
>                             need to resize/update the scroll bars
>                             state upon calling the scroll bars
>                             validation if SCROLLBARS_NEVER policy is
>                             used as the scroll bars are not displayed.
>
>                             Thanks and regards,
>                             Shashi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180301/747b247b/attachment-0001.html>

From semyon.sadetsky at oracle.com  Thu Mar  1 17:46:38 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Thu, 1 Mar 2018 09:46:38 -0800
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <c8e229a0-2023-814e-3284-59478ea4358a@oracle.com>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
 <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
 <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>
 <4396fac6-4870-aad9-6e5f-c4b5e274c423@oracle.com>
 <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>
 <143b8e3a-fc31-d1d9-ebcc-a6df28d08a42@oracle.com>
 <37e26222-53e9-4a11-84d3-b973405244d6@default>
 <c8e229a0-2023-814e-3284-59478ea4358a@oracle.com>
Message-ID: <9eb6fd2f-85ce-582e-945f-d77b91d4bea8@oracle.com>

On 3/1/18 9:37 AM, semyon.sadetsky at oracle.com wrote:

> On 2/28/18 8:09 PM, Shashidhara Veerabhadraiah wrote:
>
>> Hi Semyon, It is not getting decreased for the case of 
>> SCROLLBARS_NEVER. The Boolean flags ?needsHorz? and ?needsVert? are 
>> false for the never case and true for the other cases. We decrease by 
>> the size of the scroll bars only for the true cases, so in the false 
>> case we will use the entire width and height(SM_CXEDGE and SM_CYEDGE).
>>
> Can you clarify this a bit more? I see the next lines executed without 
> any conditions
>
> 215     parentWidth -= (horzBorder * 2);
> 216     parentHeight -= (vertBorder * 2);
I was not right this is just borders.

Looks good to me.

--Semyon
>
> --Semyon
>>
>> Thanks and regards,
>> Shashi
>>
>> *From:*Semyon Sadetsky
>> *Sent:* Thursday, March 1, 2018 12:39 AM
>> *To:* Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
>> *Cc:* awt-dev at openjdk.java.net
>> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in 
>> ScrollPane is reset after calling validate()
>>
>> Hi Sashi,
>>
>> The parent with and height shouldn't be decreased by the size of the 
>> scrollbars in case of SCROLLBARS_NEVER.
>>
>> --Semyon
>>
>> On 2/27/2018 12:45 AM, Shashidhara Veerabhadraiah wrote:
>>
>>     Hi Semyon, Thanks for your help. I did some debugging from that
>>     perspective and could find the problem and the solution. Here is
>>     the new webrev, please review it:
>>
>>     http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/
>>     <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.01/>
>>
>>     The problem was that in the case of SCROLLBARS_NEVER, scroll bar
>>     info was set using setScrollInfo() with SIF_RANGE with ranges
>>     being (0, 0). This forced the windows to pick a default value and
>>     hence reset it to that value every time. Now the logic is
>>     modified in a very similar fashion as the other scroll bar
>>     display modes but without displaying it using the new win api
>>     ShowScrollBar(). The scroll bar info is supplied with a proper
>>     range per the corresponding base component but without the scroll
>>     bar pane size(as we don?t display it). This should suffice a good
>>     range for the scroll bars to operate and correct itself if there
>>     is any out of range value is supplied.
>>
>>     Thanks and regards,
>>     Shashi
>>
>>     *From:*Semyon Sadetsky
>>     *Sent:* Tuesday, February 27, 2018 1:22 AM
>>     *To:* shashidhara veerabhadraiah
>>     <shashidhara.veerabhadraiah at oracle.com>
>>     <mailto:shashidhara.veerabhadraiah at oracle.com>
>>     *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>>     *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>>     ScrollPane is reset after calling validate()
>>
>>     The bug was failed against Windows platform. So, I'd try to find
>>     the root cause why when the scroll is notified with the scrolled
>>     component size the scroll position is set to the wrong value.
>>
>>     --Semyon
>>
>>     On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:
>>
>>         I think I agree Semyon. Thanks for your detailed explanation.
>>
>>         So how do we approach on this? I see a different behaviour on
>>         other platforms. Shouldn?t we have a common behaviour across
>>         platforms? I agree with your analysis and hence should we
>>         change the behaviour on other platforms so that all of them
>>         will have the same behaviour?
>>
>>         Thanks and regards,
>>
>>         Shashi
>>
>>             On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky
>>             <semyon.sadetsky at oracle.com
>>             <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>>             On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:
>>
>>                 Hi Semyon, Thanks for your review and these questions
>>                 help us to reach the right requirements.
>>
>>                 Without this change, there is different behavior on
>>                 windows compared to Mac/Linux platforms. Hence this
>>                 change is required to make the behavior same across
>>                 the platforms. Since the scroll pane control is not
>>                 displayed for the SCROLLBARS_NEVER case and if not in
>>                 the setScrollPosition() then how can the user can
>>                 move to a different position? Since we used to
>>                 update/recalculate the scroll pane geometry caused
>>                 changes to move to a different position other than
>>                 the setScrollPosition()!! This causes
>>                 SCROLLBARS_NEVER mode as unusable as the user is
>>                 unable to control the scrolling movement because
>>                 neither he can set one setScrollPosition() nor the
>>                 control is displayed to explicitly set the movement.
>>                 Hope this answers your question.
>>
>>             You need to think once again about two facts I brought in
>>             my previous message.
>>
>>             1. User still may scroll using mouse wheel even when
>>             scrollbars are not visible.
>>
>>             2. Visibility of scrollbars doesn't affect the
>>             requirement to notify the scroll about the scrolled
>>             component size changes. If the scrolled component was
>>             500x500 in size and its position in the 200x200 viewport
>>             was (300,300) after the size of the component is changed
>>             to 300x300 it may not be shown at the same position
>>             because the previously visible component area doesn't
>>             exist anymore and the scroll should be moved to
>>             (100,100). This should work in the same way regardless
>>             the selected scrlollbar visibility policy.
>>
>>             --Semyon
>>
>>
>>
>>                 Thanks and regards,
>>                 Shashi
>>
>>                 *From:*Semyon Sadetsky
>>                 *Sent:*Saturday, February 24, 2018 2:12 AM
>>                 *To:*Shashidhara
>>                 Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>>                 <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>                 <mailto:awt-dev at openjdk.java.net>
>>                 *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>>                 poistion in ScrollPane is reset after calling validate()
>>
>>                 On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:
>>
>>                     Hi Semyon, Whenever the container is resized we
>>                     used to update the scroll pane sizes/geometry
>>                     regardless of the scroll bar display policies.
>>                     This resizing make sense for the non
>>                     SCROLLBARS_NEVER cases as the scroll pane is
>>                     displayed or needed an update. This additional
>>                     update posed issues for the SCROLLBARS_NEVER case
>>                     where we are not supposed to display the scroll
>>                     pane per the java doc, then why update?
>>
>>                     Scroll pane geometry gets updated in 2 ways, one
>>                     thro? setScrollPosition() and childResized(). So
>>                     I derived the conclusion based on the javadoc
>>                     information that since we don?t display the
>>                     scroll pane there is no need to update the scroll
>>                     pane geometry based on the childResized() as it
>>                     was altering the position already set by the
>>                     setScrollPosition(). This behavior is same as the
>>                     other non SCROLLBARS_NEVER mode and setting the
>>                     scroll bar display to SCROLLBARS_NEVER didn?t
>>                     made any difference.
>>
>>                 The only difference of SCROLLBARS_NEVER from others I
>>                 got from javadoc is that the scroll bar controls are
>>                 hidden. So the scrolling itself happens in the same
>>                 way as in the case of visible scroll bars but it can
>>                 be only controlled by mouse wheel or
>>                 programmatically. In my understanding this means that
>>                 the notification about the scrolled component size
>>                 changes should happen in the same way as for all
>>                 other cases. I see no reason for the differentiation
>>                 that your fix introduces. What will happen if to
>>                 remove this notification for visible scroll bars modes?
>>
>>                 --Semyon
>>
>>
>>
>>                     Thanks and regards,
>>                     Shashi
>>
>>                     *From:*Semyon Sadetsky
>>                     *Sent:*Friday, February 23, 2018 10:17 PM
>>                     *To:*Shashidhara
>>                     Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>>                     <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>                     <mailto:awt-dev at openjdk.java.net>
>>                     *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>>                     poistion in ScrollPane is reset after calling
>>                     validate()
>>
>>                     On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:
>>
>>                         Hi Semyon, Thanks for your review comments.
>>
>>                         Here are those different scroll bar pane
>>                         modes and their description:
>>
>>                         *Modifier and Type*
>>
>>                         	
>>
>>                         *Field*
>>
>>                         	
>>
>>                         *Description*
>>
>>                         |static int|
>>
>>                         	
>>
>>                         *SCROLLBARS_ALWAYS
>>                         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS>*
>>
>>                         	
>>
>>                         Specifies that horizontal/vertical scrollbars
>>                         should always be shown regardless of the
>>                         respective sizes of the scrollpane and child.
>>
>>                         |static int|
>>
>>                         	
>>
>>                         *SCROLLBARS_AS_NEEDED
>>                         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED>*
>>
>>                         	
>>
>>                         Specifies that horizontal/vertical scrollbar
>>                         should be shown only when the size of the
>>                         child exceeds the size of the scrollpane in
>>                         the horizontal/vertical dimension.
>>
>>                         |static int|
>>
>>                         	
>>
>>                         *SCROLLBARS_NEVER
>>                         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER>*
>>
>>                         	
>>
>>                         Specifies that horizontal/vertical scrollbars
>>                         should never be shown regardless of the
>>                         respective sizes of the scrollpane and child.
>>
>>                     This javadoc, you've copy-pasted here, doesn't
>>                     explain why in your fix the notification about
>>                     changed child size is disabled for
>>                     SCROLLBARS_NEVER case.
>>
>>                         Thanks and regards,
>>                         Shashi
>>
>>                         *From:*Semyon Sadetsky
>>                         *Sent:*Thursday, February 22, 2018 11:58 PM
>>                         *To:*Shashidhara
>>                         Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>>                         <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>                         <mailto:awt-dev at openjdk.java.net>
>>                         *Subject:*Re: <AWT Dev> [11] JDK-8195738:
>>                         scroll poistion in ScrollPane is reset after
>>                         calling validate()
>>
>>                         Hi Shashi,
>>
>>                         Can you clarify what is the principal
>>                         difference between SCROLLBARS_NEVER and other
>>                         scroll policies that requires to avoid
>>                         updating the scroll geometry according to the
>>                         inner component size?
>>
>>                         --Semyon
>>
>>                         On 02/19/2018 11:08 PM, Shashidhara
>>                         Veerabhadraiah wrote:
>>
>>                             Hi All, Please review a code fix for the
>>                             below bug.
>>
>>                             Bug:https://bugs.openjdk.java.net/browse/JDK-8195738
>>
>>                             Webrev:http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
>>                             <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
>>
>>                             Problematic platform: Windows only.
>>
>>                             Summary: This bug occurs only on windows
>>                             platform and whereas the behavior is
>>                             different on Mac/Linux platforms. Now
>>                             after this fix there is common behavior
>>                             across the platforms.
>>
>>                             The main problem was with resetting the
>>                             state of the scroll bars even though the
>>                             scroll bar panes are spawned with
>>                             SCROLLBARS_NEVER as the scroll bar
>>                             display policy. This resetting should not
>>                             occur as the scroll bar display policy
>>                             makes the
>>
>>                             scroll bar panes invisible. Hence except
>>                             the setScrollPosition() calls, we don?t
>>                             need to resize/update the scroll bars
>>                             state upon calling the scroll bars
>>                             validation if SCROLLBARS_NEVER policy is
>>                             used as the scroll bars are not displayed.
>>
>>                             Thanks and regards,
>>                             Shashi
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180301/23be770d/attachment-0001.html>

From shashidhara.veerabhadraiah at oracle.com  Thu Mar  1 18:09:06 2018
From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com)
Date: Thu, 1 Mar 2018 23:39:06 +0530
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <9eb6fd2f-85ce-582e-945f-d77b91d4bea8@oracle.com>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
 <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
 <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>
 <4396fac6-4870-aad9-6e5f-c4b5e274c423@oracle.com>
 <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>
 <143b8e3a-fc31-d1d9-ebcc-a6df28d08a42@oracle.com>
 <37e26222-53e9-4a11-84d3-b973405244d6@default>
 <c8e229a0-2023-814e-3284-59478ea4358a@oracle.com>
 <9eb6fd2f-85ce-582e-945f-d77b91d4bea8@oracle.com>
Message-ID: <752a3505-687a-467d-6f69-657958a5867b@oracle.com>

Thank you Semyon for the review.


On 01/03/18 11:16 PM, semyon.sadetsky at oracle.com wrote:
>
> On 3/1/18 9:37 AM, semyon.sadetsky at oracle.com wrote:
>
>> On 2/28/18 8:09 PM, Shashidhara Veerabhadraiah wrote:
>>
>>> Hi Semyon, It is not getting decreased for the case of 
>>> SCROLLBARS_NEVER. The Boolean flags ?needsHorz? and ?needsVert? are 
>>> false for the never case and true for the other cases. We decrease 
>>> by the size of the scroll bars only for the true cases, so in the 
>>> false case we will use the entire width and height(SM_CXEDGE and 
>>> SM_CYEDGE).
>>>
>> Can you clarify this a bit more? I see the next lines executed 
>> without any conditions
>>
>> 215???? parentWidth -= (horzBorder * 2);
>> 216???? parentHeight -= (vertBorder * 2);
> I was not right this is just borders.
>
> Looks good to me.
>
> --Semyon
>>
>> --Semyon
>>>
>>> Thanks and regards,
>>> Shashi
>>>
>>> *From:*Semyon Sadetsky
>>> *Sent:* Thursday, March 1, 2018 12:39 AM
>>> *To:* Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
>>> *Cc:* awt-dev at openjdk.java.net
>>> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in 
>>> ScrollPane is reset after calling validate()
>>>
>>> Hi Sashi,
>>>
>>> The parent with and height shouldn't be decreased by the size of the 
>>> scrollbars in case of SCROLLBARS_NEVER.
>>>
>>> --Semyon
>>>
>>> On 2/27/2018 12:45 AM, Shashidhara Veerabhadraiah wrote:
>>>
>>>     Hi Semyon, Thanks for your help. I did some debugging from that
>>>     perspective and could find the problem and the solution. Here is
>>>     the new webrev, please review it:
>>>
>>>     http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/
>>>     <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.01/>
>>>
>>>     The problem was that in the case of SCROLLBARS_NEVER, scroll bar
>>>     info was set using setScrollInfo() with SIF_RANGE with ranges
>>>     being (0, 0). This forced the windows to pick a default value
>>>     and hence reset it to that value every time. Now the logic is
>>>     modified in a very similar fashion as the other scroll bar
>>>     display modes but without displaying it using the new win api
>>>     ShowScrollBar(). The scroll bar info is supplied with a proper
>>>     range per the corresponding base component but without the
>>>     scroll bar pane size(as we don?t display it). This should
>>>     suffice a good range for the scroll bars to operate and correct
>>>     itself if there is any out of range value is supplied.
>>>
>>>     Thanks and regards,
>>>     Shashi
>>>
>>>     *From:*Semyon Sadetsky
>>>     *Sent:* Tuesday, February 27, 2018 1:22 AM
>>>     *To:* shashidhara veerabhadraiah
>>>     <shashidhara.veerabhadraiah at oracle.com>
>>>     <mailto:shashidhara.veerabhadraiah at oracle.com>
>>>     *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>>>     *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>>>     ScrollPane is reset after calling validate()
>>>
>>>     The bug was failed against Windows platform. So, I'd try to find
>>>     the root cause why when the scroll is notified with the scrolled
>>>     component size the scroll position is set to the wrong value.
>>>
>>>     --Semyon
>>>
>>>     On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:
>>>
>>>         I think I agree Semyon. Thanks for your detailed explanation.
>>>
>>>         So how do we approach on this? I see a different behaviour
>>>         on other platforms. Shouldn?t we have a common behaviour
>>>         across platforms? I agree with your analysis and hence
>>>         should we change the behaviour on other platforms so that
>>>         all of them will have the same behaviour?
>>>
>>>         Thanks and regards,
>>>
>>>         Shashi
>>>
>>>             On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky
>>>             <semyon.sadetsky at oracle.com
>>>             <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>
>>>             On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:
>>>
>>>                 Hi Semyon, Thanks for your review and these
>>>                 questions help us to reach the right requirements.
>>>
>>>                 Without this change, there is different behavior on
>>>                 windows compared to Mac/Linux platforms. Hence this
>>>                 change is required to make the behavior same across
>>>                 the platforms. Since the scroll pane control is not
>>>                 displayed for the SCROLLBARS_NEVER case and if not
>>>                 in the setScrollPosition() then how can the user can
>>>                 move to a different position? Since we used to
>>>                 update/recalculate the scroll pane geometry caused
>>>                 changes to move to a different position other than
>>>                 the setScrollPosition()!! This causes
>>>                 SCROLLBARS_NEVER mode as unusable as the user is
>>>                 unable to control the scrolling movement because
>>>                 neither he can set one setScrollPosition() nor the
>>>                 control is displayed to explicitly set the movement.
>>>                 Hope this answers your question.
>>>
>>>             You need to think once again about two facts I brought
>>>             in my previous message.
>>>
>>>             1. User still may scroll using mouse wheel even when
>>>             scrollbars are not visible.
>>>
>>>             2. Visibility of scrollbars doesn't affect the
>>>             requirement to notify the scroll about the scrolled
>>>             component size changes. If the scrolled component was
>>>             500x500 in size and its position in the 200x200 viewport
>>>             was (300,300) after the size of the component is changed
>>>             to 300x300 it may not be shown at the same position
>>>             because the previously visible component area doesn't
>>>             exist anymore and the scroll should be moved to
>>>             (100,100). This should work in the same way regardless
>>>             the selected scrlollbar visibility policy.
>>>
>>>             --Semyon
>>>
>>>
>>>
>>>                 Thanks and regards,
>>>                 Shashi
>>>
>>>                 *From:*Semyon Sadetsky
>>>                 *Sent:*Saturday, February 24, 2018 2:12 AM
>>>                 *To:*Shashidhara
>>>                 Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>>>                 <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>>                 <mailto:awt-dev at openjdk.java.net>
>>>                 *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>>>                 poistion in ScrollPane is reset after calling validate()
>>>
>>>                 On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:
>>>
>>>                     Hi Semyon, Whenever the container is resized we
>>>                     used to update the scroll pane sizes/geometry
>>>                     regardless of the scroll bar display policies.
>>>                     This resizing make sense for the non
>>>                     SCROLLBARS_NEVER cases as the scroll pane is
>>>                     displayed or needed an update. This additional
>>>                     update posed issues for the SCROLLBARS_NEVER
>>>                     case where we are not supposed to display the
>>>                     scroll pane per the java doc, then why update?
>>>
>>>                     Scroll pane geometry gets updated in 2 ways, one
>>>                     thro? setScrollPosition() and childResized(). So
>>>                     I derived the conclusion based on the javadoc
>>>                     information that since we don?t display the
>>>                     scroll pane there is no need to update the
>>>                     scroll pane geometry based on the childResized()
>>>                     as it was altering the position already set by
>>>                     the setScrollPosition(). This behavior is same
>>>                     as the other non SCROLLBARS_NEVER mode and
>>>                     setting the scroll bar display to
>>>                     SCROLLBARS_NEVER didn?t made any difference.
>>>
>>>                 The only difference of SCROLLBARS_NEVER from others
>>>                 I got from javadoc is that the scroll bar controls
>>>                 are hidden. So the scrolling itself happens in the
>>>                 same way as in the case of visible scroll bars but
>>>                 it can be only controlled by mouse wheel or
>>>                 programmatically. In my understanding this means
>>>                 that the notification about the scrolled component
>>>                 size changes should happen in the same way as for
>>>                 all other cases. I see no reason for the
>>>                 differentiation that your fix introduces. What will
>>>                 happen if to remove this notification for visible
>>>                 scroll bars modes?
>>>
>>>                 --Semyon
>>>
>>>
>>>
>>>                     Thanks and regards,
>>>                     Shashi
>>>
>>>                     *From:*Semyon Sadetsky
>>>                     *Sent:*Friday, February 23, 2018 10:17 PM
>>>                     *To:*Shashidhara
>>>                     Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>>>                     <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>>                     <mailto:awt-dev at openjdk.java.net>
>>>                     *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>>>                     poistion in ScrollPane is reset after calling
>>>                     validate()
>>>
>>>                     On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah
>>>                     wrote:
>>>
>>>                         Hi Semyon, Thanks for your review comments.
>>>
>>>                         Here are those different scroll bar pane
>>>                         modes and their description:
>>>
>>>                         *Modifier and Type*
>>>
>>>                         	
>>>
>>>                         *Field*
>>>
>>>                         	
>>>
>>>                         *Description*
>>>
>>>                         |static int|
>>>
>>>                         	
>>>
>>>                         *SCROLLBARS_ALWAYS
>>>                         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS>*
>>>
>>>                         	
>>>
>>>                         Specifies that horizontal/vertical
>>>                         scrollbars should always be shown regardless
>>>                         of the respective sizes of the scrollpane
>>>                         and child.
>>>
>>>                         |static int|
>>>
>>>                         	
>>>
>>>                         *SCROLLBARS_AS_NEEDED
>>>                         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED>*
>>>
>>>                         	
>>>
>>>                         Specifies that horizontal/vertical scrollbar
>>>                         should be shown only when the size of the
>>>                         child exceeds the size of the scrollpane in
>>>                         the horizontal/vertical dimension.
>>>
>>>                         |static int|
>>>
>>>                         	
>>>
>>>                         *SCROLLBARS_NEVER
>>>                         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER>*
>>>
>>>                         	
>>>
>>>                         Specifies that horizontal/vertical
>>>                         scrollbars should never be shown regardless
>>>                         of the respective sizes of the scrollpane
>>>                         and child.
>>>
>>>                     This javadoc, you've copy-pasted here, doesn't
>>>                     explain why in your fix the notification about
>>>                     changed child size is disabled for
>>>                     SCROLLBARS_NEVER case.
>>>
>>>                         Thanks and regards,
>>>                         Shashi
>>>
>>>                         *From:*Semyon Sadetsky
>>>                         *Sent:*Thursday, February 22, 2018 11:58 PM
>>>                         *To:*Shashidhara
>>>                         Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>>>                         <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>>                         <mailto:awt-dev at openjdk.java.net>
>>>                         *Subject:*Re: <AWT Dev> [11] JDK-8195738:
>>>                         scroll poistion in ScrollPane is reset after
>>>                         calling validate()
>>>
>>>                         Hi Shashi,
>>>
>>>                         Can you clarify what is the principal
>>>                         difference between SCROLLBARS_NEVER and
>>>                         other scroll policies that requires to avoid
>>>                         updating the scroll geometry according to
>>>                         the inner component size?
>>>
>>>                         --Semyon
>>>
>>>                         On 02/19/2018 11:08 PM, Shashidhara
>>>                         Veerabhadraiah wrote:
>>>
>>>                             Hi All, Please review a code fix for the
>>>                             below bug.
>>>
>>>                             Bug:https://bugs.openjdk.java.net/browse/JDK-8195738
>>>
>>>                             Webrev:http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
>>>                             <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
>>>
>>>                             Problematic platform: Windows only.
>>>
>>>                             Summary: This bug occurs only on windows
>>>                             platform and whereas the behavior is
>>>                             different on Mac/Linux platforms. Now
>>>                             after this fix there is common behavior
>>>                             across the platforms.
>>>
>>>                             The main problem was with resetting the
>>>                             state of the scroll bars even though the
>>>                             scroll bar panes are spawned with
>>>                             SCROLLBARS_NEVER as the scroll bar
>>>                             display policy. This resetting should
>>>                             not occur as the scroll bar display
>>>                             policy makes the
>>>
>>>                             scroll bar panes invisible. Hence except
>>>                             the setScrollPosition() calls, we don?t
>>>                             need to resize/update the scroll bars
>>>                             state upon calling the scroll bars
>>>                             validation if SCROLLBARS_NEVER policy is
>>>                             used as the scroll bars are not displayed.
>>>
>>>                             Thanks and regards,
>>>                             Shashi
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180301/693ed3e4/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Thu Mar  1 21:28:34 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 1 Mar 2018 13:28:34 -0800
Subject: <AWT Dev> [11] JDK-8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <cd69a05c-c0b1-41eb-be21-9541c6dd07b9@default>
References: <b01398ea-f7c1-41a4-8845-20c0da99eccd@default>
 <eb824adb-920b-456e-bbed-a075a408ecd5@default>
 <d0bf586b-698e-21d6-c951-cbe53457a360@oracle.com>
 <cd69a05c-c0b1-41eb-be21-9541c6dd07b9@default>
Message-ID: <8099f4d5-6e61-5408-dcbe-2c6c748f8f34@oracle.com>

On 01/03/2018 02:41, Shashidhara Veerabhadraiah wrote:
> Sergey, we have a floating point dpi scale(dpi value/96) and we use it to scale down and up to convert from user space to device space and vice versa. This code is present at awt_Win32GraphicsDevice.cpp. In this code if you see we use clipRound() with ceil() function. Since there float to int involved with ceil operation may cause + or - 1 pixel variation in it's value I think. Please correct me if I am wrong here.

The similar code is executed when we set the size of the frame/window, 
we convert size in the user space to device space, and we do the 
opposite when we request the size of the frame. Same with robot API, 
when we move the mouse to some point and request the location of cursor.
We should try to implement mouse events in the similar way.

> Since there is an issue with windows 10 build 1703 and also the original fix is mac specific, I think my test fix to keep it specific to mac is the right decision to make. Please correct me if I am wrong here.
This test is not a mac specific, there is no any platforms specific code.


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Mar  1 21:48:43 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 1 Mar 2018 13:48:43 -0800
Subject: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated
 Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
 fails
In-Reply-To: <1d8a8bcb-f771-44c1-9c41-a7fcd74f2efd@default>
References: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>
 <5492eed4-9950-fa2a-2e69-1e2467aa71aa@oracle.com>
 <1d8a8bcb-f771-44c1-9c41-a7fcd74f2efd@default>
Message-ID: <a9aedc6e-bb97-a61e-6d3c-b33cff860fe2@oracle.com>

Hi, Prem.
On 26/02/2018 21:20, Prem Balakrishnan wrote:
> At times backFrame is rendered on top of frontFrame, due to which mouse position on backFrame is not NULL and test fails, solved this by adding waitForIdle() calls appropriately. Furthermore, mousemove from frontFrame to backFrame, caused the cursor to change to resize cursor and test fails, solved this by setting setResizable() to false.

But the old version of the test also call Util.waitForIdle(null) after 
frames were shown at line 55.


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Mar  1 21:53:52 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 1 Mar 2018 13:53:52 -0800
Subject: <AWT Dev> [11] Review request for 8198605: Touch keyboard is
 shown for a non-focusable text component
In-Reply-To: <6b137036-dcb8-6b58-0e4c-372a0141ecdd@oracle.com>
References: <6b137036-dcb8-6b58-0e4c-372a0141ecdd@oracle.com>
Message-ID: <9d4fede2-3eef-fd3a-6330-6ca0f5c69df4@oracle.com>

Hi, Anton.
Looks fine.

ps: maybe we can create some rfe to enable Touch keyboard even if the 
system has some keyboards for the test purpose?

On 01/03/2018 08:30, anton.litvinov at oracle.com wrote:
> Hello,
> 
> Could you please review the following fix for the bug.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198605
> Webrev: http://cr.openjdk.java.net/~alitvinov/8198605/jdk11/webrev.00
> 
> The fix extends a number of the required conditions in the method 
> "sun.awt.windows.WToolkit.showOrHideTouchKeyboard(Component, AWTEvent)", 
> which should be satisfied for showing of the touch keyboard, by checking 
> if the component is focusable or not.
> 
> Thank you,
> Anton


-- 
Best regards, Sergey.

From dmitry.markov at oracle.com  Thu Mar  1 22:04:34 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Thu, 1 Mar 2018 22:04:34 +0000
Subject: <AWT Dev> [11] Review request for 8198605: Touch keyboard is
 shown for a non-focusable text component
In-Reply-To: <6b137036-dcb8-6b58-0e4c-372a0141ecdd@oracle.com>
References: <6b137036-dcb8-6b58-0e4c-372a0141ecdd@oracle.com>
Message-ID: <42291074-16C1-4BCF-BE17-968CB4B80418@oracle.com>

Hi Anton,

The fix looks good, but I wonder if we also shall check results of isDisplayable() and isVisible() before showing touch keyboard. My assumption is the following: we cannot transfer focus to non-displayable or invisible components, so it is unnecessary to display touch keyboard for such components too.

Thanks,
Dmitry  

> On 1 Mar 2018, at 16:30, anton.litvinov at oracle.com wrote:
> 
> Hello,
> 
> Could you please review the following fix for the bug.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198605
> Webrev: http://cr.openjdk.java.net/~alitvinov/8198605/jdk11/webrev.00
> 
> The fix extends a number of the required conditions in the method "sun.awt.windows.WToolkit.showOrHideTouchKeyboard(Component, AWTEvent)", which should be satisfied for showing of the touch keyboard, by checking if the component is focusable or not.
> 
> Thank you,
> Anton


From erik.joelsson at oracle.com  Thu Mar  1 23:02:33 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 1 Mar 2018 15:02:33 -0800
Subject: <AWT Dev> RFR: JDK-8198844 Clean up GensrcX11Wrappers
In-Reply-To: <e656babe-e57c-a396-5b18-33ba3c9553c8@oracle.com>
References: <e656babe-e57c-a396-5b18-33ba3c9553c8@oracle.com>
Message-ID: <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com>

Hello,

In xlibtypes.txt comment, should it be sizes-64.txt?

Generating both 32 and 64 seems a bit outdated at this point. Surely 
this is a remnant of bundling 64 and 32 bit together on Solaris in the 
past? Perhaps someone in 2d can answer this? Would be nice to be able to 
clean up that part as well if possible.

Otherwise good.

/Erik

On 2018-02-28 12:12, Magnus Ihse Bursie wrote:
> My hunt on technical debt continues. This time my aim has been on the 
> sorry mess known as GensrcX11Wrappers.
>
> I've disentangled it into two functions, one simple gensrc part that 
> is actually run during the build, and which involves just a simple 
> java tool and some pre-calculated data files, and a separate step for 
> updating those pre-calculated data files. This step is now run using 
> "make update-x11wrappers". It involves compiling a native binary, and 
> running it on the target platform, so just as before, this assumes 
> that you are not cross-compiling.
>
> I'm not sure what role the "verification" step we had before ever 
> played. For all the years we've been "verifying" this, we've detected 
> no differences. In fact, as far as I understand, what we *really* 
> would need to verify against, is the X11 libraries on the runtime 
> system, i.e. where the users executes the JRE. But then again, we can 
> assume that this matches, just as anyone compiling with header files 
> on one place can assume that they can use the libraries elsewhere. The 
> only reason, as I see it, to keep the generation in the makefiles at 
> all, is to document how the files were generated, and to be ready for 
> the need to update the files if the list of datatypes in xlibtypes.txt 
> changes.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198844
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.01
>
> /Magnus
>


From prem.balakrishnan at oracle.com  Fri Mar  2 04:16:38 2018
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Thu, 1 Mar 2018 20:16:38 -0800 (PST)
Subject: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated
 Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
 fails
In-Reply-To: <a9aedc6e-bb97-a61e-6d3c-b33cff860fe2@oracle.com>
References: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>
 <5492eed4-9950-fa2a-2e69-1e2467aa71aa@oracle.com>
 <1d8a8bcb-f771-44c1-9c41-a7fcd74f2efd@default>
 <a9aedc6e-bb97-a61e-6d3c-b33cff860fe2@oracle.com>
Message-ID: <fc16bb43-8ccf-4628-beef-1b52f0d8f98d@default>

Hi Sergey,

The existing waitForIdle() call at line 55 is called after calling setVisible() for both the frames (which I have removed in proposed fix). I have added waitForIdle() call after calling setVisible() for each frame(at line 103 and 110 in proposed fix), which ensures frontFrame is rendered on top of backFrame.

Regards,
Prem

-----Original Message-----
From: Sergey Bylokhov 
Sent: Friday, March 02, 2018 3:19 AM
To: Prem Balakrishnan <prem.balakrishnan at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java' fails

Hi, Prem.
On 26/02/2018 21:20, Prem Balakrishnan wrote:
> At times backFrame is rendered on top of frontFrame, due to which mouse position on backFrame is not NULL and test fails, solved this by adding waitForIdle() calls appropriately. Furthermore, mousemove from frontFrame to backFrame, caused the cursor to change to resize cursor and test fails, solved this by setting setResizable() to false.

But the old version of the test also call Util.waitForIdle(null) after frames were shown at line 55.


-- 
Best regards, Sergey.

From prem.balakrishnan at oracle.com  Fri Mar  2 07:08:20 2018
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Thu, 1 Mar 2018 23:08:20 -0800 (PST)
Subject: <AWT Dev> [11]JDK-8160767 [TEST_BUG]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java
Message-ID: <b2c4248a-9587-4a15-926a-9f42d2c1f7c6@default>

Hi All,

 

Please Review fix for JDK 11: 

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8160767 

 

Webrev: http://cr.openjdk.java.net/~pkbalakr/8160767/webrev.00/

 

Test fails due to synchronization issue, state changes are validated immediately after calling setExtendedState(). 

Adding delay after setExtendedState() call and validating the state changes solves this issue.

 

Regards,

Prem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180301/c21fabff/attachment.html>

From magnus.ihse.bursie at oracle.com  Fri Mar  2 11:00:12 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 2 Mar 2018 12:00:12 +0100
Subject: <AWT Dev> RFR: JDK-8198844 Clean up GensrcX11Wrappers
In-Reply-To: <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com>
References: <e656babe-e57c-a396-5b18-33ba3c9553c8@oracle.com>
 <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com>
Message-ID: <d0444932-8b4b-fa96-c341-924ff2c0ad4f@oracle.com>

On 2018-03-02 00:02, Erik Joelsson wrote:
> Hello,
>
> In xlibtypes.txt comment, should it be sizes-64.txt?

Yes, good catch.

>
> Generating both 32 and 64 seems a bit outdated at this point. Surely 
> this is a remnant of bundling 64 and 32 bit together on Solaris in the 
> past? Perhaps someone in 2d can answer this? Would be nice to be able 
> to clean up that part as well if possible.
Yes, you are right. We should clean up that as well. I was just too 
conservative. I've now actually checked what happens when you generate 
both 32 and 64 bit versions, and the result is that instead of code like:
 ??? public static int getSize() { return 96; }
we get code like this:
 ??? public static int getSize() { return ((XlibWrapper.dataModel == 
32)?(80):(96)); }

Since we do no longer support multiple data models for the same build, 
this is just unnecessary. In fact, that leads to an even better cleanup, 
since we will always need just a single input file.

I also wrapped the tool calls in ExecuteWithLog.

Updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02

/Magnus


From erik.joelsson at oracle.com  Fri Mar  2 15:23:32 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 2 Mar 2018 07:23:32 -0800
Subject: <AWT Dev> RFR: JDK-8198844 Clean up GensrcX11Wrappers
In-Reply-To: <d0444932-8b4b-fa96-c341-924ff2c0ad4f@oracle.com>
References: <e656babe-e57c-a396-5b18-33ba3c9553c8@oracle.com>
 <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com>
 <d0444932-8b4b-fa96-c341-924ff2c0ad4f@oracle.com>
Message-ID: <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com>

Adding 2d-dev in the hopes of getting some input from component team. 
Seems like they should be aware of us removing the support for multiple 
data models.

Looks like you left a debug message at line 40 in GensrcX11Wrappers.gmk.

/Erik

On 2018-03-02 03:00, Magnus Ihse Bursie wrote:
> On 2018-03-02 00:02, Erik Joelsson wrote:
>> Hello,
>>
>> In xlibtypes.txt comment, should it be sizes-64.txt?
>
> Yes, good catch.
>
>>
>> Generating both 32 and 64 seems a bit outdated at this point. Surely 
>> this is a remnant of bundling 64 and 32 bit together on Solaris in 
>> the past? Perhaps someone in 2d can answer this? Would be nice to be 
>> able to clean up that part as well if possible.
> Yes, you are right. We should clean up that as well. I was just too 
> conservative. I've now actually checked what happens when you generate 
> both 32 and 64 bit versions, and the result is that instead of code like:
> ??? public static int getSize() { return 96; }
> we get code like this:
> ??? public static int getSize() { return ((XlibWrapper.dataModel == 
> 32)?(80):(96)); }
>
> Since we do no longer support multiple data models for the same build, 
> this is just unnecessary. In fact, that leads to an even better 
> cleanup, since we will always need just a single input file.
>
> I also wrapped the tool calls in ExecuteWithLog.
>
> Updated webrev:
> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 
>
>
> /Magnus
>


From anton.litvinov at oracle.com  Fri Mar  2 15:27:01 2018
From: anton.litvinov at oracle.com (anton.litvinov at oracle.com)
Date: Fri, 2 Mar 2018 15:27:01 +0000
Subject: <AWT Dev> [11] Review request for 8198605: Touch keyboard is
 shown for a non-focusable text component
In-Reply-To: <42291074-16C1-4BCF-BE17-968CB4B80418@oracle.com>
References: <6b137036-dcb8-6b58-0e4c-372a0141ecdd@oracle.com>
 <42291074-16C1-4BCF-BE17-968CB4B80418@oracle.com>
Message-ID: <b4cd49aa-27b1-2532-eb9e-9f96a1b62289@oracle.com>

Hello Dmitry,

Thank you for review and partial approval of this fix. I think that 
there is no need to add checks for "Component.isDisplayable()", 
"Component.isVisible()" in this method, because:

1.? Practical test shows, that for enabled, editable, focusable but not 
visible text components the touch keyboard is not shown in JDK with the 
fix for the bug JDK-8166772.
2.? Showing of the touch keyboard implemented by the fix for JDK-8166772 
occurs as a result of handling "java.awt.event.MouseEvent" events on 
Java code level and not of handling "java.awt.event.FocusEvent". The 
events of type "MouseEvent" are not dispatched to not visible 
"java.awt.Component" instances according to the following code from the 
method "java.awt.Container.getMouseEventTargetImpl(int, int, boolean, 
EventTargetFilter, boolean, boolean"

 ??? Component comp = component.get(i);
 ??? if (comp != null && comp.visible &&

3.? I do not see, how the end user may touch or click enabled, editable, 
focusable, but not displayable text component. I do not think that there 
is need to cover such a case, unless a test case demonstrating showing 
of the touch keyboard for not displayable text component exists.

Will you approve this fix?

Thank you,
Anton

On 01/03/2018 22:04, Dmitry Markov wrote:
> Hi Anton,
>
> The fix looks good, but I wonder if we also shall check results of isDisplayable() and isVisible() before showing touch keyboard. My assumption is the following: we cannot transfer focus to non-displayable or invisible components, so it is unnecessary to display touch keyboard for such components too.
>
> Thanks,
> Dmitry
>
>> On 1 Mar 2018, at 16:30, anton.litvinov at oracle.com wrote:
>>
>> Hello,
>>
>> Could you please review the following fix for the bug.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198605
>> Webrev: http://cr.openjdk.java.net/~alitvinov/8198605/jdk11/webrev.00
>>
>> The fix extends a number of the required conditions in the method "sun.awt.windows.WToolkit.showOrHideTouchKeyboard(Component, AWTEvent)", which should be satisfied for showing of the touch keyboard, by checking if the component is focusable or not.
>>
>> Thank you,
>> Anton


From dmitry.markov at oracle.com  Fri Mar  2 15:39:49 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Fri, 2 Mar 2018 15:39:49 +0000
Subject: <AWT Dev> [11] Review request for 8198605: Touch keyboard is
 shown for a non-focusable text component
In-Reply-To: <b4cd49aa-27b1-2532-eb9e-9f96a1b62289@oracle.com>
References: <6b137036-dcb8-6b58-0e4c-372a0141ecdd@oracle.com>
 <42291074-16C1-4BCF-BE17-968CB4B80418@oracle.com>
 <b4cd49aa-27b1-2532-eb9e-9f96a1b62289@oracle.com>
Message-ID: <C275F693-0E8D-4139-8584-238B256BD7D8@oracle.com>

Hi Anton,

Thank you for the clarification. The fix looks good to me.

Thanks,
Dmitry 

> On 2 Mar 2018, at 15:27, anton.litvinov at oracle.com wrote:
> 
> Hello Dmitry,
> 
> Thank you for review and partial approval of this fix. I think that there is no need to add checks for "Component.isDisplayable()", "Component.isVisible()" in this method, because:
> 
> 1.  Practical test shows, that for enabled, editable, focusable but not visible text components the touch keyboard is not shown in JDK with the fix for the bug JDK-8166772.
> 2.  Showing of the touch keyboard implemented by the fix for JDK-8166772 occurs as a result of handling "java.awt.event.MouseEvent" events on Java code level and not of handling "java.awt.event.FocusEvent". The events of type "MouseEvent" are not dispatched to not visible "java.awt.Component" instances according to the following code from the method "java.awt.Container.getMouseEventTargetImpl(int, int, boolean, EventTargetFilter, boolean, boolean"
> 
>     Component comp = component.get(i);
>     if (comp != null && comp.visible &&
> 
> 3.  I do not see, how the end user may touch or click enabled, editable, focusable, but not displayable text component. I do not think that there is need to cover such a case, unless a test case demonstrating showing of the touch keyboard for not displayable text component exists.
> 
> Will you approve this fix?
> 
> Thank you,
> Anton
> 
> On 01/03/2018 22:04, Dmitry Markov wrote:
>> Hi Anton,
>> 
>> The fix looks good, but I wonder if we also shall check results of isDisplayable() and isVisible() before showing touch keyboard. My assumption is the following: we cannot transfer focus to non-displayable or invisible components, so it is unnecessary to display touch keyboard for such components too.
>> 
>> Thanks,
>> Dmitry
>> 
>>> On 1 Mar 2018, at 16:30, anton.litvinov at oracle.com wrote:
>>> 
>>> Hello,
>>> 
>>> Could you please review the following fix for the bug.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198605
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8198605/jdk11/webrev.00
>>> 
>>> The fix extends a number of the required conditions in the method "sun.awt.windows.WToolkit.showOrHideTouchKeyboard(Component, AWTEvent)", which should be satisfied for showing of the touch keyboard, by checking if the component is focusable or not.
>>> 
>>> Thank you,
>>> Anton
> 


From anton.litvinov at oracle.com  Fri Mar  2 17:00:33 2018
From: anton.litvinov at oracle.com (anton.litvinov at oracle.com)
Date: Fri, 2 Mar 2018 17:00:33 +0000
Subject: <AWT Dev> [11] Review request for 8198605: Touch keyboard is
 shown for a non-focusable text component
In-Reply-To: <9d4fede2-3eef-fd3a-6330-6ca0f5c69df4@oracle.com>
References: <6b137036-dcb8-6b58-0e4c-372a0141ecdd@oracle.com>
 <9d4fede2-3eef-fd3a-6330-6ca0f5c69df4@oracle.com>
Message-ID: <34a2859c-0889-0edb-db82-383e4ca74311@oracle.com>

Hello Sergey,

Thank you for review and approval of this fix.

Do you mean such an RFE may be used for simplification of testing of 
this bug or all possible bugs connected with this new functionality, 
which allows to automatically show and hide the touch keyboard, on a PC 
without a touch screen?

The fix for the bug JDK-8166772 allows to display the touch keyboard on 
clicks from a regular physical mouse, but only for the case, when no 
physical keyboards are attached to the PC and the system setting

"Automatically show the touch keyboard in windowed apps when there's no 
keyboard attached to your device"

is turned on in MS Windows OS. Therefore technically it is possible to 
change the code of "Java_sun_awt_windows_WToolkit_showTouchKeyboard" 
function from the file 
"src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp" to 
check or not to check for presence of any attached keyboards depending 
on some new boolean flag, what will let to test this functionality 
without a touch screen just having a mouse and a physical keyboard. But 
implementation of such a flag, perhaps as a new Java system property, 
will require filing CSR request and describing this flag in the release 
notes. Also testing the functionality related to the touch keyboard 
without a touch screen is testing of not the main use case.

I am ready to create such an RFE and to work on it, if it will be 
beneficial for testing and development purposes, but if a person, who 
tests the functionality and the developer working on the issue has a 
device with a touch screen, then such possible property will simplify 
testing of the functionality only for the narrow case in which a user 
has MS Window 8 OS or later, does not have a touch screen, cannot detach 
the keyboard, since it is part of a laptop, and still wants to use the 
touch keyboard using the regular mouse.

Thank you,
Anton

On 01/03/2018 21:53, Sergey Bylokhov wrote:
> Hi, Anton.
> Looks fine.
>
> ps: maybe we can create some rfe to enable Touch keyboard even if the 
> system has some keyboards for the test purpose?
>
> On 01/03/2018 08:30, anton.litvinov at oracle.com wrote:
>> Hello,
>>
>> Could you please review the following fix for the bug.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198605
>> Webrev: http://cr.openjdk.java.net/~alitvinov/8198605/jdk11/webrev.00
>>
>> The fix extends a number of the required conditions in the method 
>> "sun.awt.windows.WToolkit.showOrHideTouchKeyboard(Component, 
>> AWTEvent)", which should be satisfied for showing of the touch 
>> keyboard, by checking if the component is focusable or not.
>>
>> Thank you,
>> Anton
>
>


From semyon.sadetsky at oracle.com  Fri Mar  2 17:02:19 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 2 Mar 2018 09:02:19 -0800
Subject: <AWT Dev> [11]JDK-8160767 [TEST_BUG]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java
In-Reply-To: <b2c4248a-9587-4a15-926a-9f42d2c1f7c6@default>
References: <b2c4248a-9587-4a15-926a-9f42d2c1f7c6@default>
Message-ID: <3792fda2-1162-4834-c04d-2a7b15a2075a@oracle.com>

Hi Prem,

Did you run it on all platforms? There may be an animation when window 
is iconified or maximized which takes more than 100ms.

--Semyon


On 03/01/2018 11:08 PM, Prem Balakrishnan wrote:
>
> Hi All,
>
> Please Review fix for JDK 11:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8160767
>
> Webrev: http://cr.openjdk.java.net/~pkbalakr/8160767/webrev.00/
>
> Test fails due to synchronization issue, state changes are validated 
> immediately after calling setExtendedState().
>
> Adding delay after setExtendedState() call and validating the state 
> changes solves this issue.
>
> Regards,
>
> Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180302/acc18220/attachment-0001.html>

From prem.balakrishnan at oracle.com  Sat Mar  3 10:54:55 2018
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Sat, 3 Mar 2018 02:54:55 -0800 (PST)
Subject: <AWT Dev> [11]JDK-8160767 [TEST_BUG]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java
In-Reply-To: <3792fda2-1162-4834-c04d-2a7b15a2075a@oracle.com>
References: <b2c4248a-9587-4a15-926a-9f42d2c1f7c6@default>
 <3792fda2-1162-4834-c04d-2a7b15a2075a@oracle.com>
Message-ID: <921fb760-02fb-4681-94b0-78e999dca394@default>

Hi Semyon,

 

Yes, I have tested it on macOS, Windows 7, 10 and Ubuntu 16.04, 17.10.

 

Regards,

Prem

 

From: Semyon Sadetsky 
Sent: Friday, March 02, 2018 10:32 PM
To: Prem Balakrishnan <prem.balakrishnan at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11]JDK-8160767 [TEST_BUG] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java

 

Hi Prem,

Did you run it on all platforms? There may be an animation when window is iconified or maximized which takes more than 100ms.

--Semyon

 

On 03/01/2018 11:08 PM, Prem Balakrishnan wrote:

Hi All,

 

Please Review fix for JDK 11: 

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8160767 

 

Webrev: http://cr.openjdk.java.net/~pkbalakr/8160767/webrev.00/

 

Test fails due to synchronization issue, state changes are validated immediately after calling setExtendedState(). 

Adding delay after setExtendedState() call and validating the state changes solves this issue.

 

Regards,

Prem

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180303/a78f7367/attachment.html>

From philip.race at oracle.com  Sat Mar  3 17:25:21 2018
From: philip.race at oracle.com (Philip Race)
Date: Sat, 03 Mar 2018 09:25:21 -0800
Subject: <AWT Dev> [11]JDK-8160767 [TEST_BUG]
	java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java
In-Reply-To: <921fb760-02fb-4681-94b0-78e999dca394@default>
References: <b2c4248a-9587-4a15-926a-9f42d2c1f7c6@default>
 <3792fda2-1162-4834-c04d-2a7b15a2075a@oracle.com>
 <921fb760-02fb-4681-94b0-78e999dca394@default>
Message-ID: <5A9ADA81.7030008@oracle.com>

+1 from me.

-phil.

On 3/3/18, 2:54 AM, Prem Balakrishnan wrote:
>
> Hi Semyon,
>
> Yes, I have tested it on macOS, Windows 7, 10 and Ubuntu 16.04, 17.10.
>
> Regards,
>
> Prem
>
> *From:*Semyon Sadetsky
> *Sent:* Friday, March 02, 2018 10:32 PM
> *To:* Prem Balakrishnan <prem.balakrishnan at oracle.com>; 
> awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [11]JDK-8160767 [TEST_BUG] 
> java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java
>
> Hi Prem,
>
> Did you run it on all platforms? There may be an animation when window 
> is iconified or maximized which takes more than 100ms.
>
> --Semyon
>
> On 03/01/2018 11:08 PM, Prem Balakrishnan wrote:
>
>     Hi All,
>
>     Please Review fix for JDK 11:
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8160767
>
>     Webrev: http://cr.openjdk.java.net/~pkbalakr/8160767/webrev.00/
>     <http://cr.openjdk.java.net/%7Epkbalakr/8160767/webrev.00/>
>
>     Test fails due to synchronization issue, state changes are
>     validated immediately after calling setExtendedState().
>
>     Adding delay after setExtendedState() call and validating the
>     state changes solves this issue.
>
>     Regards,
>
>     Prem
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180303/0a2a5699/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Mar  5 14:49:42 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 5 Mar 2018 06:49:42 -0800
Subject: <AWT Dev> [11] Review request for 8198605: Touch keyboard is
 shown for a non-focusable text component
In-Reply-To: <34a2859c-0889-0edb-db82-383e4ca74311@oracle.com>
References: <6b137036-dcb8-6b58-0e4c-372a0141ecdd@oracle.com>
 <9d4fede2-3eef-fd3a-6330-6ca0f5c69df4@oracle.com>
 <34a2859c-0889-0edb-db82-383e4ca74311@oracle.com>
Message-ID: <a663ecfa-5528-6ce8-5d33-a1c8f0f5e711@oracle.com>

On 02/03/2018 09:00, anton.litvinov at oracle.com wrote:
> Do you mean such an RFE may be used for simplification of testing of 
> this bug or all possible bugs connected with this new functionality, 
> which allows to automatically show and hide the touch keyboard, on a PC 
> without a touch screen?

Yes, it is not necessary should be a "public" property, just a way to 
reproduce and verify the bugs.

> 
> The fix for the bug JDK-8166772 allows to display the touch keyboard on 
> clicks from a regular physical mouse, but only for the case, when no 
> physical keyboards are attached to the PC and the system setting
> 
> "Automatically show the touch keyboard in windowed apps when there's no 
> keyboard attached to your device"
> 
> is turned on in MS Windows OS. Therefore technically it is possible to 
> change the code of "Java_sun_awt_windows_WToolkit_showTouchKeyboard" 
> function from the file 
> "src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp" to 
> check or not to check for presence of any attached keyboards depending 
> on some new boolean flag, what will let to test this functionality 
> without a touch screen just having a mouse and a physical keyboard. But 
> implementation of such a flag, perhaps as a new Java system property, 
> will require filing CSR request and describing this flag in the release 
> notes. Also testing the functionality related to the touch keyboard 
> without a touch screen is testing of not the main use case.
> 
> I am ready to create such an RFE and to work on it, if it will be 
> beneficial for testing and development purposes, but if a person, who 
> tests the functionality and the developer working on the issue has a 
> device with a touch screen, then such possible property will simplify 
> testing of the functionality only for the narrow case in which a user 
> has MS Window 8 OS or later, does not have a touch screen, cannot detach 
> the keyboard, since it is part of a laptop, and still wants to use the 
> touch keyboard using the regular mouse.
> 
> Thank you,
> Anton
> 
> On 01/03/2018 21:53, Sergey Bylokhov wrote:
>> Hi, Anton.
>> Looks fine.
>>
>> ps: maybe we can create some rfe to enable Touch keyboard even if the 
>> system has some keyboards for the test purpose?
>>
>> On 01/03/2018 08:30, anton.litvinov at oracle.com wrote:
>>> Hello,
>>>
>>> Could you please review the following fix for the bug.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198605
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8198605/jdk11/webrev.00
>>>
>>> The fix extends a number of the required conditions in the method 
>>> "sun.awt.windows.WToolkit.showOrHideTouchKeyboard(Component, 
>>> AWTEvent)", which should be satisfied for showing of the touch 
>>> keyboard, by checking if the component is focusable or not.
>>>
>>> Thank you,
>>> Anton
>>
>>
> 


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Mon Mar  5 16:32:29 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 5 Mar 2018 08:32:29 -0800
Subject: <AWT Dev> [11]JDK-8160767 [TEST_BUG]
 java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java
In-Reply-To: <921fb760-02fb-4681-94b0-78e999dca394@default>
References: <b2c4248a-9587-4a15-926a-9f42d2c1f7c6@default>
 <3792fda2-1162-4834-c04d-2a7b15a2075a@oracle.com>
 <921fb760-02fb-4681-94b0-78e999dca394@default>
Message-ID: <12de5fac-da18-189c-b62a-8b3eb1da4d39@oracle.com>

+1

--Semyon


On 03/03/2018 02:54 AM, Prem Balakrishnan wrote:
>
> Hi Semyon,
>
> Yes, I have tested it on macOS, Windows 7, 10 and Ubuntu 16.04, 17.10.
>
> Regards,
>
> Prem
>
> *From:*Semyon Sadetsky
> *Sent:* Friday, March 02, 2018 10:32 PM
> *To:* Prem Balakrishnan <prem.balakrishnan at oracle.com>; 
> awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [11]JDK-8160767 [TEST_BUG] 
> java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java
>
> Hi Prem,
>
> Did you run it on all platforms? There may be an animation when window 
> is iconified or maximized which takes more than 100ms.
>
> --Semyon
>
> On 03/01/2018 11:08 PM, Prem Balakrishnan wrote:
>
>     Hi All,
>
>     Please Review fix for JDK 11:
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8160767
>
>     Webrev: http://cr.openjdk.java.net/~pkbalakr/8160767/webrev.00/
>     <http://cr.openjdk.java.net/%7Epkbalakr/8160767/webrev.00/>
>
>     Test fails due to synchronization issue, state changes are
>     validated immediately after calling setExtendedState().
>
>     Adding delay after setExtendedState() call and validating the
>     state changes solves this issue.
>
>     Regards,
>
>     Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180305/8fa2db77/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Mar  5 16:56:34 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 5 Mar 2018 08:56:34 -0800
Subject: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated
 Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
 fails
In-Reply-To: <fc16bb43-8ccf-4628-beef-1b52f0d8f98d@default>
References: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>
 <5492eed4-9950-fa2a-2e69-1e2467aa71aa@oracle.com>
 <1d8a8bcb-f771-44c1-9c41-a7fcd74f2efd@default>
 <a9aedc6e-bb97-a61e-6d3c-b33cff860fe2@oracle.com>
 <fc16bb43-8ccf-4628-beef-1b52f0d8f98d@default>
Message-ID: <f4ed24b7-6792-b48b-a380-111e0f815182@oracle.com>

On 01/03/2018 20:16, Prem Balakrishnan wrote:
> The existing waitForIdle() call at line 55 is called after calling setVisible() for both the frames (which I have removed in proposed fix). I have added waitForIdle() call after calling setVisible() for each frame(at line 103 and 110 in proposed fix), which ensures frontFrame is rendered on top of backFrame.

I doubt that this will fix the problem - it will decrease the 
possibility of such behavior.
Please add toBack()/toFront calls for these frames to make a correct order.

> 
> Regards,
> Prem
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Friday, March 02, 2018 3:19 AM
> To: Prem Balakrishnan <prem.balakrishnan at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java' fails
> 
> Hi, Prem.
> On 26/02/2018 21:20, Prem Balakrishnan wrote:
>> At times backFrame is rendered on top of frontFrame, due to which mouse position on backFrame is not NULL and test fails, solved this by adding waitForIdle() calls appropriately. Furthermore, mousemove from frontFrame to backFrame, caused the cursor to change to resize cursor and test fails, solved this by setting setResizable() to false.
> 
> But the old version of the test also call Util.waitForIdle(null) after frames were shown at line 55.
> 
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Mar  5 18:06:26 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 5 Mar 2018 10:06:26 -0800
Subject: <AWT Dev> <AWT dev>[11] Review request for JDK-8190767: [macos]
 if JFrame is maximized on OS X, all new JFrames will be maximized by default
In-Reply-To: <059B7314-C03E-49A7-A6BA-6D27207DB2D3@oracle.com>
References: <DB89D6AD-022D-4A42-BB27-643C79B9176A@oracle.com>
 <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
 <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>
 <ab1bdb7e-2be6-1d57-f7d1-0a8b13a1e4ba@oracle.com>
 <CD0F2B6C-5300-41DD-AED3-15D413D01429@oracle.com>
 <5A870469.9070006@oracle.com>
 <ECF1EC5B-A1AB-46CB-AC02-53923A8EEB3F@oracle.com>
 <059B7314-C03E-49A7-A6BA-6D27207DB2D3@oracle.com>
Message-ID: <46dd1caf-8827-43fc-37b3-761c396d34dd@oracle.com>

Hi, Manajit.
On 26/02/2018 05:45, Manajit Halder wrote:
> Changed the fix as per Sergey?s review comment. Now both Frame and 
> Dialog are checked for resizibility before setting canFullScreen to true.
> Please review the modified webrev:
> http://cr.openjdk.java.net/~mhalder/8190767/webrev.03/

There are small issues in the test;
  - The Swing components should be created/accessed on EDT(see 
constructor of AllFramesMaximize and dispose)
  - @test 8190767, I guess @bug tag missed.

Also I found another bug by this testcase:
  - Change the of the window from JFrame to JDialog at line 103
  - Run the test.
  - Click on the JButton which will open JDialog
  - Click maximize on the JFrame
  - Click on the JButton which will open JDialog again
  - Two dialogs will try to get a focus in an endless loop, by switching 
between the spaces.

Please file a CR for this.

> 
> Thanks,
> Manajit
> 
> 
>> On 17-Feb-2018, at 8:03 AM, Manajit Halder <manajit.halder at oracle.com 
>> <mailto:manajit.halder at oracle.com>> wrote:
>>
>> Correcting the subject to indicate that the fix is for JDK 11.
>>
>> Regard,
>> Manajit
>>
>>> On 16-Feb-2018, at 9:48 PM, Kevin Rushforth 
>>> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>>>
>>> Perhaps the subject should be changed to indicate that the fix is for 
>>> JDK 11 (not JDK 10 for which it is way too late)...
>>>
>>> -- Kevin
>>>
>>>
>>> Manajit Halder wrote:
>>>> Hi Sergey,
>>>>
>>>> Please review the modified fix. The current webrev maintains the 
>>>> window behaviour after it is shown as per the current implementation.
>>>> canFullScreen is set true in case the window is resizable.
>>>>
>>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.02/ 
>>>> <http://cr.openjdk.java.net/%7Emhalder/8190767/webrev.02/>
>>>>
>>>> Regards,
>>>> Manajit
>>>>
>>>>> On 14-Feb-2018, at 8:29 AM, Sergey Bylokhov 
>>>>> <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> wrote:
>>>>>
>>>>> Hi, Manajit.>http://cr.openjdk.java.net/~mhalder/8190767/webrev.01/ 
>>>>> <http://cr.openjdk.java.net/%7Emhalder/8190767/webrev.01/>
>>>>> After the window is shown behavior should be the same as in current 
>>>>> implementation(resizable windows should have canFullScreen=true, 
>>>>> others canFullScreen=false) so you cannot just set it to "true" or 
>>>>> "false".
>>>>>
>>>>>> The issue is not reproducible in jdk8. >
>>>>>> Regards,
>>>>>> Manajit
>>>>>>>
>>>>>>> On 31-Jan-2018, at 2:40 AM, Sergey Bylokhov 
>>>>>>> <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com> 
>>>>>>> <mailto:sergey.bylokhov at oracle.com>> wrote:
>>>>>>>
>>>>>>> Hi, Manajit.
>>>>>>> Did you check that it works properly in jdk8?
>>>>>>>
>>>>>>> I guess we need to set "WINDOW_FULLSCREENABLE" after we show the 
>>>>>>> window for the first time, with one exception if the window is 
>>>>>>> MAXIMIZED_BOTH.
>>>>>>>
>>>>>>> On 29/01/2018 04:39, Manajit Halder wrote:
>>>>>>>> Hi All,
>>>>>>>> Kindly review the fix for JDK10.
>>>>>>>> Bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190767
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.00/
>>>>>>>> Problem:
>>>>>>>> In this problem two unrelated windows are created (first window 
>>>>>>>> and second window). If the second window is created when the 
>>>>>>>> first window is in fullscreen then the second window will 
>>>>>>>> automatically be created in fullscreen mode. This is the default 
>>>>>>>> behaviour with Cocoa windows. The second window receives 
>>>>>>>> windowWillEnterFullScreen notification when the first window is 
>>>>>>>> in fullscreen. windowWillEnterFullScreen notification is system 
>>>>>>>> generated notification and there is no way to prevent it.
>>>>>>>> Above conclusion was made after debugging the issue to find out 
>>>>>>>> if there is any way to prevent the windowWillEnterFullScreen 
>>>>>>>> notification and also to find out if it generated due to some 
>>>>>>>> existing java (generic and native) code.
>>>>>>>> I wrote a simple Mac OS X application with 2 windows and 
>>>>>>>> observed the same behaviour. The second window is created in 
>>>>>>>> fullscreen mode if it is created when the first window is in 
>>>>>>>> fullscreen. Whereas the second window is displayed normal if the 
>>>>>>>> first window is in normal mode (not in fullscreen mode). The 
>>>>>>>> only way found to prevent the second window going to fullscreen 
>>>>>>>> is don?t set this behaviour for the second window.
>>>>>>>> Fix:
>>>>>>>> The behaviour is normal on Mac OS. But if we want to prevent the 
>>>>>>>> second (all windows except the primary window) window to 
>>>>>>>> automatically created in fullscreen mode then the following fix 
>>>>>>>> can be applicable.
>>>>>>>> By default all the Frames are set the WINDOW_FULLSCREENABLE 
>>>>>>>> property and by default all frames receives fullscreen event if 
>>>>>>>> the first frame is in fullscreen when it is created. Due to this 
>>>>>>>> setting the second frame which is created on button click goes 
>>>>>>>> to fullscreen on creation automatically. Mac OS fullscreen event 
>>>>>>>> notifications are received in case the first frame is in 
>>>>>>>> fullscreen and WINDOW_FULLSCREENABLE set for the second frame.
>>>>>>>> Only the first frame should have the WINDOW_FULLSCREENABLE 
>>>>>>>> property set. The frames created in this case were ownerless 
>>>>>>>> windows as mentioned earlier. Therefore it is not possible to 
>>>>>>>> find out the owner of the current frame, it is null for all the 
>>>>>>>> frames created. Hence the fix is if the current frame is the 
>>>>>>>> first frame then set the property otherwise don?t set the 
>>>>>>>> property WINDOW_FULLSCREENABLE.
>>>>>>>> Regards,
>>>>>>>> Manajit
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards, Sergey.
>>>>>
>>>>>
>>>>> --
>>>>> Best regards, Sergey.
>>>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Mar  5 18:34:22 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 5 Mar 2018 10:34:22 -0800
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
 <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
 <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>
 <4396fac6-4870-aad9-6e5f-c4b5e274c423@oracle.com>
 <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>
Message-ID: <b4d4f75a-f9d3-e2c7-ba79-4c62cdb14bde@oracle.com>

Hi, Shashi.
Can you confirm that the bug6404832 is not reproducible after this 
change(since part of it fix is dropped)?

Please use some meaningful name for the test + small typo in the 
test(poistion) please fix both before the push.

On 27/02/2018 00:45, Shashidhara Veerabhadraiah wrote:
> Hi Semyon, Thanks for your help. I did some debugging from that 
> perspective and could find the problem and the solution. Here is the new 
> webrev, please review it:
> 
> http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/
> 
> The problem was that in the case of SCROLLBARS_NEVER, scroll bar info 
> was set using setScrollInfo() with SIF_RANGE with ranges being (0, 0). 
> This forced the windows to pick a default value and hence reset it to 
> that value every time. Now the logic is modified in a very similar 
> fashion as the other scroll bar display modes but without displaying it 
> using the new win api ShowScrollBar(). The scroll bar info is supplied 
> with a proper range per the corresponding base component but without the 
> scroll bar pane size(as we don?t display it). This should suffice a good 
> range for the scroll bars to operate and correct itself if there is any 
> out of range value is supplied.
> 
> Thanks and regards,
> Shashi
> 
> *From:*Semyon Sadetsky
> *Sent:* Tuesday, February 27, 2018 1:22 AM
> *To:* shashidhara veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
> *Cc:* awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane 
> is reset after calling validate()
> 
> The bug was failed against Windows platform. So, I'd try to find the 
> root cause why when the scroll is notified with the scrolled component 
> size the scroll position is set to the wrong value.
> 
> --Semyon
> 
> On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:
> 
>     I think I agree Semyon. Thanks for your detailed explanation.
> 
>     So how do we approach on this? I see a different behaviour on other
>     platforms. Shouldn?t we have a common behaviour across platforms? I
>     agree with your analysis and hence should we change the behaviour on
>     other platforms so that all of them will have the same behaviour?
> 
>     Thanks and regards,
> 
>     Shashi
> 
>         On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky
>         <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>>
>         wrote:
> 
>         On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:
> 
>             Hi Semyon, Thanks for your review and these questions help
>             us to reach the right requirements.
> 
>             Without this change, there is different behavior on windows
>             compared to Mac/Linux platforms. Hence this change is
>             required to make the behavior same across the platforms.
>             Since the scroll pane control is not displayed for the
>             SCROLLBARS_NEVER case and if not in the setScrollPosition()
>             then how can the user can move to a different position?
>             Since we used to update/recalculate the scroll pane geometry
>             caused changes to move to a different position other than
>             the setScrollPosition()!! This causes SCROLLBARS_NEVER mode
>             as unusable as the user is unable to control the scrolling
>             movement because neither he can set one setScrollPosition()
>             nor the control is displayed to explicitly set the movement.
>             Hope this answers your question.
> 
>         You need to think once again about two facts I brought in my
>         previous message.
> 
>         1. User still may scroll using mouse wheel even when scrollbars
>         are not visible.
> 
>         2. Visibility of scrollbars doesn't affect the requirement to
>         notify the scroll about the scrolled component size changes. If
>         the scrolled component was 500x500 in size and its position in
>         the 200x200 viewport was (300,300) after the size of the
>         component is changed to 300x300 it may not be shown at the same
>         position because the previously visible component area doesn't
>         exist anymore and the scroll should be moved to (100,100). This
>         should work in the same way regardless the selected scrlollbar
>         visibility policy.
> 
>         --Semyon
> 
> 
>             Thanks and regards,
>             Shashi
> 
>             *From:*Semyon Sadetsky
>             *Sent:*Saturday, February 24, 2018 2:12 AM
>             *To:*Shashidhara
>             Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>             <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>             <mailto:awt-dev at openjdk.java.net>
>             *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>             ScrollPane is reset after calling validate()
> 
>             On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:
> 
>                 Hi Semyon, Whenever the container is resized we used to
>                 update the scroll pane sizes/geometry regardless of the
>                 scroll bar display policies. This resizing make sense
>                 for the non SCROLLBARS_NEVER cases as the scroll pane is
>                 displayed or needed an update. This additional update
>                 posed issues for the SCROLLBARS_NEVER case where we are
>                 not supposed to display the scroll pane per the java
>                 doc, then why update?
> 
>                 Scroll pane geometry gets updated in 2 ways, one thro?
>                 setScrollPosition() and childResized(). So I derived the
>                 conclusion based on the javadoc information that since
>                 we don?t display the scroll pane there is no need to
>                 update the scroll pane geometry based on the
>                 childResized() as it was altering the position already
>                 set by the setScrollPosition(). This behavior is same as
>                 the other non SCROLLBARS_NEVER mode and setting the
>                 scroll bar display to SCROLLBARS_NEVER didn?t made any
>                 difference.
> 
>             The only difference of SCROLLBARS_NEVER from others I got
>             from javadoc is that the scroll bar controls are hidden. So
>             the scrolling itself happens in the same way as in the case
>             of visible scroll bars but it can be only controlled by
>             mouse wheel or programmatically. In my understanding this
>             means that the notification about the scrolled component
>             size changes should happen in the same way as for all other
>             cases. I see no reason for the differentiation that your fix
>             introduces. What will happen if to remove this notification
>             for visible scroll bars modes?
> 
>             --Semyon
> 
> 
>                 Thanks and regards,
>                 Shashi
> 
>                 *From:*Semyon Sadetsky
>                 *Sent:*Friday, February 23, 2018 10:17 PM
>                 *To:*Shashidhara
>                 Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>                 <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>                 <mailto:awt-dev at openjdk.java.net>
>                 *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>                 poistion in ScrollPane is reset after calling validate()
> 
>                 On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:
> 
>                     Hi Semyon, Thanks for your review comments.
> 
>                     Here are those different scroll bar pane modes and
>                     their description:
> 
>                     *Modifier and Type*
> 
>                     	
> 
>                     *Field*
> 
>                     	
> 
>                     *Description*
> 
>                     |static int|
> 
>                     	
> 
>                     *SCROLLBARS_ALWAYS
>                     <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS>*
> 
>                     	
> 
>                     Specifies that horizontal/vertical scrollbars should
>                     always be shown regardless of the respective sizes
>                     of the scrollpane and child.
> 
>                     |static int|
> 
>                     	
> 
>                     *SCROLLBARS_AS_NEEDED
>                     <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED>*
> 
>                     	
> 
>                     Specifies that horizontal/vertical scrollbar should
>                     be shown only when the size of the child exceeds the
>                     size of the scrollpane in the horizontal/vertical
>                     dimension.
> 
>                     |static int|
> 
>                     	
> 
>                     *SCROLLBARS_NEVER
>                     <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER>*
> 
>                     	
> 
>                     Specifies that horizontal/vertical scrollbars should
>                     never be shown regardless of the respective sizes of
>                     the scrollpane and child.
> 
>                 This javadoc, you've copy-pasted here, doesn't explain
>                 why in your fix the notification about changed child
>                 size is disabled for SCROLLBARS_NEVER case.
> 
>                     Thanks and regards,
>                     Shashi
> 
>                     *From:*Semyon Sadetsky
>                     *Sent:*Thursday, February 22, 2018 11:58 PM
>                     *To:*Shashidhara
>                     Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com> <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>                     <mailto:awt-dev at openjdk.java.net>
>                     *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>                     poistion in ScrollPane is reset after calling validate()
> 
>                     Hi Shashi,
> 
>                     Can you clarify what is the principal difference
>                     between SCROLLBARS_NEVER and other scroll policies
>                     that requires to avoid updating the scroll geometry
>                     according to the inner component size?
> 
>                     --Semyon
> 
>                     On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah
>                     wrote:
> 
>                         Hi All, Please review a code fix for the below bug.
> 
>                         Bug:https://bugs.openjdk.java.net/browse/JDK-8195738
> 
>                         Webrev:http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
>                         <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
> 
>                         Problematic platform: Windows only.
> 
>                         Summary: This bug occurs only on windows
>                         platform and whereas the behavior is different
>                         on Mac/Linux platforms. Now after this fix there
>                         is common behavior across the platforms.
> 
>                         The main problem was with resetting the state of
>                         the scroll bars even though the scroll bar panes
>                         are spawned with SCROLLBARS_NEVER as the scroll
>                         bar display policy. This resetting should not
>                         occur as the scroll bar display policy makes the
> 
>                         scroll bar panes invisible. Hence except the
>                         setScrollPosition() calls, we don?t need to
>                         resize/update the scroll bars state upon calling
>                         the scroll bars validation if SCROLLBARS_NEVER
>                         policy is used as the scroll bars are not displayed.
> 
>                         Thanks and regards,
>                         Shashi
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Mon Mar  5 22:38:18 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 5 Mar 2018 14:38:18 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up
	GensrcX11Wrappers
In-Reply-To: <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com>
References: <e656babe-e57c-a396-5b18-33ba3c9553c8@oracle.com>
 <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com>
 <d0444932-8b4b-fa96-c341-924ff2c0ad4f@oracle.com>
 <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com>
Message-ID: <3d245e02-3af5-fc56-4c09-12eca73574e2@oracle.com>

 >I'm not sure what role the "verification" step we had before ever played.
 >For all the years we've been "verifying" this, we've detected no 
differences.

I think this is useful in the event that you make some changes and
regenerate the 64 bit sizes but not 32 bit.

For example this old bug similarly reported a breakage on Solaris ..
https://bugs.openjdk.java.net/browse/JDK-6804680

... back in the day when we only had that checked in and the ones used 
for Linux
were being generated on the fly. My reading of the history here is 
sizes.32 and sizes.64
were added to support cross-compilation, and the verification step meant 
that  all
architectures would get checked in some build or other.

We care less about 32 bit now .. and even the cross-compilation .. so  
arguably
we could go back to always generating the files, as was the case for 
Linux before
https://bugs.openjdk.java.net/browse/JDK-8004151

But if we say we still want to keep around the possibility of 32 bit 
support AND
cross-compilation, then the verification step still seems useful.

If we say we care only about 32 bit or do not care about cross 
compilation, then
why not get rid of the checked in file and calculate these every build ?

The clean up of removing the solaris specific seems like it could have been
done a long time ago .. I am not sure why was ever only this one case there.
I'd have to dig back a very long way.

I do agree we do not need to support 32 + 64 bit concurrently, that went
away when 64 bit solaris overlay on 32 bit was dropped.

-phil.

On 03/02/2018 07:23 AM, Erik Joelsson wrote:
> Adding 2d-dev in the hopes of getting some input from component team. 
> Seems like they should be aware of us removing the support for 
> multiple data models.
>
> Looks like you left a debug message at line 40 in GensrcX11Wrappers.gmk.
>
> /Erik
>
> On 2018-03-02 03:00, Magnus Ihse Bursie wrote:
>> On 2018-03-02 00:02, Erik Joelsson wrote:
>>> Hello,
>>>
>>> In xlibtypes.txt comment, should it be sizes-64.txt?
>>
>> Yes, good catch.
>>
>>>
>>> Generating both 32 and 64 seems a bit outdated at this point. Surely 
>>> this is a remnant of bundling 64 and 32 bit together on Solaris in 
>>> the past? Perhaps someone in 2d can answer this? Would be nice to be 
>>> able to clean up that part as well if possible.
>> Yes, you are right. We should clean up that as well. I was just too 
>> conservative. I've now actually checked what happens when you 
>> generate both 32 and 64 bit versions, and the result is that instead 
>> of code like:
>>     public static int getSize() { return 96; }
>> we get code like this:
>>     public static int getSize() { return ((XlibWrapper.dataModel == 
>> 32)?(80):(96)); }
>>
>> Since we do no longer support multiple data models for the same 
>> build, this is just unnecessary. In fact, that leads to an even 
>> better cleanup, since we will always need just a single input file.
>>
>> I also wrapped the tool calls in ExecuteWithLog.
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 
>>
>>
>> /Magnus
>>
>


From magnus.ihse.bursie at oracle.com  Mon Mar  5 23:30:49 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 6 Mar 2018 00:30:49 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up
	GensrcX11Wrappers
In-Reply-To: <3d245e02-3af5-fc56-4c09-12eca73574e2@oracle.com>
References: <e656babe-e57c-a396-5b18-33ba3c9553c8@oracle.com>
 <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com>
 <d0444932-8b4b-fa96-c341-924ff2c0ad4f@oracle.com>
 <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com>
 <3d245e02-3af5-fc56-4c09-12eca73574e2@oracle.com>
Message-ID: <c1af2076-970f-7058-48c3-72bb0a261c14@oracle.com>


On 2018-03-05 23:38, Phil Race wrote:
> >I'm not sure what role the "verification" step we had before ever 
> played.
> >For all the years we've been "verifying" this, we've detected no 
> differences.
>
> I think this is useful in the event that you make some changes and
> regenerate the 64 bit sizes but not 32 bit.
That's a good point. I should add a warning message when regenerating 
the checked-in data files that you need to regenerate the files on both 
32 and 64 bit platforms.
>
> For example this old bug similarly reported a breakage on Solaris ..
> https://bugs.openjdk.java.net/browse/JDK-6804680
>
> ... back in the day when we only had that checked in and the ones used 
> for Linux
> were being generated on the fly. My reading of the history here is 
> sizes.32 and sizes.64
> were added to support cross-compilation, and the verification step 
> meant that? all
> architectures would get checked in some build or other.

I'd rather say that it was at this time that we stopped run-time 
generation of the X11 size data. The "verification" step was there more 
like a comfort thing for the build team, since we was too conservative.


> The clean up of removing the solaris specific seems like it could have 
> been
> done a long time ago .. I am not sure why was ever only this one case 
> there.
> I'd have to dig back a very long way.
>
> I do agree we do not need to support 32 + 64 bit concurrently, that went
> away when 64 bit solaris overlay on 32 bit was dropped.

Thank you.

Updated webrev with warning message about updating for all platforms:

http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.03

(Only UpdateX11Wrappers.gmk has changed)

/Magnus

>
> -phil.
>
> On 03/02/2018 07:23 AM, Erik Joelsson wrote:
>> Adding 2d-dev in the hopes of getting some input from component team. 
>> Seems like they should be aware of us removing the support for 
>> multiple data models.
>>
>> Looks like you left a debug message at line 40 in GensrcX11Wrappers.gmk.
>>
>> /Erik
>>
>> On 2018-03-02 03:00, Magnus Ihse Bursie wrote:
>>> On 2018-03-02 00:02, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> In xlibtypes.txt comment, should it be sizes-64.txt?
>>>
>>> Yes, good catch.
>>>
>>>>
>>>> Generating both 32 and 64 seems a bit outdated at this point. 
>>>> Surely this is a remnant of bundling 64 and 32 bit together on 
>>>> Solaris in the past? Perhaps someone in 2d can answer this? Would 
>>>> be nice to be able to clean up that part as well if possible.
>>> Yes, you are right. We should clean up that as well. I was just too 
>>> conservative. I've now actually checked what happens when you 
>>> generate both 32 and 64 bit versions, and the result is that instead 
>>> of code like:
>>> ??? public static int getSize() { return 96; }
>>> we get code like this:
>>> ??? public static int getSize() { return ((XlibWrapper.dataModel == 
>>> 32)?(80):(96)); }
>>>
>>> Since we do no longer support multiple data models for the same 
>>> build, this is just unnecessary. In fact, that leads to an even 
>>> better cleanup, since we will always need just a single input file.
>>>
>>> I also wrapped the tool calls in ExecuteWithLog.
>>>
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 
>>>
>>>
>>> /Magnus
>>>
>>
>


From philip.race at oracle.com  Mon Mar  5 23:53:53 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 5 Mar 2018 15:53:53 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up
	GensrcX11Wrappers
In-Reply-To: <c1af2076-970f-7058-48c3-72bb0a261c14@oracle.com>
References: <e656babe-e57c-a396-5b18-33ba3c9553c8@oracle.com>
 <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com>
 <d0444932-8b4b-fa96-c341-924ff2c0ad4f@oracle.com>
 <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com>
 <3d245e02-3af5-fc56-4c09-12eca73574e2@oracle.com>
 <c1af2076-970f-7058-48c3-72bb0a261c14@oracle.com>
Message-ID: <5b0e7911-b27d-ce35-abde-a35faaf89693@oracle.com>

+ $(ECHO) needs to be updated for both 32 and 64 bit platforms. You have 
now needs -> need. Could we make this easier by trying to generate the 
32 bit native binary as well if running on 64 bits ? Looks like this was 
not normally done on Linux but if you have 32 bit compiler + library 
support it should work. Or do you consider it easy enough to just kick 
off a 32 bit build to get the same ? -phil.


On 03/05/2018 03:30 PM, Magnus Ihse Bursie wrote:
>
> On 2018-03-05 23:38, Phil Race wrote:
>> >I'm not sure what role the "verification" step we had before ever 
>> played.
>> >For all the years we've been "verifying" this, we've detected no 
>> differences.
>>
>> I think this is useful in the event that you make some changes and
>> regenerate the 64 bit sizes but not 32 bit.
> That's a good point. I should add a warning message when regenerating 
> the checked-in data files that you need to regenerate the files on 
> both 32 and 64 bit platforms.
>>
>> For example this old bug similarly reported a breakage on Solaris ..
>> https://bugs.openjdk.java.net/browse/JDK-6804680
>>
>> ... back in the day when we only had that checked in and the ones 
>> used for Linux
>> were being generated on the fly. My reading of the history here is 
>> sizes.32 and sizes.64
>> were added to support cross-compilation, and the verification step 
>> meant that  all
>> architectures would get checked in some build or other.
>
> I'd rather say that it was at this time that we stopped run-time 
> generation of the X11 size data. The "verification" step was there 
> more like a comfort thing for the build team, since we was too 
> conservative.
>
>
>> The clean up of removing the solaris specific seems like it could 
>> have been
>> done a long time ago .. I am not sure why was ever only this one case 
>> there.
>> I'd have to dig back a very long way.
>>
>> I do agree we do not need to support 32 + 64 bit concurrently, that went
>> away when 64 bit solaris overlay on 32 bit was dropped.
>
> Thank you.
>
> Updated webrev with warning message about updating for all platforms:
>
> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.03 
>
>
> (Only UpdateX11Wrappers.gmk has changed)
>
> /Magnus
>
>>
>> -phil.
>>
>> On 03/02/2018 07:23 AM, Erik Joelsson wrote:
>>> Adding 2d-dev in the hopes of getting some input from component 
>>> team. Seems like they should be aware of us removing the support for 
>>> multiple data models.
>>>
>>> Looks like you left a debug message at line 40 in 
>>> GensrcX11Wrappers.gmk.
>>>
>>> /Erik
>>>
>>> On 2018-03-02 03:00, Magnus Ihse Bursie wrote:
>>>> On 2018-03-02 00:02, Erik Joelsson wrote:
>>>>> Hello,
>>>>>
>>>>> In xlibtypes.txt comment, should it be sizes-64.txt?
>>>>
>>>> Yes, good catch.
>>>>
>>>>>
>>>>> Generating both 32 and 64 seems a bit outdated at this point. 
>>>>> Surely this is a remnant of bundling 64 and 32 bit together on 
>>>>> Solaris in the past? Perhaps someone in 2d can answer this? Would 
>>>>> be nice to be able to clean up that part as well if possible.
>>>> Yes, you are right. We should clean up that as well. I was just too 
>>>> conservative. I've now actually checked what happens when you 
>>>> generate both 32 and 64 bit versions, and the result is that 
>>>> instead of code like:
>>>>     public static int getSize() { return 96; }
>>>> we get code like this:
>>>>     public static int getSize() { return ((XlibWrapper.dataModel == 
>>>> 32)?(80):(96)); }
>>>>
>>>> Since we do no longer support multiple data models for the same 
>>>> build, this is just unnecessary. In fact, that leads to an even 
>>>> better cleanup, since we will always need just a single input file.
>>>>
>>>> I also wrapped the tool calls in ExecuteWithLog.
>>>>
>>>> Updated webrev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 
>>>>
>>>>
>>>> /Magnus
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180305/a0eae250/attachment.html>

From magnus.ihse.bursie at oracle.com  Tue Mar  6 00:00:03 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 6 Mar 2018 01:00:03 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up
	GensrcX11Wrappers
In-Reply-To: <5b0e7911-b27d-ce35-abde-a35faaf89693@oracle.com>
References: <e656babe-e57c-a396-5b18-33ba3c9553c8@oracle.com>
 <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com>
 <d0444932-8b4b-fa96-c341-924ff2c0ad4f@oracle.com>
 <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com>
 <3d245e02-3af5-fc56-4c09-12eca73574e2@oracle.com>
 <c1af2076-970f-7058-48c3-72bb0a261c14@oracle.com>
 <5b0e7911-b27d-ce35-abde-a35faaf89693@oracle.com>
Message-ID: <7e270b69-9b1f-81e0-bf28-820e893b66ad@oracle.com>



On 2018-03-06 00:53, Phil Race wrote:
> + $(ECHO) needs to be updated for both 32 and 64 bit platforms. You 
> have now needs -> need.
Fixed typo. Thanks! (I really hate how I suck at those English plural 
s'es :-&)
> Could we make this easier by trying to generate the 32 bit native 
> binary as well if running on 64 bits ? Looks like this was not 
> normally done on Linux but if you have 32 bit compiler + library 
> support it should work. Or do you consider it easy enough to just kick 
> off a 32 bit build to get the same ?
Yes, I consider that easy enough, given how unlikely it is that this 
needs ever be done.

/Magnus

> -phil.
>
> On 03/05/2018 03:30 PM, Magnus Ihse Bursie wrote:
>>
>> On 2018-03-05 23:38, Phil Race wrote:
>>> >I'm not sure what role the "verification" step we had before ever 
>>> played.
>>> >For all the years we've been "verifying" this, we've detected no 
>>> differences.
>>>
>>> I think this is useful in the event that you make some changes and
>>> regenerate the 64 bit sizes but not 32 bit.
>> That's a good point. I should add a warning message when regenerating 
>> the checked-in data files that you need to regenerate the files on 
>> both 32 and 64 bit platforms.
>>>
>>> For example this old bug similarly reported a breakage on Solaris ..
>>> https://bugs.openjdk.java.net/browse/JDK-6804680
>>>
>>> ... back in the day when we only had that checked in and the ones 
>>> used for Linux
>>> were being generated on the fly. My reading of the history here is 
>>> sizes.32 and sizes.64
>>> were added to support cross-compilation, and the verification step 
>>> meant that? all
>>> architectures would get checked in some build or other.
>>
>> I'd rather say that it was at this time that we stopped run-time 
>> generation of the X11 size data. The "verification" step was there 
>> more like a comfort thing for the build team, since we was too 
>> conservative.
>>
>>
>>> The clean up of removing the solaris specific seems like it could 
>>> have been
>>> done a long time ago .. I am not sure why was ever only this one 
>>> case there.
>>> I'd have to dig back a very long way.
>>>
>>> I do agree we do not need to support 32 + 64 bit concurrently, that 
>>> went
>>> away when 64 bit solaris overlay on 32 bit was dropped.
>>
>> Thank you.
>>
>> Updated webrev with warning message about updating for all platforms:
>>
>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.03 
>>
>>
>> (Only UpdateX11Wrappers.gmk has changed)
>>
>> /Magnus
>>
>>>
>>> -phil.
>>>
>>> On 03/02/2018 07:23 AM, Erik Joelsson wrote:
>>>> Adding 2d-dev in the hopes of getting some input from component 
>>>> team. Seems like they should be aware of us removing the support 
>>>> for multiple data models.
>>>>
>>>> Looks like you left a debug message at line 40 in 
>>>> GensrcX11Wrappers.gmk.
>>>>
>>>> /Erik
>>>>
>>>> On 2018-03-02 03:00, Magnus Ihse Bursie wrote:
>>>>> On 2018-03-02 00:02, Erik Joelsson wrote:
>>>>>> Hello,
>>>>>>
>>>>>> In xlibtypes.txt comment, should it be sizes-64.txt?
>>>>>
>>>>> Yes, good catch.
>>>>>
>>>>>>
>>>>>> Generating both 32 and 64 seems a bit outdated at this point. 
>>>>>> Surely this is a remnant of bundling 64 and 32 bit together on 
>>>>>> Solaris in the past? Perhaps someone in 2d can answer this? Would 
>>>>>> be nice to be able to clean up that part as well if possible.
>>>>> Yes, you are right. We should clean up that as well. I was just 
>>>>> too conservative. I've now actually checked what happens when you 
>>>>> generate both 32 and 64 bit versions, and the result is that 
>>>>> instead of code like:
>>>>> ??? public static int getSize() { return 96; }
>>>>> we get code like this:
>>>>> ??? public static int getSize() { return ((XlibWrapper.dataModel 
>>>>> == 32)?(80):(96)); }
>>>>>
>>>>> Since we do no longer support multiple data models for the same 
>>>>> build, this is just unnecessary. In fact, that leads to an even 
>>>>> better cleanup, since we will always need just a single input file.
>>>>>
>>>>> I also wrapped the tool calls in ExecuteWithLog.
>>>>>
>>>>> Updated webrev:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 
>>>>>
>>>>>
>>>>> /Magnus
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180306/6af03f2d/attachment-0001.html>

From philip.race at oracle.com  Tue Mar  6 00:04:21 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 5 Mar 2018 16:04:21 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up
	GensrcX11Wrappers
In-Reply-To: <7e270b69-9b1f-81e0-bf28-820e893b66ad@oracle.com>
References: <e656babe-e57c-a396-5b18-33ba3c9553c8@oracle.com>
 <76caf055-954d-ae9a-22c1-eaea8b7fee42@oracle.com>
 <d0444932-8b4b-fa96-c341-924ff2c0ad4f@oracle.com>
 <3622d76d-74bc-92f2-af3e-c70ccc5e8092@oracle.com>
 <3d245e02-3af5-fc56-4c09-12eca73574e2@oracle.com>
 <c1af2076-970f-7058-48c3-72bb0a261c14@oracle.com>
 <5b0e7911-b27d-ce35-abde-a35faaf89693@oracle.com>
 <7e270b69-9b1f-81e0-bf28-820e893b66ad@oracle.com>
Message-ID: <e8600b4b-c330-77d2-fd1f-6bc4e989fee1@oracle.com>

It isn't "unlikely" .. it is just "relatively rare".

-phil.

On 03/05/2018 04:00 PM, Magnus Ihse Bursie wrote:
>
>
> On 2018-03-06 00:53, Phil Race wrote:
>> + $(ECHO) needs to be updated for both 32 and 64 bit platforms. You 
>> have now needs -> need.
> Fixed typo. Thanks! (I really hate how I suck at those English plural 
> s'es :-&)
>> Could we make this easier by trying to generate the 32 bit native 
>> binary as well if running on 64 bits ? Looks like this was not 
>> normally done on Linux but if you have 32 bit compiler + library 
>> support it should work. Or do you consider it easy enough to just 
>> kick off a 32 bit build to get the same ?
> Yes, I consider that easy enough, given how unlikely it is that this 
> needs ever be done.
>
> /Magnus
>
>> -phil.
>>
>> On 03/05/2018 03:30 PM, Magnus Ihse Bursie wrote:
>>>
>>> On 2018-03-05 23:38, Phil Race wrote:
>>>> >I'm not sure what role the "verification" step we had before ever 
>>>> played.
>>>> >For all the years we've been "verifying" this, we've detected no 
>>>> differences.
>>>>
>>>> I think this is useful in the event that you make some changes and
>>>> regenerate the 64 bit sizes but not 32 bit.
>>> That's a good point. I should add a warning message when 
>>> regenerating the checked-in data files that you need to regenerate 
>>> the files on both 32 and 64 bit platforms.
>>>>
>>>> For example this old bug similarly reported a breakage on Solaris ..
>>>> https://bugs.openjdk.java.net/browse/JDK-6804680
>>>>
>>>> ... back in the day when we only had that checked in and the ones 
>>>> used for Linux
>>>> were being generated on the fly. My reading of the history here is 
>>>> sizes.32 and sizes.64
>>>> were added to support cross-compilation, and the verification step 
>>>> meant that  all
>>>> architectures would get checked in some build or other.
>>>
>>> I'd rather say that it was at this time that we stopped run-time 
>>> generation of the X11 size data. The "verification" step was there 
>>> more like a comfort thing for the build team, since we was too 
>>> conservative.
>>>
>>>
>>>> The clean up of removing the solaris specific seems like it could 
>>>> have been
>>>> done a long time ago .. I am not sure why was ever only this one 
>>>> case there.
>>>> I'd have to dig back a very long way.
>>>>
>>>> I do agree we do not need to support 32 + 64 bit concurrently, that 
>>>> went
>>>> away when 64 bit solaris overlay on 32 bit was dropped.
>>>
>>> Thank you.
>>>
>>> Updated webrev with warning message about updating for all platforms:
>>>
>>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.03 
>>>
>>>
>>> (Only UpdateX11Wrappers.gmk has changed)
>>>
>>> /Magnus
>>>
>>>>
>>>> -phil.
>>>>
>>>> On 03/02/2018 07:23 AM, Erik Joelsson wrote:
>>>>> Adding 2d-dev in the hopes of getting some input from component 
>>>>> team. Seems like they should be aware of us removing the support 
>>>>> for multiple data models.
>>>>>
>>>>> Looks like you left a debug message at line 40 in 
>>>>> GensrcX11Wrappers.gmk.
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2018-03-02 03:00, Magnus Ihse Bursie wrote:
>>>>>> On 2018-03-02 00:02, Erik Joelsson wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> In xlibtypes.txt comment, should it be sizes-64.txt?
>>>>>>
>>>>>> Yes, good catch.
>>>>>>
>>>>>>>
>>>>>>> Generating both 32 and 64 seems a bit outdated at this point. 
>>>>>>> Surely this is a remnant of bundling 64 and 32 bit together on 
>>>>>>> Solaris in the past? Perhaps someone in 2d can answer this? 
>>>>>>> Would be nice to be able to clean up that part as well if possible.
>>>>>> Yes, you are right. We should clean up that as well. I was just 
>>>>>> too conservative. I've now actually checked what happens when you 
>>>>>> generate both 32 and 64 bit versions, and the result is that 
>>>>>> instead of code like:
>>>>>>     public static int getSize() { return 96; }
>>>>>> we get code like this:
>>>>>>     public static int getSize() { return ((XlibWrapper.dataModel 
>>>>>> == 32)?(80):(96)); }
>>>>>>
>>>>>> Since we do no longer support multiple data models for the same 
>>>>>> build, this is just unnecessary. In fact, that leads to an even 
>>>>>> better cleanup, since we will always need just a single input file.
>>>>>>
>>>>>> I also wrapped the tool calls in ExecuteWithLog.
>>>>>>
>>>>>> Updated webrev:
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 
>>>>>>
>>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180305/03f5cf43/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Tue Mar  6 05:32:38 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Mon, 5 Mar 2018 21:32:38 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <b4d4f75a-f9d3-e2c7-ba79-4c62cdb14bde@oracle.com>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
 <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
 <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>
 <4396fac6-4870-aad9-6e5f-c4b5e274c423@oracle.com>
 <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>
 <b4d4f75a-f9d3-e2c7-ba79-4c62cdb14bde@oracle.com>
Message-ID: <19b5307a-3d66-4683-a215-5df2b6a10267@default>

Hi Sergey, I tested for the problem bug 6404832 and found that issue is not happening anymore. Anyway this old bug was specific to Windows XP and there was no problem with windows 2000, Windows 2003. But tested and found that there is no issue as said in the bug.

I have modified the test per your comments and here is the new Webrev:
http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.02/

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, March 6, 2018 12:04 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky <semyon.sadetsky at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

Hi, Shashi.
Can you confirm that the bug6404832 is not reproducible after this change(since part of it fix is dropped)?

Please use some meaningful name for the test + small typo in the
test(poistion) please fix both before the push.

On 27/02/2018 00:45, Shashidhara Veerabhadraiah wrote:
> Hi Semyon, Thanks for your help. I did some debugging from that 
> perspective and could find the problem and the solution. Here is the 
> new webrev, please review it:
> 
> http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/
> 
> The problem was that in the case of SCROLLBARS_NEVER, scroll bar info 
> was set using setScrollInfo() with SIF_RANGE with ranges being (0, 0).
> This forced the windows to pick a default value and hence reset it to 
> that value every time. Now the logic is modified in a very similar 
> fashion as the other scroll bar display modes but without displaying 
> it using the new win api ShowScrollBar(). The scroll bar info is 
> supplied with a proper range per the corresponding base component but 
> without the scroll bar pane size(as we don?t display it). This should 
> suffice a good range for the scroll bars to operate and correct itself 
> if there is any out of range value is supplied.
> 
> Thanks and regards,
> Shashi
> 
> *From:*Semyon Sadetsky
> *Sent:* Tuesday, February 27, 2018 1:22 AM
> *To:* shashidhara veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>
> *Cc:* awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in 
> ScrollPane is reset after calling validate()
> 
> The bug was failed against Windows platform. So, I'd try to find the 
> root cause why when the scroll is notified with the scrolled component 
> size the scroll position is set to the wrong value.
> 
> --Semyon
> 
> On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:
> 
>     I think I agree Semyon. Thanks for your detailed explanation.
> 
>     So how do we approach on this? I see a different behaviour on other
>     platforms. Shouldn?t we have a common behaviour across platforms? I
>     agree with your analysis and hence should we change the behaviour on
>     other platforms so that all of them will have the same behaviour?
> 
>     Thanks and regards,
> 
>     Shashi
> 
>         On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky
>         <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>>
>         wrote:
> 
>         On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:
> 
>             Hi Semyon, Thanks for your review and these questions help
>             us to reach the right requirements.
> 
>             Without this change, there is different behavior on windows
>             compared to Mac/Linux platforms. Hence this change is
>             required to make the behavior same across the platforms.
>             Since the scroll pane control is not displayed for the
>             SCROLLBARS_NEVER case and if not in the setScrollPosition()
>             then how can the user can move to a different position?
>             Since we used to update/recalculate the scroll pane geometry
>             caused changes to move to a different position other than
>             the setScrollPosition()!! This causes SCROLLBARS_NEVER mode
>             as unusable as the user is unable to control the scrolling
>             movement because neither he can set one setScrollPosition()
>             nor the control is displayed to explicitly set the movement.
>             Hope this answers your question.
> 
>         You need to think once again about two facts I brought in my
>         previous message.
> 
>         1. User still may scroll using mouse wheel even when scrollbars
>         are not visible.
> 
>         2. Visibility of scrollbars doesn't affect the requirement to
>         notify the scroll about the scrolled component size changes. If
>         the scrolled component was 500x500 in size and its position in
>         the 200x200 viewport was (300,300) after the size of the
>         component is changed to 300x300 it may not be shown at the same
>         position because the previously visible component area doesn't
>         exist anymore and the scroll should be moved to (100,100). This
>         should work in the same way regardless the selected scrlollbar
>         visibility policy.
> 
>         --Semyon
> 
> 
>             Thanks and regards,
>             Shashi
> 
>             *From:*Semyon Sadetsky
>             *Sent:*Saturday, February 24, 2018 2:12 AM
>             *To:*Shashidhara
>             Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>             <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>             <mailto:awt-dev at openjdk.java.net>
>             *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>             ScrollPane is reset after calling validate()
> 
>             On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:
> 
>                 Hi Semyon, Whenever the container is resized we used to
>                 update the scroll pane sizes/geometry regardless of the
>                 scroll bar display policies. This resizing make sense
>                 for the non SCROLLBARS_NEVER cases as the scroll pane is
>                 displayed or needed an update. This additional update
>                 posed issues for the SCROLLBARS_NEVER case where we are
>                 not supposed to display the scroll pane per the java
>                 doc, then why update?
> 
>                 Scroll pane geometry gets updated in 2 ways, one thro?
>                 setScrollPosition() and childResized(). So I derived the
>                 conclusion based on the javadoc information that since
>                 we don?t display the scroll pane there is no need to
>                 update the scroll pane geometry based on the
>                 childResized() as it was altering the position already
>                 set by the setScrollPosition(). This behavior is same as
>                 the other non SCROLLBARS_NEVER mode and setting the
>                 scroll bar display to SCROLLBARS_NEVER didn?t made any
>                 difference.
> 
>             The only difference of SCROLLBARS_NEVER from others I got
>             from javadoc is that the scroll bar controls are hidden. So
>             the scrolling itself happens in the same way as in the case
>             of visible scroll bars but it can be only controlled by
>             mouse wheel or programmatically. In my understanding this
>             means that the notification about the scrolled component
>             size changes should happen in the same way as for all other
>             cases. I see no reason for the differentiation that your fix
>             introduces. What will happen if to remove this notification
>             for visible scroll bars modes?
> 
>             --Semyon
> 
> 
>                 Thanks and regards,
>                 Shashi
> 
>                 *From:*Semyon Sadetsky
>                 *Sent:*Friday, February 23, 2018 10:17 PM
>                 *To:*Shashidhara
>                 Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>                 <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>                 <mailto:awt-dev at openjdk.java.net>
>                 *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>                 poistion in ScrollPane is reset after calling 
> validate()
> 
>                 On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:
> 
>                     Hi Semyon, Thanks for your review comments.
> 
>                     Here are those different scroll bar pane modes and
>                     their description:
> 
>                     *Modifier and Type*
> 
>                     	
> 
>                     *Field*
> 
>                     	
> 
>                     *Description*
> 
>                     |static int|
> 
>                     	
> 
>                     *SCROLLBARS_ALWAYS
>                     
> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SC
> ROLLBARS_ALWAYS>*
> 
>                     	
> 
>                     Specifies that horizontal/vertical scrollbars should
>                     always be shown regardless of the respective sizes
>                     of the scrollpane and child.
> 
>                     |static int|
> 
>                     	
> 
>                     *SCROLLBARS_AS_NEEDED
>                     
> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SC
> ROLLBARS_AS_NEEDED>*
> 
>                     	
> 
>                     Specifies that horizontal/vertical scrollbar should
>                     be shown only when the size of the child exceeds the
>                     size of the scrollpane in the horizontal/vertical
>                     dimension.
> 
>                     |static int|
> 
>                     	
> 
>                     *SCROLLBARS_NEVER
>                     
> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SC
> ROLLBARS_NEVER>*
> 
>                     	
> 
>                     Specifies that horizontal/vertical scrollbars should
>                     never be shown regardless of the respective sizes of
>                     the scrollpane and child.
> 
>                 This javadoc, you've copy-pasted here, doesn't explain
>                 why in your fix the notification about changed child
>                 size is disabled for SCROLLBARS_NEVER case.
> 
>                     Thanks and regards,
>                     Shashi
> 
>                     *From:*Semyon Sadetsky
>                     *Sent:*Thursday, February 22, 2018 11:58 PM
>                     *To:*Shashidhara
>                     Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com> <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>                     <mailto:awt-dev at openjdk.java.net>
>                     *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>                     poistion in ScrollPane is reset after calling 
> validate()
> 
>                     Hi Shashi,
> 
>                     Can you clarify what is the principal difference
>                     between SCROLLBARS_NEVER and other scroll policies
>                     that requires to avoid updating the scroll geometry
>                     according to the inner component size?
> 
>                     --Semyon
> 
>                     On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah
>                     wrote:
> 
>                         Hi All, Please review a code fix for the below bug.
> 
>                         
> Bug:https://bugs.openjdk.java.net/browse/JDK-8195738
> 
>                         Webrev:http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
>                         
> <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
> 
>                         Problematic platform: Windows only.
> 
>                         Summary: This bug occurs only on windows
>                         platform and whereas the behavior is different
>                         on Mac/Linux platforms. Now after this fix there
>                         is common behavior across the platforms.
> 
>                         The main problem was with resetting the state of
>                         the scroll bars even though the scroll bar panes
>                         are spawned with SCROLLBARS_NEVER as the scroll
>                         bar display policy. This resetting should not
>                         occur as the scroll bar display policy makes 
> the
> 
>                         scroll bar panes invisible. Hence except the
>                         setScrollPosition() calls, we don?t need to
>                         resize/update the scroll bars state upon calling
>                         the scroll bars validation if SCROLLBARS_NEVER
>                         policy is used as the scroll bars are not displayed.
> 
>                         Thanks and regards,
>                         Shashi
> 


--
Best regards, Sergey.

From prem.balakrishnan at oracle.com  Tue Mar  6 10:48:40 2018
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Tue, 6 Mar 2018 02:48:40 -0800 (PST)
Subject: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated
 Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
 fails
In-Reply-To: <f4ed24b7-6792-b48b-a380-111e0f815182@oracle.com>
References: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>
 <5492eed4-9950-fa2a-2e69-1e2467aa71aa@oracle.com>
 <1d8a8bcb-f771-44c1-9c41-a7fcd74f2efd@default>
 <a9aedc6e-bb97-a61e-6d3c-b33cff860fe2@oracle.com>
 <fc16bb43-8ccf-4628-beef-1b52f0d8f98d@default>
 <f4ed24b7-6792-b48b-a380-111e0f815182@oracle.com>
Message-ID: <bf123646-8e98-44bb-8e31-181a52b102c7@default>

Hi Sergey,

Please review the updated patch:
http://cr.openjdk.java.net/~pkbalakr/8196435/webrev.02/ 

Regards,
Prem

-----Original Message-----
From: Sergey Bylokhov 
Sent: Monday, March 05, 2018 10:27 PM
To: Prem Balakrishnan <prem.balakrishnan at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java' fails

On 01/03/2018 20:16, Prem Balakrishnan wrote:
> The existing waitForIdle() call at line 55 is called after calling setVisible() for both the frames (which I have removed in proposed fix). I have added waitForIdle() call after calling setVisible() for each frame(at line 103 and 110 in proposed fix), which ensures frontFrame is rendered on top of backFrame.

I doubt that this will fix the problem - it will decrease the possibility of such behavior.
Please add toBack()/toFront calls for these frames to make a correct order.

> 
> Regards,
> Prem
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Friday, March 02, 2018 3:19 AM
> To: Prem Balakrishnan <prem.balakrishnan at oracle.com>; 
> awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression 
> automated Test 
> 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java' 
> fails
> 
> Hi, Prem.
> On 26/02/2018 21:20, Prem Balakrishnan wrote:
>> At times backFrame is rendered on top of frontFrame, due to which mouse position on backFrame is not NULL and test fails, solved this by adding waitForIdle() calls appropriately. Furthermore, mousemove from frontFrame to backFrame, caused the cursor to change to resize cursor and test fails, solved this by setting setResizable() to false.
> 
> But the old version of the test also call Util.waitForIdle(null) after frames were shown at line 55.
> 
> 


--
Best regards, Sergey.

From manajit.halder at oracle.com  Tue Mar  6 12:59:57 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Tue, 6 Mar 2018 18:29:57 +0530
Subject: <AWT Dev> <AWT dev>[11] Review request for JDK-8190767: [macos]
 if JFrame is maximized on OS X, all new JFrames will be maximized by default
In-Reply-To: <46dd1caf-8827-43fc-37b3-761c396d34dd@oracle.com>
References: <DB89D6AD-022D-4A42-BB27-643C79B9176A@oracle.com>
 <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
 <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>
 <ab1bdb7e-2be6-1d57-f7d1-0a8b13a1e4ba@oracle.com>
 <CD0F2B6C-5300-41DD-AED3-15D413D01429@oracle.com>
 <5A870469.9070006@oracle.com>
 <ECF1EC5B-A1AB-46CB-AC02-53923A8EEB3F@oracle.com>
 <059B7314-C03E-49A7-A6BA-6D27207DB2D3@oracle.com>
 <46dd1caf-8827-43fc-37b3-761c396d34dd@oracle.com>
Message-ID: <E264A2C9-9EC8-44BB-97A0-ECD627AD6899@oracle.com>

Hi Sergey,

Thank you for the review comment. Modified the test case as per your comment.
Created issue https://bugs.openjdk.java.net/browse/JDK-8199116 <https://bugs.openjdk.java.net/browse/JDK-8199116> for the bug found by you.

Please review the webev:
http://cr.openjdk.java.net/~mhalder/8190767/webrev.04/ <http://cr.openjdk.java.net/~mhalder/8190767/webrev.04/>

Regards,
Manajit 

> On 05-Mar-2018, at 11:36 PM, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
> Hi, Manajit.
> On 26/02/2018 05:45, Manajit Halder wrote:
>> Changed the fix as per Sergey?s review comment. Now both Frame and Dialog are checked for resizibility before setting canFullScreen to true.
>> Please review the modified webrev:
>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.03/ <http://cr.openjdk.java.net/~mhalder/8190767/webrev.03/>
> 
> There are small issues in the test;
> - The Swing components should be created/accessed on EDT(see constructor of AllFramesMaximize and dispose)
> - @test 8190767, I guess @bug tag missed.
> 
> Also I found another bug by this testcase:
> - Change the of the window from JFrame to JDialog at line 103
> - Run the test.
> - Click on the JButton which will open JDialog
> - Click maximize on the JFrame
> - Click on the JButton which will open JDialog again
> - Two dialogs will try to get a focus in an endless loop, by switching between the spaces.
> 
> Please file a CR for this.
> 
>> Thanks,
>> Manajit
>>> On 17-Feb-2018, at 8:03 AM, Manajit Halder <manajit.halder at oracle.com <mailto:manajit.halder at oracle.com> <mailto:manajit.halder at oracle.com <mailto:manajit.halder at oracle.com>>> wrote:
>>> 
>>> Correcting the subject to indicate that the fix is for JDK 11.
>>> 
>>> Regard,
>>> Manajit
>>> 
>>>> On 16-Feb-2018, at 9:48 PM, Kevin Rushforth <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com> <mailto:kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>> wrote:
>>>> 
>>>> Perhaps the subject should be changed to indicate that the fix is for JDK 11 (not JDK 10 for which it is way too late)...
>>>> 
>>>> -- Kevin
>>>> 
>>>> 
>>>> Manajit Halder wrote:
>>>>> Hi Sergey,
>>>>> 
>>>>> Please review the modified fix. The current webrev maintains the window behaviour after it is shown as per the current implementation.
>>>>> canFullScreen is set true in case the window is resizable.
>>>>> 
>>>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.02/ <http://cr.openjdk.java.net/~mhalder/8190767/webrev.02/> <http://cr.openjdk.java.net/%7Emhalder/8190767/webrev.02/ <http://cr.openjdk.java.net/%7Emhalder/8190767/webrev.02/>>
>>>>> 
>>>>> Regards,
>>>>> Manajit
>>>>> 
>>>>>> On 14-Feb-2018, at 8:29 AM, Sergey Bylokhov <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com><mailto:sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>>> wrote:
>>>>>> 
>>>>>> Hi, Manajit.>http://cr.openjdk.java.net/~mhalder/8190767/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8190767/webrev.01/><http://cr.openjdk.java.net/%7Emhalder/8190767/webrev.01/ <http://cr.openjdk.java.net/%7Emhalder/8190767/webrev.01/>>
>>>>>> After the window is shown behavior should be the same as in current implementation(resizable windows should have canFullScreen=true, others canFullScreen=false) so you cannot just set it to "true" or "false".
>>>>>> 
>>>>>>> The issue is not reproducible in jdk8. >
>>>>>>> Regards,
>>>>>>> Manajit
>>>>>>>> 
>>>>>>>> On 31-Jan-2018, at 2:40 AM, Sergey Bylokhov <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com><mailto:sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> <mailto:sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>>> wrote:
>>>>>>>> 
>>>>>>>> Hi, Manajit.
>>>>>>>> Did you check that it works properly in jdk8?
>>>>>>>> 
>>>>>>>> I guess we need to set "WINDOW_FULLSCREENABLE" after we show the window for the first time, with one exception if the window is MAXIMIZED_BOTH.
>>>>>>>> 
>>>>>>>> On 29/01/2018 04:39, Manajit Halder wrote:
>>>>>>>>> Hi All,
>>>>>>>>> Kindly review the fix for JDK10.
>>>>>>>>> Bug:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190767
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.00/
>>>>>>>>> Problem:
>>>>>>>>> In this problem two unrelated windows are created (first window and second window). If the second window is created when the first window is in fullscreen then the second window will automatically be created in fullscreen mode. This is the default behaviour with Cocoa windows. The second window receives windowWillEnterFullScreen notification when the first window is in fullscreen. windowWillEnterFullScreen notification is system generated notification and there is no way to prevent it.
>>>>>>>>> Above conclusion was made after debugging the issue to find out if there is any way to prevent the windowWillEnterFullScreen notification and also to find out if it generated due to some existing java (generic and native) code.
>>>>>>>>> I wrote a simple Mac OS X application with 2 windows and observed the same behaviour. The second window is created in fullscreen mode if it is created when the first window is in fullscreen. Whereas the second window is displayed normal if the first window is in normal mode (not in fullscreen mode). The only way found to prevent the second window going to fullscreen is don?t set this behaviour for the second window.
>>>>>>>>> Fix:
>>>>>>>>> The behaviour is normal on Mac OS. But if we want to prevent the second (all windows except the primary window) window to automatically created in fullscreen mode then the following fix can be applicable.
>>>>>>>>> By default all the Frames are set the WINDOW_FULLSCREENABLE property and by default all frames receives fullscreen event if the first frame is in fullscreen when it is created. Due to this setting the second frame which is created on button click goes to fullscreen on creation automatically. Mac OS fullscreen event notifications are received in case the first frame is in fullscreen and WINDOW_FULLSCREENABLE set for the second frame.
>>>>>>>>> Only the first frame should have the WINDOW_FULLSCREENABLE property set. The frames created in this case were ownerless windows as mentioned earlier. Therefore it is not possible to find out the owner of the current frame, it is null for all the frames created. Hence the fix is if the current frame is the first frame then set the property otherwise don?t set the property WINDOW_FULLSCREENABLE.
>>>>>>>>> Regards,
>>>>>>>>> Manajit
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Best regards, Sergey.
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>> 
>>> 
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180306/05d847c7/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Tue Mar  6 23:22:08 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 6 Mar 2018 15:22:08 -0800
Subject: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated
 Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
 fails
In-Reply-To: <bf123646-8e98-44bb-8e31-181a52b102c7@default>
References: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>
 <5492eed4-9950-fa2a-2e69-1e2467aa71aa@oracle.com>
 <1d8a8bcb-f771-44c1-9c41-a7fcd74f2efd@default>
 <a9aedc6e-bb97-a61e-6d3c-b33cff860fe2@oracle.com>
 <fc16bb43-8ccf-4628-beef-1b52f0d8f98d@default>
 <f4ed24b7-6792-b48b-a380-111e0f815182@oracle.com>
 <bf123646-8e98-44bb-8e31-181a52b102c7@default>
Message-ID: <fbcbae5c-8b99-453f-df0e-d22054631735@oracle.com>

Looks fine.

On 06/03/2018 02:48, Prem Balakrishnan wrote:
> Hi Sergey,
> 
> Please review the updated patch:
> http://cr.openjdk.java.net/~pkbalakr/8196435/webrev.02/
> 
> Regards,
> Prem
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Monday, March 05, 2018 10:27 PM
> To: Prem Balakrishnan <prem.balakrishnan at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java' fails
> 
> On 01/03/2018 20:16, Prem Balakrishnan wrote:
>> The existing waitForIdle() call at line 55 is called after calling setVisible() for both the frames (which I have removed in proposed fix). I have added waitForIdle() call after calling setVisible() for each frame(at line 103 and 110 in proposed fix), which ensures frontFrame is rendered on top of backFrame.
> 
> I doubt that this will fix the problem - it will decrease the possibility of such behavior.
> Please add toBack()/toFront calls for these frames to make a correct order.
> 
>>
>> Regards,
>> Prem
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Friday, March 02, 2018 3:19 AM
>> To: Prem Balakrishnan <prem.balakrishnan at oracle.com>;
>> awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression
>> automated Test
>> 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
>> fails
>>
>> Hi, Prem.
>> On 26/02/2018 21:20, Prem Balakrishnan wrote:
>>> At times backFrame is rendered on top of frontFrame, due to which mouse position on backFrame is not NULL and test fails, solved this by adding waitForIdle() calls appropriately. Furthermore, mousemove from frontFrame to backFrame, caused the cursor to change to resize cursor and test fails, solved this by setting setResizable() to false.
>>
>> But the old version of the test also call Util.waitForIdle(null) after frames were shown at line 55.
>>
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Mar  6 23:25:04 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 6 Mar 2018 15:25:04 -0800
Subject: <AWT Dev> <AWT dev>[11] Review request for JDK-8190767: [macos]
 if JFrame is maximized on OS X, all new JFrames will be maximized by default
In-Reply-To: <E264A2C9-9EC8-44BB-97A0-ECD627AD6899@oracle.com>
References: <DB89D6AD-022D-4A42-BB27-643C79B9176A@oracle.com>
 <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
 <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>
 <ab1bdb7e-2be6-1d57-f7d1-0a8b13a1e4ba@oracle.com>
 <CD0F2B6C-5300-41DD-AED3-15D413D01429@oracle.com>
 <5A870469.9070006@oracle.com>
 <ECF1EC5B-A1AB-46CB-AC02-53923A8EEB3F@oracle.com>
 <059B7314-C03E-49A7-A6BA-6D27207DB2D3@oracle.com>
 <46dd1caf-8827-43fc-37b3-761c396d34dd@oracle.com>
 <E264A2C9-9EC8-44BB-97A0-ECD627AD6899@oracle.com>
Message-ID: <7959f355-ae99-a8c5-cce0-d5d4d748dd32@oracle.com>

Looks fine, please make this test a macosx specific before the push( 
@requires tag)

On 06/03/2018 04:59, Manajit Halder wrote:
> Hi Sergey,
> 
> Thank you for the review comment. Modified the test case as per your 
> comment.
> Created issue https://bugs.openjdk.java.net/browse/JDK-8199116?for the 
> bug found by you.
> 
> Please review the webev:
> http://cr.openjdk.java.net/~mhalder/8190767/webrev.04/
> 
> Regards,
> Manajit
> 
>> On 05-Mar-2018, at 11:36 PM, Sergey Bylokhov 
>> <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> wrote:
>>
>> Hi, Manajit.
>> On 26/02/2018 05:45, Manajit Halder wrote:
>>> Changed the fix as per Sergey?s review comment. Now both Frame and 
>>> Dialog are checked for resizibility before setting canFullScreen to true.
>>> Please review the modified webrev:
>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.03/
>>
>> There are small issues in the test;
>> - The Swing components should be created/accessed on EDT(see 
>> constructor of AllFramesMaximize and dispose)
>> - @test 8190767, I guess @bug tag missed.
>>
>> Also I found another bug by this testcase:
>> - Change the of the window from JFrame to JDialog at line 103
>> - Run the test.
>> - Click on the JButton which will open JDialog
>> - Click maximize on the JFrame
>> - Click on the JButton which will open JDialog again
>> - Two dialogs will try to get a focus in an endless loop, by switching 
>> between the spaces.
>>
>> Please file a CR for this.
>>
>>> Thanks,
>>> Manajit
>>>> On 17-Feb-2018, at 8:03 AM, Manajit Halder 
>>>> <manajit.halder at oracle.com 
>>>> <mailto:manajit.halder at oracle.com><mailto:manajit.halder at oracle.com>> wrote:
>>>>
>>>> Correcting the subject to indicate that the fix is for JDK 11.
>>>>
>>>> Regard,
>>>> Manajit
>>>>
>>>>> On 16-Feb-2018, at 9:48 PM, Kevin Rushforth 
>>>>> <kevin.rushforth at oracle.com 
>>>>> <mailto:kevin.rushforth at oracle.com><mailto:kevin.rushforth at oracle.com>> 
>>>>> wrote:
>>>>>
>>>>> Perhaps the subject should be changed to indicate that the fix is 
>>>>> for JDK 11 (not JDK 10 for which it is way too late)...
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>> Manajit Halder wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> Please review the modified fix. The current webrev maintains the 
>>>>>> window behaviour after it is shown as per the current implementation.
>>>>>> canFullScreen is set true in case the window is resizable.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.02/<http://cr.openjdk.java.net/%7Emhalder/8190767/webrev.02/>
>>>>>>
>>>>>> Regards,
>>>>>> Manajit
>>>>>>
>>>>>>> On 14-Feb-2018, at 8:29 AM, Sergey Bylokhov 
>>>>>>> <sergey.bylokhov at oracle.com 
>>>>>>> <mailto:sergey.bylokhov at oracle.com><mailto:sergey.bylokhov at oracle.com>> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi, 
>>>>>>> Manajit.>http://cr.openjdk.java.net/~mhalder/8190767/webrev.01/<http://cr.openjdk.java.net/%7Emhalder/8190767/webrev.01/>
>>>>>>> After the window is shown behavior should be the same as in 
>>>>>>> current implementation(resizable windows should have 
>>>>>>> canFullScreen=true, others canFullScreen=false) so you cannot 
>>>>>>> just set it to "true" or "false".
>>>>>>>
>>>>>>>> The issue is not reproducible in jdk8. >
>>>>>>>> Regards,
>>>>>>>> Manajit
>>>>>>>>>
>>>>>>>>> On 31-Jan-2018, at 2:40 AM, Sergey Bylokhov 
>>>>>>>>> <sergey.bylokhov at oracle.com 
>>>>>>>>> <mailto:sergey.bylokhov at oracle.com><mailto:sergey.bylokhov at oracle.com> 
>>>>>>>>> <mailto:sergey.bylokhov at oracle.com>> wrote:
>>>>>>>>>
>>>>>>>>> Hi, Manajit.
>>>>>>>>> Did you check that it works properly in jdk8?
>>>>>>>>>
>>>>>>>>> I guess we need to set "WINDOW_FULLSCREENABLE" after we show 
>>>>>>>>> the window for the first time, with one exception if the window 
>>>>>>>>> is MAXIMIZED_BOTH.
>>>>>>>>>
>>>>>>>>> On 29/01/2018 04:39, Manajit Halder wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>> Kindly review the fix for JDK10.
>>>>>>>>>> Bug:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190767
>>>>>>>>>> Webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.00/
>>>>>>>>>> Problem:
>>>>>>>>>> In this problem two unrelated windows are created (first 
>>>>>>>>>> window and second window). If the second window is created 
>>>>>>>>>> when the first window is in fullscreen then the second window 
>>>>>>>>>> will automatically be created in fullscreen mode. This is the 
>>>>>>>>>> default behaviour with Cocoa windows. The second window 
>>>>>>>>>> receives windowWillEnterFullScreen notification when the first 
>>>>>>>>>> window is in fullscreen. windowWillEnterFullScreen 
>>>>>>>>>> notification is system generated notification and there is no 
>>>>>>>>>> way to prevent it.
>>>>>>>>>> Above conclusion was made after debugging the issue to find 
>>>>>>>>>> out if there is any way to prevent the 
>>>>>>>>>> windowWillEnterFullScreen notification and also to find out if 
>>>>>>>>>> it generated due to some existing java (generic and native) code.
>>>>>>>>>> I wrote a simple Mac OS X application with 2 windows and 
>>>>>>>>>> observed the same behaviour. The second window is created in 
>>>>>>>>>> fullscreen mode if it is created when the first window is in 
>>>>>>>>>> fullscreen. Whereas the second window is displayed normal if 
>>>>>>>>>> the first window is in normal mode (not in fullscreen mode). 
>>>>>>>>>> The only way found to prevent the second window going to 
>>>>>>>>>> fullscreen is don?t set this behaviour for the second window.
>>>>>>>>>> Fix:
>>>>>>>>>> The behaviour is normal on Mac OS. But if we want to prevent 
>>>>>>>>>> the second (all windows except the primary window) window to 
>>>>>>>>>> automatically created in fullscreen mode then the following 
>>>>>>>>>> fix can be applicable.
>>>>>>>>>> By default all the Frames are set the WINDOW_FULLSCREENABLE 
>>>>>>>>>> property and by default all frames receives fullscreen event 
>>>>>>>>>> if the first frame is in fullscreen when it is created. Due to 
>>>>>>>>>> this setting the second frame which is created on button click 
>>>>>>>>>> goes to fullscreen on creation automatically. Mac OS 
>>>>>>>>>> fullscreen event notifications are received in case the first 
>>>>>>>>>> frame is in fullscreen and WINDOW_FULLSCREENABLE set for the 
>>>>>>>>>> second frame.
>>>>>>>>>> Only the first frame should have the WINDOW_FULLSCREENABLE 
>>>>>>>>>> property set. The frames created in this case were ownerless 
>>>>>>>>>> windows as mentioned earlier. Therefore it is not possible to 
>>>>>>>>>> find out the owner of the current frame, it is null for all 
>>>>>>>>>> the frames created. Hence the fix is if the current frame is 
>>>>>>>>>> the first frame then set the property otherwise don?t set the 
>>>>>>>>>> property WINDOW_FULLSCREENABLE.
>>>>>>>>>> Regards,
>>>>>>>>>> Manajit
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best regards, Sergey.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards, Sergey.
>>>>>>
>>>>
>>
>>
>> --
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Mar  7 00:17:17 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 6 Mar 2018 16:17:17 -0800
Subject: <AWT Dev> [11] Review Request: 8199022 New failures should be added
 to ProblemList
Message-ID: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>

Hello.
Please review an update of the ProblemList for jdk11.

The goal is to make our testing as stable as possible and exclude any 
unstable tests(I have started from the tests which may be run in the 
headless mode).
In this iteration I have updated the problemList for tests which were 
failed in our nightly at least once for last week. I tested this fix in 
mach5 seven times and always got a green status for open tests.

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

  - The ProblemList.txt is updated, I have created a list of new bugs 
for the tests which fail at least once in a few iterations on a 
different systems.
  - The TEST.ROOT is updated, because "javax/swing" was missed when it 
was updated last time in JDK-8002120. The reason is that our tests does 
not work well in the agentvm mode(they affects each other in some 
unclear way which is reproduced in nightly only).


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Mar  7 00:33:25 2018
From: philip.race at oracle.com (Philip Race)
Date: Tue, 06 Mar 2018 16:33:25 -0800
Subject: <AWT Dev> [11] Review Request: 8199022 New failures should be
 added to ProblemList
In-Reply-To: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
References: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
Message-ID: <5A9F3355.5090005@oracle.com>

+1

-phil.

On 3/6/18, 4:17 PM, Sergey Bylokhov wrote:
> Hello.
> Please review an update of the ProblemList for jdk11.
>
> The goal is to make our testing as stable as possible and exclude any 
> unstable tests(I have started from the tests which may be run in the 
> headless mode).
> In this iteration I have updated the problemList for tests which were 
> failed in our nightly at least once for last week. I tested this fix 
> in mach5 seven times and always got a green status for open tests.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>
>  - The ProblemList.txt is updated, I have created a list of new bugs 
> for the tests which fail at least once in a few iterations on a 
> different systems.
>  - The TEST.ROOT is updated, because "javax/swing" was missed when it 
> was updated last time in JDK-8002120. The reason is that our tests 
> does not work well in the agentvm mode(they affects each other in some 
> unclear way which is reproduced in nightly only).
>
>

From Sergey.Bylokhov at oracle.com  Wed Mar  7 02:41:17 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 6 Mar 2018 18:41:17 -0800
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <19b5307a-3d66-4683-a215-5df2b6a10267@default>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
 <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
 <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>
 <4396fac6-4870-aad9-6e5f-c4b5e274c423@oracle.com>
 <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>
 <b4d4f75a-f9d3-e2c7-ba79-4c62cdb14bde@oracle.com>
 <19b5307a-3d66-4683-a215-5df2b6a10267@default>
Message-ID: <6249ef41-e913-0d28-338e-831284e054c6@oracle.com>

Looks fine.

On 05/03/2018 21:32, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, I tested for the problem bug 6404832 and found that issue is not happening anymore. Anyway this old bug was specific to Windows XP and there was no problem with windows 2000, Windows 2003. But tested and found that there is no issue as said in the bug.
> 
> I have modified the test per your comments and here is the new Webrev:
> http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.02/
> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, March 6, 2018 12:04 AM
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky <semyon.sadetsky at oracle.com>
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()
> 
> Hi, Shashi.
> Can you confirm that the bug6404832 is not reproducible after this change(since part of it fix is dropped)?
> 
> Please use some meaningful name for the test + small typo in the
> test(poistion) please fix both before the push.
> 
> On 27/02/2018 00:45, Shashidhara Veerabhadraiah wrote:
>> Hi Semyon, Thanks for your help. I did some debugging from that
>> perspective and could find the problem and the solution. Here is the
>> new webrev, please review it:
>>
>> http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/
>>
>> The problem was that in the case of SCROLLBARS_NEVER, scroll bar info
>> was set using setScrollInfo() with SIF_RANGE with ranges being (0, 0).
>> This forced the windows to pick a default value and hence reset it to
>> that value every time. Now the logic is modified in a very similar
>> fashion as the other scroll bar display modes but without displaying
>> it using the new win api ShowScrollBar(). The scroll bar info is
>> supplied with a proper range per the corresponding base component but
>> without the scroll bar pane size(as we don?t display it). This should
>> suffice a good range for the scroll bars to operate and correct itself
>> if there is any out of range value is supplied.
>>
>> Thanks and regards,
>> Shashi
>>
>> *From:*Semyon Sadetsky
>> *Sent:* Tuesday, February 27, 2018 1:22 AM
>> *To:* shashidhara veerabhadraiah
>> <shashidhara.veerabhadraiah at oracle.com>
>> *Cc:* awt-dev at openjdk.java.net
>> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>> ScrollPane is reset after calling validate()
>>
>> The bug was failed against Windows platform. So, I'd try to find the
>> root cause why when the scroll is notified with the scrolled component
>> size the scroll position is set to the wrong value.
>>
>> --Semyon
>>
>> On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:
>>
>>      I think I agree Semyon. Thanks for your detailed explanation.
>>
>>      So how do we approach on this? I see a different behaviour on other
>>      platforms. Shouldn?t we have a common behaviour across platforms? I
>>      agree with your analysis and hence should we change the behaviour on
>>      other platforms so that all of them will have the same behaviour?
>>
>>      Thanks and regards,
>>
>>      Shashi
>>
>>          On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky
>>          <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>>
>>          wrote:
>>
>>          On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:
>>
>>              Hi Semyon, Thanks for your review and these questions help
>>              us to reach the right requirements.
>>
>>              Without this change, there is different behavior on windows
>>              compared to Mac/Linux platforms. Hence this change is
>>              required to make the behavior same across the platforms.
>>              Since the scroll pane control is not displayed for the
>>              SCROLLBARS_NEVER case and if not in the setScrollPosition()
>>              then how can the user can move to a different position?
>>              Since we used to update/recalculate the scroll pane geometry
>>              caused changes to move to a different position other than
>>              the setScrollPosition()!! This causes SCROLLBARS_NEVER mode
>>              as unusable as the user is unable to control the scrolling
>>              movement because neither he can set one setScrollPosition()
>>              nor the control is displayed to explicitly set the movement.
>>              Hope this answers your question.
>>
>>          You need to think once again about two facts I brought in my
>>          previous message.
>>
>>          1. User still may scroll using mouse wheel even when scrollbars
>>          are not visible.
>>
>>          2. Visibility of scrollbars doesn't affect the requirement to
>>          notify the scroll about the scrolled component size changes. If
>>          the scrolled component was 500x500 in size and its position in
>>          the 200x200 viewport was (300,300) after the size of the
>>          component is changed to 300x300 it may not be shown at the same
>>          position because the previously visible component area doesn't
>>          exist anymore and the scroll should be moved to (100,100). This
>>          should work in the same way regardless the selected scrlollbar
>>          visibility policy.
>>
>>          --Semyon
>>
>>
>>              Thanks and regards,
>>              Shashi
>>
>>              *From:*Semyon Sadetsky
>>              *Sent:*Saturday, February 24, 2018 2:12 AM
>>              *To:*Shashidhara
>>              Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>>              <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>              <mailto:awt-dev at openjdk.java.net>
>>              *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>>              ScrollPane is reset after calling validate()
>>
>>              On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:
>>
>>                  Hi Semyon, Whenever the container is resized we used to
>>                  update the scroll pane sizes/geometry regardless of the
>>                  scroll bar display policies. This resizing make sense
>>                  for the non SCROLLBARS_NEVER cases as the scroll pane is
>>                  displayed or needed an update. This additional update
>>                  posed issues for the SCROLLBARS_NEVER case where we are
>>                  not supposed to display the scroll pane per the java
>>                  doc, then why update?
>>
>>                  Scroll pane geometry gets updated in 2 ways, one thro?
>>                  setScrollPosition() and childResized(). So I derived the
>>                  conclusion based on the javadoc information that since
>>                  we don?t display the scroll pane there is no need to
>>                  update the scroll pane geometry based on the
>>                  childResized() as it was altering the position already
>>                  set by the setScrollPosition(). This behavior is same as
>>                  the other non SCROLLBARS_NEVER mode and setting the
>>                  scroll bar display to SCROLLBARS_NEVER didn?t made any
>>                  difference.
>>
>>              The only difference of SCROLLBARS_NEVER from others I got
>>              from javadoc is that the scroll bar controls are hidden. So
>>              the scrolling itself happens in the same way as in the case
>>              of visible scroll bars but it can be only controlled by
>>              mouse wheel or programmatically. In my understanding this
>>              means that the notification about the scrolled component
>>              size changes should happen in the same way as for all other
>>              cases. I see no reason for the differentiation that your fix
>>              introduces. What will happen if to remove this notification
>>              for visible scroll bars modes?
>>
>>              --Semyon
>>
>>
>>                  Thanks and regards,
>>                  Shashi
>>
>>                  *From:*Semyon Sadetsky
>>                  *Sent:*Friday, February 23, 2018 10:17 PM
>>                  *To:*Shashidhara
>>                  Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>>                  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>                  <mailto:awt-dev at openjdk.java.net>
>>                  *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>>                  poistion in ScrollPane is reset after calling
>> validate()
>>
>>                  On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:
>>
>>                      Hi Semyon, Thanks for your review comments.
>>
>>                      Here are those different scroll bar pane modes and
>>                      their description:
>>
>>                      *Modifier and Type*
>>
>>                      	
>>
>>                      *Field*
>>
>>                      	
>>
>>                      *Description*
>>
>>                      |static int|
>>
>>                      	
>>
>>                      *SCROLLBARS_ALWAYS
>>                      
>> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SC
>> ROLLBARS_ALWAYS>*
>>
>>                      	
>>
>>                      Specifies that horizontal/vertical scrollbars should
>>                      always be shown regardless of the respective sizes
>>                      of the scrollpane and child.
>>
>>                      |static int|
>>
>>                      	
>>
>>                      *SCROLLBARS_AS_NEEDED
>>                      
>> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SC
>> ROLLBARS_AS_NEEDED>*
>>
>>                      	
>>
>>                      Specifies that horizontal/vertical scrollbar should
>>                      be shown only when the size of the child exceeds the
>>                      size of the scrollpane in the horizontal/vertical
>>                      dimension.
>>
>>                      |static int|
>>
>>                      	
>>
>>                      *SCROLLBARS_NEVER
>>                      
>> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SC
>> ROLLBARS_NEVER>*
>>
>>                      	
>>
>>                      Specifies that horizontal/vertical scrollbars should
>>                      never be shown regardless of the respective sizes of
>>                      the scrollpane and child.
>>
>>                  This javadoc, you've copy-pasted here, doesn't explain
>>                  why in your fix the notification about changed child
>>                  size is disabled for SCROLLBARS_NEVER case.
>>
>>                      Thanks and regards,
>>                      Shashi
>>
>>                      *From:*Semyon Sadetsky
>>                      *Sent:*Thursday, February 22, 2018 11:58 PM
>>                      *To:*Shashidhara
>>                      Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com> <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>                      <mailto:awt-dev at openjdk.java.net>
>>                      *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>>                      poistion in ScrollPane is reset after calling
>> validate()
>>
>>                      Hi Shashi,
>>
>>                      Can you clarify what is the principal difference
>>                      between SCROLLBARS_NEVER and other scroll policies
>>                      that requires to avoid updating the scroll geometry
>>                      according to the inner component size?
>>
>>                      --Semyon
>>
>>                      On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah
>>                      wrote:
>>
>>                          Hi All, Please review a code fix for the below bug.
>>
>>                          
>> Bug:https://bugs.openjdk.java.net/browse/JDK-8195738
>>
>>                          Webrev:http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
>>                          
>> <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
>>
>>                          Problematic platform: Windows only.
>>
>>                          Summary: This bug occurs only on windows
>>                          platform and whereas the behavior is different
>>                          on Mac/Linux platforms. Now after this fix there
>>                          is common behavior across the platforms.
>>
>>                          The main problem was with resetting the state of
>>                          the scroll bars even though the scroll bar panes
>>                          are spawned with SCROLLBARS_NEVER as the scroll
>>                          bar display policy. This resetting should not
>>                          occur as the scroll bar display policy makes
>> the
>>
>>                          scroll bar panes invisible. Hence except the
>>                          setScrollPosition() calls, we don?t need to
>>                          resize/update the scroll bars state upon calling
>>                          the scroll bars validation if SCROLLBARS_NEVER
>>                          policy is used as the scroll bars are not displayed.
>>
>>                          Thanks and regards,
>>                          Shashi
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Wed Mar  7 04:16:29 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 6 Mar 2018 20:16:29 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <6249ef41-e913-0d28-338e-831284e054c6@oracle.com>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
 <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
 <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>
 <4396fac6-4870-aad9-6e5f-c4b5e274c423@oracle.com>
 <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>
 <b4d4f75a-f9d3-e2c7-ba79-4c62cdb14bde@oracle.com>
 <19b5307a-3d66-4683-a215-5df2b6a10267@default>
 <6249ef41-e913-0d28-338e-831284e054c6@oracle.com>
Message-ID: <dbbefe4c-48fc-43db-b8cd-a2866871f0f7@default>

Thanks for your time in review Sergey and Semyon.


-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, March 7, 2018 8:11 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky <semyon.sadetsky at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

Looks fine.

On 05/03/2018 21:32, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, I tested for the problem bug 6404832 and found that issue is not happening anymore. Anyway this old bug was specific to Windows XP and there was no problem with windows 2000, Windows 2003. But tested and found that there is no issue as said in the bug.
> 
> I have modified the test per your comments and here is the new Webrev:
> http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.02/
> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, March 6, 2018 12:04 AM
> To: Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky 
> <semyon.sadetsky at oracle.com>
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane 
> is reset after calling validate()
> 
> Hi, Shashi.
> Can you confirm that the bug6404832 is not reproducible after this change(since part of it fix is dropped)?
> 
> Please use some meaningful name for the test + small typo in the
> test(poistion) please fix both before the push.
> 
> On 27/02/2018 00:45, Shashidhara Veerabhadraiah wrote:
>> Hi Semyon, Thanks for your help. I did some debugging from that 
>> perspective and could find the problem and the solution. Here is the 
>> new webrev, please review it:
>>
>> http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/
>>
>> The problem was that in the case of SCROLLBARS_NEVER, scroll bar info 
>> was set using setScrollInfo() with SIF_RANGE with ranges being (0, 0).
>> This forced the windows to pick a default value and hence reset it to 
>> that value every time. Now the logic is modified in a very similar 
>> fashion as the other scroll bar display modes but without displaying 
>> it using the new win api ShowScrollBar(). The scroll bar info is 
>> supplied with a proper range per the corresponding base component but 
>> without the scroll bar pane size(as we don?t display it). This should 
>> suffice a good range for the scroll bars to operate and correct 
>> itself if there is any out of range value is supplied.
>>
>> Thanks and regards,
>> Shashi
>>
>> *From:*Semyon Sadetsky
>> *Sent:* Tuesday, February 27, 2018 1:22 AM
>> *To:* shashidhara veerabhadraiah
>> <shashidhara.veerabhadraiah at oracle.com>
>> *Cc:* awt-dev at openjdk.java.net
>> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in 
>> ScrollPane is reset after calling validate()
>>
>> The bug was failed against Windows platform. So, I'd try to find the 
>> root cause why when the scroll is notified with the scrolled 
>> component size the scroll position is set to the wrong value.
>>
>> --Semyon
>>
>> On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:
>>
>>      I think I agree Semyon. Thanks for your detailed explanation.
>>
>>      So how do we approach on this? I see a different behaviour on other
>>      platforms. Shouldn?t we have a common behaviour across platforms? I
>>      agree with your analysis and hence should we change the behaviour on
>>      other platforms so that all of them will have the same behaviour?
>>
>>      Thanks and regards,
>>
>>      Shashi
>>
>>          On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky
>>          <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>>
>>          wrote:
>>
>>          On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:
>>
>>              Hi Semyon, Thanks for your review and these questions help
>>              us to reach the right requirements.
>>
>>              Without this change, there is different behavior on windows
>>              compared to Mac/Linux platforms. Hence this change is
>>              required to make the behavior same across the platforms.
>>              Since the scroll pane control is not displayed for the
>>              SCROLLBARS_NEVER case and if not in the setScrollPosition()
>>              then how can the user can move to a different position?
>>              Since we used to update/recalculate the scroll pane geometry
>>              caused changes to move to a different position other than
>>              the setScrollPosition()!! This causes SCROLLBARS_NEVER mode
>>              as unusable as the user is unable to control the scrolling
>>              movement because neither he can set one setScrollPosition()
>>              nor the control is displayed to explicitly set the movement.
>>              Hope this answers your question.
>>
>>          You need to think once again about two facts I brought in my
>>          previous message.
>>
>>          1. User still may scroll using mouse wheel even when scrollbars
>>          are not visible.
>>
>>          2. Visibility of scrollbars doesn't affect the requirement to
>>          notify the scroll about the scrolled component size changes. If
>>          the scrolled component was 500x500 in size and its position in
>>          the 200x200 viewport was (300,300) after the size of the
>>          component is changed to 300x300 it may not be shown at the same
>>          position because the previously visible component area doesn't
>>          exist anymore and the scroll should be moved to (100,100). This
>>          should work in the same way regardless the selected scrlollbar
>>          visibility policy.
>>
>>          --Semyon
>>
>>
>>              Thanks and regards,
>>              Shashi
>>
>>              *From:*Semyon Sadetsky
>>              *Sent:*Saturday, February 24, 2018 2:12 AM
>>              *To:*Shashidhara
>>              Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>>              <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>              <mailto:awt-dev at openjdk.java.net>
>>              *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>>              ScrollPane is reset after calling validate()
>>
>>              On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:
>>
>>                  Hi Semyon, Whenever the container is resized we used to
>>                  update the scroll pane sizes/geometry regardless of the
>>                  scroll bar display policies. This resizing make sense
>>                  for the non SCROLLBARS_NEVER cases as the scroll pane is
>>                  displayed or needed an update. This additional update
>>                  posed issues for the SCROLLBARS_NEVER case where we are
>>                  not supposed to display the scroll pane per the java
>>                  doc, then why update?
>>
>>                  Scroll pane geometry gets updated in 2 ways, one thro?
>>                  setScrollPosition() and childResized(). So I derived the
>>                  conclusion based on the javadoc information that since
>>                  we don?t display the scroll pane there is no need to
>>                  update the scroll pane geometry based on the
>>                  childResized() as it was altering the position already
>>                  set by the setScrollPosition(). This behavior is same as
>>                  the other non SCROLLBARS_NEVER mode and setting the
>>                  scroll bar display to SCROLLBARS_NEVER didn?t made any
>>                  difference.
>>
>>              The only difference of SCROLLBARS_NEVER from others I got
>>              from javadoc is that the scroll bar controls are hidden. So
>>              the scrolling itself happens in the same way as in the case
>>              of visible scroll bars but it can be only controlled by
>>              mouse wheel or programmatically. In my understanding this
>>              means that the notification about the scrolled component
>>              size changes should happen in the same way as for all other
>>              cases. I see no reason for the differentiation that your fix
>>              introduces. What will happen if to remove this notification
>>              for visible scroll bars modes?
>>
>>              --Semyon
>>
>>
>>                  Thanks and regards,
>>                  Shashi
>>
>>                  *From:*Semyon Sadetsky
>>                  *Sent:*Friday, February 23, 2018 10:17 PM
>>                  *To:*Shashidhara
>>                  Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>>                  <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>                  <mailto:awt-dev at openjdk.java.net>
>>                  *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>>                  poistion in ScrollPane is reset after calling
>> validate()
>>
>>                  On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:
>>
>>                      Hi Semyon, Thanks for your review comments.
>>
>>                      Here are those different scroll bar pane modes and
>>                      their description:
>>
>>                      *Modifier and Type*
>>
>>                      	
>>
>>                      *Field*
>>
>>                      	
>>
>>                      *Description*
>>
>>                      |static int|
>>
>>                      	
>>
>>                      *SCROLLBARS_ALWAYS
>>                      
>> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#S
>> C
>> ROLLBARS_ALWAYS>*
>>
>>                      	
>>
>>                      Specifies that horizontal/vertical scrollbars should
>>                      always be shown regardless of the respective sizes
>>                      of the scrollpane and child.
>>
>>                      |static int|
>>
>>                      	
>>
>>                      *SCROLLBARS_AS_NEEDED
>>                      
>> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#S
>> C
>> ROLLBARS_AS_NEEDED>*
>>
>>                      	
>>
>>                      Specifies that horizontal/vertical scrollbar should
>>                      be shown only when the size of the child exceeds the
>>                      size of the scrollpane in the horizontal/vertical
>>                      dimension.
>>
>>                      |static int|
>>
>>                      	
>>
>>                      *SCROLLBARS_NEVER
>>                      
>> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#S
>> C
>> ROLLBARS_NEVER>*
>>
>>                      	
>>
>>                      Specifies that horizontal/vertical scrollbars should
>>                      never be shown regardless of the respective sizes of
>>                      the scrollpane and child.
>>
>>                  This javadoc, you've copy-pasted here, doesn't explain
>>                  why in your fix the notification about changed child
>>                  size is disabled for SCROLLBARS_NEVER case.
>>
>>                      Thanks and regards,
>>                      Shashi
>>
>>                      *From:*Semyon Sadetsky
>>                      *Sent:*Thursday, February 22, 2018 11:58 PM
>>                      *To:*Shashidhara
>>                      Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com> <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>                      <mailto:awt-dev at openjdk.java.net>
>>                      *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>>                      poistion in ScrollPane is reset after calling
>> validate()
>>
>>                      Hi Shashi,
>>
>>                      Can you clarify what is the principal difference
>>                      between SCROLLBARS_NEVER and other scroll policies
>>                      that requires to avoid updating the scroll geometry
>>                      according to the inner component size?
>>
>>                      --Semyon
>>
>>                      On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah
>>                      wrote:
>>
>>                          Hi All, Please review a code fix for the below bug.
>>
>>                          
>> Bug:https://bugs.openjdk.java.net/browse/JDK-8195738
>>
>>                          
>> Webrev:http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
>>                          
>> <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
>>
>>                          Problematic platform: Windows only.
>>
>>                          Summary: This bug occurs only on windows
>>                          platform and whereas the behavior is different
>>                          on Mac/Linux platforms. Now after this fix there
>>                          is common behavior across the platforms.
>>
>>                          The main problem was with resetting the state of
>>                          the scroll bars even though the scroll bar panes
>>                          are spawned with SCROLLBARS_NEVER as the scroll
>>                          bar display policy. This resetting should not
>>                          occur as the scroll bar display policy makes 
>> the
>>
>>                          scroll bar panes invisible. Hence except the
>>                          setScrollPosition() calls, we don?t need to
>>                          resize/update the scroll bars state upon calling
>>                          the scroll bars validation if SCROLLBARS_NEVER
>>                          policy is used as the scroll bars are not displayed.
>>
>>                          Thanks and regards,
>>                          Shashi
>>
> 
> 
> --
> Best regards, Sergey.
> 


--
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Mar  7 08:21:28 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 7 Mar 2018 13:51:28 +0530
Subject: <AWT Dev> <Swing Dev> [11] Review Request: 8199022 New failures
 should be added to ProblemList
In-Reply-To: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
References: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
Message-ID: <41dd6940-ad8e-f0e6-d329-c5a94789fd50@oracle.com>

Hi Sergey,

Looks ok to me. Could you also please add these tests to the list as well

java/awt/image/VolatileImage/CustomCompositeTest.java 8199002 
windows-all, linux-all
java/awt/image/VolatileImage/GradientPaints.java 8199003 linux-all
java/awt/JAWT/JAWT.sh?? windows-all

Regards
Prasanta
On 3/7/2018 5:47 AM, Sergey Bylokhov wrote:
> Hello.
> Please review an update of the ProblemList for jdk11.
>
> The goal is to make our testing as stable as possible and exclude any 
> unstable tests(I have started from the tests which may be run in the 
> headless mode).
> In this iteration I have updated the problemList for tests which were 
> failed in our nightly at least once for last week. I tested this fix 
> in mach5 seven times and always got a green status for open tests.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>
> ?- The ProblemList.txt is updated, I have created a list of new bugs 
> for the tests which fail at least once in a few iterations on a 
> different systems.
> ?- The TEST.ROOT is updated, because "javax/swing" was missed when it 
> was updated last time in JDK-8002120. The reason is that our tests 
> does not work well in the agentvm mode(they affects each other in some 
> unclear way which is reproduced in nightly only).
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180307/294babb2/attachment.html>

From krishna.addepalli at oracle.com  Wed Mar  7 09:08:01 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 7 Mar 2018 01:08:01 -0800 (PST)
Subject: <AWT Dev> <AWT dev>[11] Review request for JDK-8190767: [macos]
 if JFrame is maximized on OS X, all new JFrames will be maximized by default
Message-ID: <775a5c84-5ce4-4671-9dfa-5fdc9e70f70b@default>

Looks fine for me as well.

Thanks,
Krishna

Date: Tue, 6 Mar 2018 15:25:04 -0800
From: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
To: Manajit Halder <manajit.halder at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> <AWT dev>[11] Review request for JDK-8190767:
	[macos] if JFrame is maximized on OS X, all new JFrames will be
	maximized by default
Message-ID: <7959f355-ae99-a8c5-cce0-d5d4d748dd32 at oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Looks fine, please make this test a macosx specific before the push( 
@requires tag)

On 06/03/2018 04:59, Manajit Halder wrote:
> Hi Sergey,
> 
> Thank you for the review comment. Modified the test case as per your 
> comment.
> Created issue https://bugs.openjdk.java.net/browse/JDK-8199116?for the 
> bug found by you.
> 
> Please review the webev:
> http://cr.openjdk.java.net/~mhalder/8190767/webrev.04/
> 
> Regards,
> Manajit
> 
>> On 05-Mar-2018, at 11:36 PM, Sergey Bylokhov 
>> <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> wrote:
>>
>> Hi, Manajit.
>> On 26/02/2018 05:45, Manajit Halder wrote:
>>> Changed the fix as per Sergey?s review comment. Now both Frame and 
>>> Dialog are checked for resizibility before setting canFullScreen to true.
>>> Please review the modified webrev:
>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.03/
>>
>> There are small issues in the test;
>> - The Swing components should be created/accessed on EDT(see 
>> constructor of AllFramesMaximize and dispose)
>> - @test 8190767, I guess @bug tag missed.
>>
>> Also I found another bug by this testcase:
>> - Change the of the window from JFrame to JDialog at line 103
>> - Run the test.
>> - Click on the JButton which will open JDialog
>> - Click maximize on the JFrame
>> - Click on the JButton which will open JDialog again
>> - Two dialogs will try to get a focus in an endless loop, by switching 
>> between the spaces.
>>
>> Please file a CR for this.
>>
>>> Thanks,
>>> Manajit
>>>> On 17-Feb-2018, at 8:03 AM, Manajit Halder 
>>>> <manajit.halder at oracle.com 
>>>> <mailto:manajit.halder at oracle.com><mailto:manajit.halder at oracle.com>> wrote:
>>>>
>>>> Correcting the subject to indicate that the fix is for JDK 11.
>>>>
>>>> Regard,
>>>> Manajit
>>>>
>>>>> On 16-Feb-2018, at 9:48 PM, Kevin Rushforth 
>>>>> <kevin.rushforth at oracle.com 
>>>>> <mailto:kevin.rushforth at oracle.com><mailto:kevin.rushforth at oracle.com>> 
>>>>> wrote:
>>>>>
>>>>> Perhaps the subject should be changed to indicate that the fix is 
>>>>> for JDK 11 (not JDK 10 for which it is way too late)...
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>> Manajit Halder wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> Please review the modified fix. The current webrev maintains the 
>>>>>> window behaviour after it is shown as per the current implementation.
>>>>>> canFullScreen is set true in case the window is resizable.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.02/<http://cr.openjdk.java.net/%7Emhalder/8190767/webrev.02/>
>>>>>>
>>>>>> Regards,
>>>>>> Manajit
>>>>>>
>>>>>>> On 14-Feb-2018, at 8:29 AM, Sergey Bylokhov 
>>>>>>> <sergey.bylokhov at oracle.com 
>>>>>>> <mailto:sergey.bylokhov at oracle.com><mailto:sergey.bylokhov at oracle.com>> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi, 
>>>>>>> Manajit.>http://cr.openjdk.java.net/~mhalder/8190767/webrev.01/<http://cr.openjdk.java.net/%7Emhalder/8190767/webrev.01/>
>>>>>>> After the window is shown behavior should be the same as in 
>>>>>>> current implementation(resizable windows should have 
>>>>>>> canFullScreen=true, others canFullScreen=false) so you cannot 
>>>>>>> just set it to "true" or "false".
>>>>>>>
>>>>>>>> The issue is not reproducible in jdk8. >
>>>>>>>> Regards,
>>>>>>>> Manajit
>>>>>>>>>
>>>>>>>>> On 31-Jan-2018, at 2:40 AM, Sergey Bylokhov 
>>>>>>>>> <sergey.bylokhov at oracle.com 
>>>>>>>>> <mailto:sergey.bylokhov at oracle.com><mailto:sergey.bylokhov at oracle.com> 
>>>>>>>>> <mailto:sergey.bylokhov at oracle.com>> wrote:
>>>>>>>>>
>>>>>>>>> Hi, Manajit.
>>>>>>>>> Did you check that it works properly in jdk8?
>>>>>>>>>
>>>>>>>>> I guess we need to set "WINDOW_FULLSCREENABLE" after we show 
>>>>>>>>> the window for the first time, with one exception if the window 
>>>>>>>>> is MAXIMIZED_BOTH.
>>>>>>>>>
>>>>>>>>> On 29/01/2018 04:39, Manajit Halder wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>> Kindly review the fix for JDK10.
>>>>>>>>>> Bug:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190767
>>>>>>>>>> Webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.00/
>>>>>>>>>> Problem:
>>>>>>>>>> In this problem two unrelated windows are created (first 
>>>>>>>>>> window and second window). If the second window is created 
>>>>>>>>>> when the first window is in fullscreen then the second window 
>>>>>>>>>> will automatically be created in fullscreen mode. This is the 
>>>>>>>>>> default behaviour with Cocoa windows. The second window 
>>>>>>>>>> receives windowWillEnterFullScreen notification when the first 
>>>>>>>>>> window is in fullscreen. windowWillEnterFullScreen 
>>>>>>>>>> notification is system generated notification and there is no 
>>>>>>>>>> way to prevent it.
>>>>>>>>>> Above conclusion was made after debugging the issue to find 
>>>>>>>>>> out if there is any way to prevent the 
>>>>>>>>>> windowWillEnterFullScreen notification and also to find out if 
>>>>>>>>>> it generated due to some existing java (generic and native) code.
>>>>>>>>>> I wrote a simple Mac OS X application with 2 windows and 
>>>>>>>>>> observed the same behaviour. The second window is created in 
>>>>>>>>>> fullscreen mode if it is created when the first window is in 
>>>>>>>>>> fullscreen. Whereas the second window is displayed normal if 
>>>>>>>>>> the first window is in normal mode (not in fullscreen mode). 
>>>>>>>>>> The only way found to prevent the second window going to 
>>>>>>>>>> fullscreen is don?t set this behaviour for the second window.
>>>>>>>>>> Fix:
>>>>>>>>>> The behaviour is normal on Mac OS. But if we want to prevent 
>>>>>>>>>> the second (all windows except the primary window) window to 
>>>>>>>>>> automatically created in fullscreen mode then the following 
>>>>>>>>>> fix can be applicable.
>>>>>>>>>> By default all the Frames are set the WINDOW_FULLSCREENABLE 
>>>>>>>>>> property and by default all frames receives fullscreen event 
>>>>>>>>>> if the first frame is in fullscreen when it is created. Due to 
>>>>>>>>>> this setting the second frame which is created on button click 
>>>>>>>>>> goes to fullscreen on creation automatically. Mac OS 
>>>>>>>>>> fullscreen event notifications are received in case the first 
>>>>>>>>>> frame is in fullscreen and WINDOW_FULLSCREENABLE set for the 
>>>>>>>>>> second frame.
>>>>>>>>>> Only the first frame should have the WINDOW_FULLSCREENABLE 
>>>>>>>>>> property set. The frames created in this case were ownerless 
>>>>>>>>>> windows as mentioned earlier. Therefore it is not possible to 
>>>>>>>>>> find out the owner of the current frame, it is null for all 
>>>>>>>>>> the frames created. Hence the fix is if the current frame is 
>>>>>>>>>> the first frame then set the property otherwise don?t set the 
>>>>>>>>>> property WINDOW_FULLSCREENABLE.
>>>>>>>>>> Regards,
>>>>>>>>>> Manajit
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best regards, Sergey.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards, Sergey.
>>>>>>
>>>>
>>
>>
>> --
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Mar  7 13:55:58 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 7 Mar 2018 05:55:58 -0800
Subject: <AWT Dev> <Swing Dev> [11] Review Request: 8199022 New failures
 should be added to ProblemList
In-Reply-To: <41dd6940-ad8e-f0e6-d329-c5a94789fd50@oracle.com>
References: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
 <41dd6940-ad8e-f0e6-d329-c5a94789fd50@oracle.com>
Message-ID: <b472fe19-4771-7b98-b189-b1cbcabc7916@oracle.com>

Hi, Prasanta.
What bugid for java/awt/JAWT/JAWT.sh ?

On 07/03/2018 00:21, Prasanta Sadhukhan wrote:
> Hi Sergey,
> 
> Looks ok to me. Could you also please add these tests to the list as well
> 
> java/awt/image/VolatileImage/CustomCompositeTest.java 8199002 
> windows-all, linux-all
> java/awt/image/VolatileImage/GradientPaints.java 8199003 linux-all
> java/awt/JAWT/JAWT.sh?? windows-all
> 
> Regards
> Prasanta
> On 3/7/2018 5:47 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review an update of the ProblemList for jdk11.
>>
>> The goal is to make our testing as stable as possible and exclude any 
>> unstable tests(I have started from the tests which may be run in the 
>> headless mode).
>> In this iteration I have updated the problemList for tests which were 
>> failed in our nightly at least once for last week. I tested this fix 
>> in mach5 seven times and always got a green status for open tests.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>>
>> ?- The ProblemList.txt is updated, I have created a list of new bugs 
>> for the tests which fail at least once in a few iterations on a 
>> different systems.
>> ?- The TEST.ROOT is updated, because "javax/swing" was missed when it 
>> was updated last time in JDK-8002120. The reason is that our tests 
>> does not work well in the agentvm mode(they affects each other in some 
>> unclear way which is reproduced in nightly only).
>>
>>
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Mar  7 13:57:13 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 7 Mar 2018 19:27:13 +0530
Subject: <AWT Dev> <Swing Dev> [11] Review Request: 8199022 New failures
 should be added to ProblemList
In-Reply-To: <b472fe19-4771-7b98-b189-b1cbcabc7916@oracle.com>
References: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
 <41dd6940-ad8e-f0e6-d329-c5a94789fd50@oracle.com>
 <b472fe19-4771-7b98-b189-b1cbcabc7916@oracle.com>
Message-ID: <c2fd412c-4f8c-f314-cafa-8a741799e8c0@oracle.com>

JDK-8197798 <https://bugs.openjdk.java.net/browse/JDK-8197798>


On 3/7/2018 7:25 PM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> What bugid for java/awt/JAWT/JAWT.sh ?
>
> On 07/03/2018 00:21, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>> Looks ok to me. Could you also please add these tests to the list as 
>> well
>>
>> java/awt/image/VolatileImage/CustomCompositeTest.java 8199002 
>> windows-all, linux-all
>> java/awt/image/VolatileImage/GradientPaints.java 8199003 linux-all
>> java/awt/JAWT/JAWT.sh?? windows-all
>>
>> Regards
>> Prasanta
>> On 3/7/2018 5:47 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review an update of the ProblemList for jdk11.
>>>
>>> The goal is to make our testing as stable as possible and exclude 
>>> any unstable tests(I have started from the tests which may be run in 
>>> the headless mode).
>>> In this iteration I have updated the problemList for tests which 
>>> were failed in our nightly at least once for last week. I tested 
>>> this fix in mach5 seven times and always got a green status for open 
>>> tests.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>>>
>>> ?- The ProblemList.txt is updated, I have created a list of new bugs 
>>> for the tests which fail at least once in a few iterations on a 
>>> different systems.
>>> ?- The TEST.ROOT is updated, because "javax/swing" was missed when 
>>> it was updated last time in JDK-8002120. The reason is that our 
>>> tests does not work well in the agentvm mode(they affects each other 
>>> in some unclear way which is reproduced in nightly only).
>>>
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180307/16381f58/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed Mar  7 19:08:08 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 7 Mar 2018 11:08:08 -0800
Subject: <AWT Dev> <Swing Dev> [11] Review Request: 8199022 New failures
 should be added to ProblemList
In-Reply-To: <c2fd412c-4f8c-f314-cafa-8a741799e8c0@oracle.com>
References: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
 <41dd6940-ad8e-f0e6-d329-c5a94789fd50@oracle.com>
 <b472fe19-4771-7b98-b189-b1cbcabc7916@oracle.com>
 <c2fd412c-4f8c-f314-cafa-8a741799e8c0@oracle.com>
Message-ID: <5ac042e7-02d3-8bc2-d9db-37d2219f290a@oracle.com>

The patch is updated:
http://cr.openjdk.java.net/~serb/8199022/webrev.01

On 07/03/2018 05:57, Prasanta Sadhukhan wrote:
> JDK-8197798 <https://bugs.openjdk.java.net/browse/JDK-8197798>
> 
> 
> On 3/7/2018 7:25 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> What bugid for java/awt/JAWT/JAWT.sh ?
>>
>> On 07/03/2018 00:21, Prasanta Sadhukhan wrote:
>>> Hi Sergey,
>>>
>>> Looks ok to me. Could you also please add these tests to the list as 
>>> well
>>>
>>> java/awt/image/VolatileImage/CustomCompositeTest.java 8199002 
>>> windows-all, linux-all
>>> java/awt/image/VolatileImage/GradientPaints.java 8199003 linux-all
>>> java/awt/JAWT/JAWT.sh?? windows-all
>>>
>>> Regards
>>> Prasanta
>>> On 3/7/2018 5:47 AM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review an update of the ProblemList for jdk11.
>>>>
>>>> The goal is to make our testing as stable as possible and exclude 
>>>> any unstable tests(I have started from the tests which may be run in 
>>>> the headless mode).
>>>> In this iteration I have updated the problemList for tests which 
>>>> were failed in our nightly at least once for last week. I tested 
>>>> this fix in mach5 seven times and always got a green status for open 
>>>> tests.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>>>>
>>>> ?- The ProblemList.txt is updated, I have created a list of new bugs 
>>>> for the tests which fail at least once in a few iterations on a 
>>>> different systems.
>>>> ?- The TEST.ROOT is updated, because "javax/swing" was missed when 
>>>> it was updated last time in JDK-8002120. The reason is that our 
>>>> tests does not work well in the agentvm mode(they affects each other 
>>>> in some unclear way which is reproduced in nightly only).
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Thu Mar  8 05:42:47 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 8 Mar 2018 11:12:47 +0530
Subject: <AWT Dev> <Swing Dev> [11] Review Request: 8199022 New failures
 should be added to ProblemList
In-Reply-To: <5ac042e7-02d3-8bc2-d9db-37d2219f290a@oracle.com>
References: <a4c8aa6d-b70d-ce7a-a11e-c6606f5c7243@oracle.com>
 <41dd6940-ad8e-f0e6-d329-c5a94789fd50@oracle.com>
 <b472fe19-4771-7b98-b189-b1cbcabc7916@oracle.com>
 <c2fd412c-4f8c-f314-cafa-8a741799e8c0@oracle.com>
 <5ac042e7-02d3-8bc2-d9db-37d2219f290a@oracle.com>
Message-ID: <b157fb3f-e951-59ee-ae1b-2ad656e4c545@oracle.com>

+1

Regards
Prasanta
On 3/8/2018 12:38 AM, Sergey Bylokhov wrote:
> The patch is updated:
> http://cr.openjdk.java.net/~serb/8199022/webrev.01
>
> On 07/03/2018 05:57, Prasanta Sadhukhan wrote:
>> JDK-8197798 <https://bugs.openjdk.java.net/browse/JDK-8197798>
>>
>>
>> On 3/7/2018 7:25 PM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> What bugid for java/awt/JAWT/JAWT.sh ?
>>>
>>> On 07/03/2018 00:21, Prasanta Sadhukhan wrote:
>>>> Hi Sergey,
>>>>
>>>> Looks ok to me. Could you also please add these tests to the list 
>>>> as well
>>>>
>>>> java/awt/image/VolatileImage/CustomCompositeTest.java 8199002 
>>>> windows-all, linux-all
>>>> java/awt/image/VolatileImage/GradientPaints.java 8199003 linux-all
>>>> java/awt/JAWT/JAWT.sh?? windows-all
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 3/7/2018 5:47 AM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review an update of the ProblemList for jdk11.
>>>>>
>>>>> The goal is to make our testing as stable as possible and exclude 
>>>>> any unstable tests(I have started from the tests which may be run 
>>>>> in the headless mode).
>>>>> In this iteration I have updated the problemList for tests which 
>>>>> were failed in our nightly at least once for last week. I tested 
>>>>> this fix in mach5 seven times and always got a green status for 
>>>>> open tests.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>>>>>
>>>>> ?- The ProblemList.txt is updated, I have created a list of new 
>>>>> bugs for the tests which fail at least once in a few iterations on 
>>>>> a different systems.
>>>>> ?- The TEST.ROOT is updated, because "javax/swing" was missed when 
>>>>> it was updated last time in JDK-8002120. The reason is that our 
>>>>> tests does not work well in the agentvm mode(they affects each 
>>>>> other in some unclear way which is reproduced in nightly only).
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From manajit.halder at oracle.com  Thu Mar  8 09:57:39 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Thu, 8 Mar 2018 15:27:39 +0530
Subject: <AWT Dev> Subject: <AWT dev>[11] Review request for
 JDK-7158623: [macosx] Should an unfocusable maximized Frame be resizable?
In-Reply-To: <0D6F1EFB-65B5-4823-B136-6DE71AA4DA28@oracle.com>
References: <D9D0E2F1-34F0-4ACC-B2A4-A8C945D519A8@oracle.com>
 <5A870416.1030009@oracle.com>
 <1506b6ce-01db-ddbb-d00f-6647a62c76fc@oracle.com>
 <0D6F1EFB-65B5-4823-B136-6DE71AA4DA28@oracle.com>
Message-ID: <870C4A8A-931C-492A-BC97-4D856FEA083E@oracle.com>

Hi Phil,

Please find my answers inline:

Before: if its unfocusable, then setStyleBits will set the mask to 0 :

    // this is the counter-point to -[CWindow _nativeSetStyleBit:]
    private void setStyleBits(final int mask, final boolean value) {
        execute(ptr -> nativeSetNSWindowStyleBits(ptr, mask, value ? mask : 0));
    }

Before if its unfocusable, then setStyleBits will not set the bits SHOULD_BECOME_KEY and SHOULD_BECOME_MAIN if the window is not focusable. 
While debugging it was observed that the bits set on the window in this case was 0000111110000010 (the 9th bit is set, whereas the 12th and 13th bits are not set)

After: .. well exactly the same thing .. you just added a RESIZABLE bit that will be ignored.

Now after my fix RESIZABLE bit along with the other bits won?t be set if the window is not focusable. Bits set on the window in this case was 0000110110000010  (the 9th bit is not set)

The bit setting is done in the native method Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowStyleBits.

Thanks,
Manajit


> On 26-Feb-2018, at 1:28 PM, Manajit Halder <manajit.halder at oracle.com> wrote:
> 
> Hi Phil and Kevin,
> 
> Sorry for specifying wrong JDK version. This review is for JDK 11.
> 
> Regarding spec:
>    	It is not mentioned in the focus spec whether the unfocusable maximized frames should be resizable or not.
>    	The fix is given based on the implementation on other platforms (windows and linux/unix) . On both the platforms (windows and unix/linux) the test passes whereas the test fails on Mac.
> 	An old Issue https://bugs.openjdk.java.net/browse/JDK-4980161 <https://bugs.openjdk.java.net/browse/JDK-4980161> is related to this fix.
>   
> Regarding fix:
> 	The test case java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java fails on Mac and passes on windows and linux/unix.
> 	As per the test case when setFocusableWindowState is set to false frame should not be resizable. 
> 	updateFocusableWindowState() updates the window focusable state and the fix under review sets RESIZABLE property to true or false based on focusability of the frame.
> 	
> Regards,
> Manajit
> 
> 
>> webrev appears to be against the correct repo :
>> sh://hg.openjdk.java.net/jdk/client <sh://hg.openjdk.java.net/jdk/client> 
>> 
>> 
>> First can you point to what in the spec. or whatever points to
>> the correct desired behaviour being what you describe :
>> >If the frame is focusable then it is resizable otherwise not.
>> 
>> And regarding the fix, it isn't obvious how adding RESIZABLE changes anything here
>> for the unfocusable case which seems to be the situation that is under discussion.
>> 
>> Before: if its unfocusable, then setStyleBits will set the mask to 0 :
>> 
>>     // this is the counter-point to -[CWindow _nativeSetStyleBit:]
>>     private void setStyleBits(final int mask, final boolean value) {
>>         execute(ptr -> nativeSetNSWindowStyleBits(ptr, mask, value ? mask : 0));
>>     }
>> 
>> After: .. well exactly the same thing .. you just added a RESIZABLE bit that will be ignored.
>> 
>> It may make a difference in the isFocusable case .. but that does not match what you
>> say you are doing.
>> 
>> -phil.
>> 
>> On 02/16/2018 08:17 AM, Kevin Rushforth wrote:
>>> 
>>> > Kindly review the fix for JDK10.
>>> 
>>> You mean JDK 11, right?
>>> 
>>> -- Kevin
>>> 
>>> 
>>> Manajit Halder wrote:
>>>> 
>>>> Hi All,
>>>> 
>>>> Kindly review the fix for JDK10.
>>>> 
>>>> Bug: 
>>>> https://bugs.openjdk.java.net/browse/JDK-7158623 <https://bugs.openjdk.java.net/browse/JDK-7158623>
>>>> 
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mhalder/7158623/webrev.00/ <http://cr.openjdk.java.net/%7Emhalder/7158623/webrev.00/>
>>>> 
>>>> Issue:
>>>> Unfocusable frame was resizable.
>>>> 
>>>> Fix:
>>>> After the fix resizability of the frame depends on focusability of the frame. If the frame is focusable then it is resizable otherwise not.
>>>> The test code was cleaned to remove old test machinery code.
>>>> 
>>>> Regards,
>>>> Manajit
>>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180308/9ab0e137/attachment-0001.html>

From krishna.addepalli at oracle.com  Thu Mar  8 11:03:00 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 8 Mar 2018 03:03:00 -0800 (PST)
Subject: <AWT Dev> <Swing Dev> [11] Review Request: 8199022 New
Message-ID: <e233a7fd-a7c0-4c28-af7f-ca469efed7a6@default>

Hi Sergey, 

Bug id is JDK-8197798 for java/awt/JAWT/JAWT.sh

Thanks,
Krishna

Message: 1
Date: Wed, 7 Mar 2018 05:55:58 -0800
From: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
To: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com>,
	"swing-dev at openjdk.java.net" <swing-dev at openjdk.java.net>,
	"awt-dev at openjdk.java.net" <awt-dev at openjdk.java.net>
Subject: Re: <AWT Dev> <Swing Dev> [11] Review Request: 8199022 New
	failures should be added to ProblemList
Message-ID: <b472fe19-4771-7b98-b189-b1cbcabc7916 at oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi, Prasanta.
What bugid for java/awt/JAWT/JAWT.sh ?

On 07/03/2018 00:21, Prasanta Sadhukhan wrote:
> Hi Sergey,
> 
> Looks ok to me. Could you also please add these tests to the list as 
> well
> 
> java/awt/image/VolatileImage/CustomCompositeTest.java 8199002 
> windows-all, linux-all 
> java/awt/image/VolatileImage/GradientPaints.java 8199003 linux-all 
> java/awt/JAWT/JAWT.sh?? windows-all
> 
> Regards
> Prasanta
> On 3/7/2018 5:47 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review an update of the ProblemList for jdk11.
>>
>> The goal is to make our testing as stable as possible and exclude any 
>> unstable tests(I have started from the tests which may be run in the 
>> headless mode).
>> In this iteration I have updated the problemList for tests which were 
>> failed in our nightly at least once for last week. I tested this fix 
>> in mach5 seven times and always got a green status for open tests.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199022
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8199022/webrev.00/
>>
>> ?- The ProblemList.txt is updated, I have created a list of new bugs 
>> for the tests which fail at least once in a few iterations on a 
>> different systems.
>> ?- The TEST.ROOT is updated, because "javax/swing" was missed when it 
>> was updated last time in JDK-8002120. The reason is that our tests 
>> does not work well in the agentvm mode(they affects each other in 
>> some unclear way which is reproduced in nightly only).
>>
>>
> 


--
Best regards, Sergey.


From anton.litvinov at oracle.com  Mon Mar 12 12:34:22 2018
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Mon, 12 Mar 2018 12:34:22 +0000
Subject: <AWT Dev> [11] Review request for 8198605: Touch keyboard is
 shown for a non-focusable text component
In-Reply-To: <a663ecfa-5528-6ce8-5d33-a1c8f0f5e711@oracle.com>
References: <6b137036-dcb8-6b58-0e4c-372a0141ecdd@oracle.com>
 <9d4fede2-3eef-fd3a-6330-6ca0f5c69df4@oracle.com>
 <34a2859c-0889-0edb-db82-383e4ca74311@oracle.com>
 <a663ecfa-5528-6ce8-5d33-a1c8f0f5e711@oracle.com>
Message-ID: <bc96e7a7-a8b3-a8a2-ecbc-ef063f34b852@oracle.com>

Hello Sergey,

Understood, I have created the corresponding enhancement request 
(https://bugs.openjdk.java.net/browse/JDK-8199455) on this subject. 
Please feel free to edit the description and the summary of this issue, 
if you think that it is necessary to introduce some corrections there.

Thank you,
Anton

On 05/03/2018 14:49, Sergey Bylokhov wrote:
> On 02/03/2018 09:00, anton.litvinov at oracle.com wrote:
>> Do you mean such an RFE may be used for simplification of testing of 
>> this bug or all possible bugs connected with this new functionality, 
>> which allows to automatically show and hide the touch keyboard, on a 
>> PC without a touch screen?
>
> Yes, it is not necessary should be a "public" property, just a way to 
> reproduce and verify the bugs.
>
>>
>> The fix for the bug JDK-8166772 allows to display the touch keyboard 
>> on clicks from a regular physical mouse, but only for the case, when 
>> no physical keyboards are attached to the PC and the system setting
>>
>> "Automatically show the touch keyboard in windowed apps when there's 
>> no keyboard attached to your device"
>>
>> is turned on in MS Windows OS. Therefore technically it is possible 
>> to change the code of 
>> "Java_sun_awt_windows_WToolkit_showTouchKeyboard" function from the 
>> file "src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp" 
>> to check or not to check for presence of any attached keyboards 
>> depending on some new boolean flag, what will let to test this 
>> functionality without a touch screen just having a mouse and a 
>> physical keyboard. But implementation of such a flag, perhaps as a 
>> new Java system property, will require filing CSR request and 
>> describing this flag in the release notes. Also testing the 
>> functionality related to the touch keyboard without a touch screen is 
>> testing of not the main use case.
>>
>> I am ready to create such an RFE and to work on it, if it will be 
>> beneficial for testing and development purposes, but if a person, who 
>> tests the functionality and the developer working on the issue has a 
>> device with a touch screen, then such possible property will simplify 
>> testing of the functionality only for the narrow case in which a user 
>> has MS Window 8 OS or later, does not have a touch screen, cannot 
>> detach the keyboard, since it is part of a laptop, and still wants to 
>> use the touch keyboard using the regular mouse.
>>
>> Thank you,
>> Anton
>>
>> On 01/03/2018 21:53, Sergey Bylokhov wrote:
>>> Hi, Anton.
>>> Looks fine.
>>>
>>> ps: maybe we can create some rfe to enable Touch keyboard even if 
>>> the system has some keyboards for the test purpose?
>>>
>>> On 01/03/2018 08:30, anton.litvinov at oracle.com wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix for the bug.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198605
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8198605/jdk11/webrev.00
>>>>
>>>> The fix extends a number of the required conditions in the method 
>>>> "sun.awt.windows.WToolkit.showOrHideTouchKeyboard(Component, 
>>>> AWTEvent)", which should be satisfied for showing of the touch 
>>>> keyboard, by checking if the component is focusable or not.
>>>>
>>>> Thank you,
>>>> Anton
>>>
>>>
>>
>
>


From anton.litvinov at oracle.com  Mon Mar 12 13:24:47 2018
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Mon, 12 Mar 2018 13:24:47 +0000
Subject: <AWT Dev> [11] Review request for 8198606: Touch keyboard does not
 hide, when a text component looses focus
Message-ID: <e2989ef6-8eb1-3aa2-ef38-06b147932995@oracle.com>

Hello,

Could you please review the following fix for the bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198606
Webrev: http://cr.openjdk.java.net/~alitvinov/8198606/jdk11/webrev.00

The root cause of the bug is the fact that starting from one of the last 
updates of MS Windows 10 the window of the touch keyboard does not have 
the style "WS_VISIBLE", even when it is really visible, and the method 
"AwtToolkit::HideTouchKeyboard()" does not execute the code hiding the 
touch keyboard, because the method 
"AwtToolkit::GetTouchKeyboardWindow()" return "NULL", since one of its 
conditions, particularly "::IsWindowVisible(hwnd)", where "hwnd" is a 
handle of the touch keyboard window, currently always returns "FALSE".

The fix for this bug removes this extra "if" condition from the method 
"AwtToolkit::GetTouchKeyboardWindow()", which in current circumstances 
is always evaluated as "FALSE".

Thank you,
Anton

From Sergey.Bylokhov at oracle.com  Mon Mar 12 14:10:24 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 12 Mar 2018 07:10:24 -0700
Subject: <AWT Dev> [11] Review request for 8198606: Touch keyboard does
 not hide, when a text component looses focus
In-Reply-To: <e2989ef6-8eb1-3aa2-ef38-06b147932995@oracle.com>
References: <e2989ef6-8eb1-3aa2-ef38-06b147932995@oracle.com>
Message-ID: <941933c5-8083-4276-42f9-908ce02734a6@oracle.com>

Looks fine.

On 12/03/2018 06:24, Anton Litvinov wrote:
> Hello,
> 
> Could you please review the following fix for the bug.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198606
> Webrev: http://cr.openjdk.java.net/~alitvinov/8198606/jdk11/webrev.00
> 
> The root cause of the bug is the fact that starting from one of the last 
> updates of MS Windows 10 the window of the touch keyboard does not have 
> the style "WS_VISIBLE", even when it is really visible, and the method 
> "AwtToolkit::HideTouchKeyboard()" does not execute the code hiding the 
> touch keyboard, because the method 
> "AwtToolkit::GetTouchKeyboardWindow()" return "NULL", since one of its 
> conditions, particularly "::IsWindowVisible(hwnd)", where "hwnd" is a 
> handle of the touch keyboard window, currently always returns "FALSE".
> 
> The fix for this bug removes this extra "if" condition from the method 
> "AwtToolkit::GetTouchKeyboardWindow()", which in current circumstances 
> is always evaluated as "FALSE".
> 
> Thank you,
> Anton


-- 
Best regards, Sergey.

From dmitry.markov at oracle.com  Mon Mar 12 22:00:53 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 12 Mar 2018 22:00:53 +0000
Subject: <AWT Dev> [11] Review request for 8198606: Touch keyboard does
 not hide, when a text component looses focus
In-Reply-To: <e2989ef6-8eb1-3aa2-ef38-06b147932995@oracle.com>
References: <e2989ef6-8eb1-3aa2-ef38-06b147932995@oracle.com>
Message-ID: <9AC02E7D-D7EC-43A6-A7AF-4B529463BF8A@oracle.com>

Hi Anton,

The fix looks good.

Thanks,
Dmitry

> On 12 Mar 2018, at 13:24, Anton Litvinov <ANTON.LITVINOV at ORACLE.COM> wrote:
> 
> Hello,
> 
> Could you please review the following fix for the bug.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198606
> Webrev: http://cr.openjdk.java.net/~alitvinov/8198606/jdk11/webrev.00
> 
> The root cause of the bug is the fact that starting from one of the last updates of MS Windows 10 the window of the touch keyboard does not have the style "WS_VISIBLE", even when it is really visible, and the method "AwtToolkit::HideTouchKeyboard()" does not execute the code hiding the touch keyboard, because the method "AwtToolkit::GetTouchKeyboardWindow()" return "NULL", since one of its conditions, particularly "::IsWindowVisible(hwnd)", where "hwnd" is a handle of the touch keyboard window, currently always returns "FALSE".
> 
> The fix for this bug removes this extra "if" condition from the method "AwtToolkit::GetTouchKeyboardWindow()", which in current circumstances is always evaluated as "FALSE".
> 
> Thank you,
> Anton


From dipak.kumar at oracle.com  Wed Mar 14 10:02:15 2018
From: dipak.kumar at oracle.com (Dipak Kumar)
Date: Wed, 14 Mar 2018 03:02:15 -0700 (PDT)
Subject: <AWT Dev> [8u-backport] Review request for 8195738 : scroll
 poistion in ScrollPane is reset after calling validate()
Message-ID: <10404fdb-0444-4d15-8d09-e7f499cbcb5a@default>

Hi All,

 

Please review the below patch (for 8u-backport) - 

 

Webrev : http://cr.openjdk.java.net/~dkumar/8195738/webrev.00/  

JBS : https://bugs.openjdk.java.net/browse/JDK-8195738  

JDK 11 changeset - http://hg.openjdk.java.net/jdk/client/rev/96bebffe0be1 

 

Patch pushed for JDK 11 applies cleanly to JDK 8 after adjusting file path except 'headful' keyword has been removed from the test as this is not defined for 8.

Related Jtreg tests have been run against the proposed patch and results are fine.

 

Thanks,

Dipak

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180314/920c2ea8/attachment.html>

From krishna.addepalli at oracle.com  Wed Mar 14 14:53:08 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 14 Mar 2018 07:53:08 -0700 (PDT)
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
Message-ID: <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>

Hi Sergey,

As per our discussion, I have modified the fix to process only SequencedEvents and ignore others. I have also modified the test case to include some dummy events between two SequencedEvents, and it works.
Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/

However, could you point me to a doc/spec which says that all the SequencedEvents have to be processed together, even if other events in the queue have arrived before?

Thanks,
Krishna

-----Original Message-----
From: Krishna Addepalli 
Sent: Saturday, February 17, 2018 7:57 AM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net; Semyon Sadetsky <semyon.sadetsky at oracle.com>
Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events

Hi Sergey,

The event is present, but with the id "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is pumping the events, it is looking for "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.

Thanks,
Krishna

-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, February 17, 2018 1:49 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net; Semyon Sadetsky <semyon.sadetsky at oracle.com>
Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events

Hi, Krishna.
On 16/02/2018 00:42, Krishna Addepalli wrote:
> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.

But both events are posted by the test, why the second event is not present in the queue?


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Mar 14 17:44:26 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 14 Mar 2018 10:44:26 -0700
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
Message-ID: <64c90022-6a33-5bd2-ae94-097759466836@oracle.com>

On 14/03/2018 07:53, Krishna Addepalli wrote:
> As per our discussion, I have modified the fix to process only SequencedEvents and ignore others. I have also modified the test case to include some dummy events between two SequencedEvents, and it works.

Looks fine.

> However, could you point me to a doc/spec which says that all the SequencedEvents have to be processed together, even if other events in the queue have arrived before?

This class is not public so it behavior is not completely specified. But 
even this javadoc specified that "If this method is invoked before all 
previous nested events have been dispatched, then this method blocks 
until such a point is reached." So yes SequencedEvents should be 
processed together according their order. it does not specify should we 
dispatch other events in between. But if we will dispatch other event 
then we will introduce "out of order dispatching", when some event which 
was posted after SequencedEvent will be dispatched first. So the 
question is why we need this "sort of out of order execution".

> 
> Thanks,
> Krishna
> 
> -----Original Message-----
> From: Krishna Addepalli
> Sent: Saturday, February 17, 2018 7:57 AM
> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net; Semyon Sadetsky <semyon.sadetsky at oracle.com>
> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events
> 
> Hi Sergey,
> 
> The event is present, but with the id "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is pumping the events, it is looking for "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
> 
> Thanks,
> Krishna
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, February 17, 2018 1:49 AM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net; Semyon Sadetsky <semyon.sadetsky at oracle.com>
> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events
> 
> Hi, Krishna.
> On 16/02/2018 00:42, Krishna Addepalli wrote:
>> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.
> 
> But both events are posted by the test, why the second event is not present in the queue?
> 
> 


-- 
Best regards, Sergey.

From chen.j.patrick at gmail.com  Wed Mar 14 12:51:16 2018
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Wed, 14 Mar 2018 13:51:16 +0100
Subject: <AWT Dev> [8u-backport] Review request for 8195738 : scroll
 poistion in ScrollPane is reset after calling validate()
In-Reply-To: <10404fdb-0444-4d15-8d09-e7f499cbcb5a@default>
References: <10404fdb-0444-4d15-8d09-e7f499cbcb5a@default>
Message-ID: <CANmuJ8tWznJW+RrNWQWJP79e4b0-bhFdVVdrOsnoOQAsavR+ng@mail.gmail.com>

Hi,
Why in src/windows/native/sun/windows/awt_ScrollPane.cpp did you delete
the main condition?

Means : the two variables are used isn't it ?

Cheers,
Pc


2018-03-14 11:02 GMT+01:00 Dipak Kumar <dipak.kumar at oracle.com>:

> Hi All,
>
>
>
> Please review the below patch (for 8u-backport) -
>
>
>
> Webrev : http://cr.openjdk.java.net/~dkumar/8195738/webrev.00/
>
> JBS : https://bugs.openjdk.java.net/browse/JDK-8195738
>
> JDK 11 changeset - http://hg.openjdk.java.net/jdk/client/rev/96bebffe0be1
>
>
>
> Patch pushed for JDK 11 applies cleanly to JDK 8 after adjusting file path
> except 'headful' keyword has been removed from the test as this is not
> defined for 8.
>
> Related Jtreg tests have been run against the proposed patch and results
> are fine.
>
>
>
> Thanks,
>
> Dipak
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180314/71a7f75d/attachment.html>

From magnus.ihse.bursie at oracle.com  Thu Mar 15 01:12:14 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 15 Mar 2018 02:12:14 +0100
Subject: <AWT Dev> RFR: JDK-8071469 Cleanup include and exclude of sound
 native libraries after source code restructure
In-Reply-To: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
Message-ID: <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>

I forgot to add the client mailing lists as recipients. Sorry. (Not sure 
if "sounds" belong to "awt" or "2d".)

/Magnus

On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
> From the bug description:
>
> Moving this to a separate bug from JDK-8055190. In SoundLibraries.gmk, 
> the source code splitting is not complete. The directory libjsound is 
> used to build not only libjsound but libjsoundalsa and libjsoundds, 
> and thus needs a complex include/exclude system like before.
>
> I have tested this using COMPARE_BUILD. Windows and solaris are 
> completely clean. On macosx, there's a binary diff (but nothing else) 
> on libjsound.dylib. On linux, some offset seems to have changed, which 
> caused a slight change in disass and fulldump for libjsound.so. I'm 
> not quite sure what's causing it, but I'm convinced it's harmless.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01
>
> /Magnus
>


From erik.joelsson at oracle.com  Thu Mar 15 14:20:38 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 15 Mar 2018 07:20:38 -0700
Subject: <AWT Dev> RFR: JDK-8071469 Cleanup include and exclude of sound
 native libraries after source code restructure
In-Reply-To: <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
Message-ID: <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>

Looks good to me. I tried cleaning this up before but failed to find a 
reasonable split, but this seems like a good split between common and 
library specific.

/Erik


On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
> I forgot to add the client mailing lists as recipients. Sorry. (Not 
> sure if "sounds" belong to "awt" or "2d".)
>
> /Magnus
>
> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>> From the bug description:
>>
>> Moving this to a separate bug from JDK-8055190. In 
>> SoundLibraries.gmk, the source code splitting is not complete. The 
>> directory libjsound is used to build not only libjsound but 
>> libjsoundalsa and libjsoundds, and thus needs a complex 
>> include/exclude system like before.
>>
>> I have tested this using COMPARE_BUILD. Windows and solaris are 
>> completely clean. On macosx, there's a binary diff (but nothing else) 
>> on libjsound.dylib. On linux, some offset seems to have changed, 
>> which caused a slight change in disass and fulldump for libjsound.so. 
>> I'm not quite sure what's causing it, but I'm convinced it's harmless.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01
>>
>> /Magnus
>>
>


From semyon.sadetsky at oracle.com  Thu Mar 15 15:44:21 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 15 Mar 2018 08:44:21 -0700
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
Message-ID: <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>

Hi Krishna,

You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is absolutely 
different event.

They can be used interchangeably?

--Semyon


On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
> Hi Sergey,
>
> As per our discussion, I have modified the fix to process only SequencedEvents and ignore others. I have also modified the test case to include some dummy events between two SequencedEvents, and it works.
> Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>
> However, could you point me to a doc/spec which says that all the SequencedEvents have to be processed together, even if other events in the queue have arrived before?
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Krishna Addepalli
> Sent: Saturday, February 17, 2018 7:57 AM
> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net; Semyon Sadetsky <semyon.sadetsky at oracle.com>
> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events
>
> Hi Sergey,
>
> The event is present, but with the id "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is pumping the events, it is looking for "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, February 17, 2018 1:49 AM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net; Semyon Sadetsky <semyon.sadetsky at oracle.com>
> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events
>
> Hi, Krishna.
> On 16/02/2018 00:42, Krishna Addepalli wrote:
>> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.
> But both events are posted by the test, why the second event is not present in the queue?
>
>


From philip.race at oracle.com  Thu Mar 15 16:53:39 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 15 Mar 2018 09:53:39 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
 exclude of sound native libraries after source code restructure
In-Reply-To: <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
Message-ID: <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>

It is very hard to follow all the moved around files, but one thing
that sticks out is there is a "bsd" directory created and I can't
work out how the files in there are used.
If they are for a BSD port of OpenJDK where is rest of the support for 
that ?

On 03/15/2018 07:20 AM, Erik Joelsson wrote:
> Looks good to me. I tried cleaning this up before but failed to find a 
> reasonable split, but this seems like a good split between common and 
> library specific.
>
> /Erik
>
>
> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>> I forgot to add the client mailing lists as recipients. Sorry. (Not 
>> sure if "sounds" belong to "awt" or "2d".)

In fact, there is a sound-specific list, which I've added.

-phil.
>>
>> /Magnus
>>
>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>> From the bug description:
>>>
>>> Moving this to a separate bug from JDK-8055190. In 
>>> SoundLibraries.gmk, the source code splitting is not complete. The 
>>> directory libjsound is used to build not only libjsound but 
>>> libjsoundalsa and libjsoundds, and thus needs a complex 
>>> include/exclude system like before.
>>>
>>> I have tested this using COMPARE_BUILD. Windows and solaris are 
>>> completely clean. On macosx, there's a binary diff (but nothing 
>>> else) on libjsound.dylib. On linux, some offset seems to have 
>>> changed, which caused a slight change in disass and fulldump for 
>>> libjsound.so. I'm not quite sure what's causing it, but I'm 
>>> convinced it's harmless.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01
>>>
>>> /Magnus
>>>
>>
>


From krishna.addepalli at oracle.com  Thu Mar 15 16:59:23 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 15 Mar 2018 09:59:23 -0700 (PDT)
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
Message-ID: <46db1312-af5e-42a1-aca4-942798e74df8@default>

Hi Semyon,

SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas when it is dispatching events, it is looking for FOCUS_LAST + 2, which is causing the hang.
I have modified it to look for only FOCUS_LAST + 1 events, which has fixed the problem.

Thanks,
Krishna

-----Original Message-----
From: Semyon Sadetsky 
Sent: Thursday, March 15, 2018 9:14 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events

Hi Krishna,

You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is absolutely different event.

They can be used interchangeably?

--Semyon


On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
> Hi Sergey,
>
> As per our discussion, I have modified the fix to process only SequencedEvents and ignore others. I have also modified the test case to include some dummy events between two SequencedEvents, and it works.
> Here is the new webrev: 
> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>
> However, could you point me to a doc/spec which says that all the SequencedEvents have to be processed together, even if other events in the queue have arrived before?
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Krishna Addepalli
> Sent: Saturday, February 17, 2018 7:57 AM
> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; 
> awt-dev at openjdk.java.net; Semyon Sadetsky <semyon.sadetsky at oracle.com>
> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
> sequenced events
>
> Hi Sergey,
>
> The event is present, but with the id "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is pumping the events, it is looking for "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, February 17, 2018 1:49 AM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
> awt-dev at openjdk.java.net; Semyon Sadetsky <semyon.sadetsky at oracle.com>
> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
> sequenced events
>
> Hi, Krishna.
> On 16/02/2018 00:42, Krishna Addepalli wrote:
>> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.
> But both events are posted by the test, why the second event is not present in the queue?
>
>


From semyon.sadetsky at oracle.com  Thu Mar 15 17:06:03 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 15 Mar 2018 10:06:03 -0700
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <46db1312-af5e-42a1-aca4-942798e74df8@default>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
 <46db1312-af5e-42a1-aca4-942798e74df8@default>
Message-ID: <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>

On 03/15/2018 09:59 AM, Krishna Addepalli wrote:

> Hi Semyon,
>
> SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas when it is dispatching events, it is looking for FOCUS_LAST + 2, which is causing the hang.
I think it correctly waits for FOCUS_LAST + 2 to guaranty the right 
order of processing in which the sequenced event is first processed on 
another EDT.

--Semyon
> I have modified it to look for only FOCUS_LAST + 1 events, which has fixed the problem.
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Thursday, March 15, 2018 9:14 PM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events
>
> Hi Krishna,
>
> You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is absolutely different event.
>
> They can be used interchangeably?
>
> --Semyon
>
>
> On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
>> Hi Sergey,
>>
>> As per our discussion, I have modified the fix to process only SequencedEvents and ignore others. I have also modified the test case to include some dummy events between two SequencedEvents, and it works.
>> Here is the new webrev:
>> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>>
>> However, could you point me to a doc/spec which says that all the SequencedEvents have to be processed together, even if other events in the queue have arrived before?
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Krishna Addepalli
>> Sent: Saturday, February 17, 2018 7:57 AM
>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>;
>> awt-dev at openjdk.java.net; Semyon Sadetsky <semyon.sadetsky at oracle.com>
>> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>> sequenced events
>>
>> Hi Sergey,
>>
>> The event is present, but with the id "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is pumping the events, it is looking for "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Saturday, February 17, 2018 1:49 AM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>> awt-dev at openjdk.java.net; Semyon Sadetsky <semyon.sadetsky at oracle.com>
>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>> sequenced events
>>
>> Hi, Krishna.
>> On 16/02/2018 00:42, Krishna Addepalli wrote:
>>> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.
>> But both events are posted by the test, why the second event is not present in the queue?
>>
>>


From krishna.addepalli at oracle.com  Thu Mar 15 17:11:04 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 15 Mar 2018 10:11:04 -0700 (PDT)
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
 <46db1312-af5e-42a1-aca4-942798e74df8@default>
 <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>
Message-ID: <0a2b1ccd-cf94-4c84-8b31-d33415a0e82d@default>

If no such event is posted to the queue, it will lead to hang right? And also, the correct order of processing is not by the event number, but rather by the condition check to see if the current event is the first event in the separate list maintained for SequencedEvents.
Just repeating it for reference: 
"edt.pumpEvents(ID, () -> !SequencedEvent.this.isFirstOrDisposed());"

Thanks,
Krishna

-----Original Message-----
From: Semyon Sadetsky 
Sent: Thursday, March 15, 2018 10:36 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events

On 03/15/2018 09:59 AM, Krishna Addepalli wrote:

> Hi Semyon,
>
> SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas when it is dispatching events, it is looking for FOCUS_LAST + 2, which is causing the hang.
I think it correctly waits for FOCUS_LAST + 2 to guaranty the right order of processing in which the sequenced event is first processed on another EDT.
--Semyon
> I have modified it to look for only FOCUS_LAST + 1 events, which has fixed the problem.
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Thursday, March 15, 2018 9:14 PM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
> awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
> sequenced events
>
> Hi Krishna,
>
> You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is absolutely different event.
>
> They can be used interchangeably?
>
> --Semyon
>
>
> On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
>> Hi Sergey,
>>
>> As per our discussion, I have modified the fix to process only SequencedEvents and ignore others. I have also modified the test case to include some dummy events between two SequencedEvents, and it works.
>> Here is the new webrev:
>> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>>
>> However, could you point me to a doc/spec which says that all the SequencedEvents have to be processed together, even if other events in the queue have arrived before?
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Krishna Addepalli
>> Sent: Saturday, February 17, 2018 7:57 AM
>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; 
>> awt-dev at openjdk.java.net; Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com>
>> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>> sequenced events
>>
>> Hi Sergey,
>>
>> The event is present, but with the id "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is pumping the events, it is looking for "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Saturday, February 17, 2018 1:49 AM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> awt-dev at openjdk.java.net; Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com>
>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>> sequenced events
>>
>> Hi, Krishna.
>> On 16/02/2018 00:42, Krishna Addepalli wrote:
>>> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.
>> But both events are posted by the test, why the second event is not present in the queue?
>>
>>


From semyon.sadetsky at oracle.com  Thu Mar 15 17:17:48 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 15 Mar 2018 10:17:48 -0700
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <0a2b1ccd-cf94-4c84-8b31-d33415a0e82d@default>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
 <46db1312-af5e-42a1-aca4-942798e74df8@default>
 <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>
 <0a2b1ccd-cf94-4c84-8b31-d33415a0e82d@default>
Message-ID: <ee2a5bd2-9ffd-e322-3281-c0a9f09cf109@oracle.com>

On 03/15/2018 10:11 AM, Krishna Addepalli wrote:

> If no such event is posted to the queue, it will lead to hang right?
Are you sure that the root cause is that there are no such event?
I think the event is enqueued but its order is wrong.

The test to the fix must contain several application contexts because 
this mechanism provides synchronization between contexts.

--Semyon
> And also, the correct order of processing is not by the event number, but rather by the condition check to see if the current event is the first event in the separate list maintained for SequencedEvents.
> Just repeating it for reference:
> "edt.pumpEvents(ID, () -> !SequencedEvent.this.isFirstOrDisposed());"
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Thursday, March 15, 2018 10:36 PM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events
>
> On 03/15/2018 09:59 AM, Krishna Addepalli wrote:
>
>> Hi Semyon,
>>
>> SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas when it is dispatching events, it is looking for FOCUS_LAST + 2, which is causing the hang.
> I think it correctly waits for FOCUS_LAST + 2 to guaranty the right order of processing in which the sequenced event is first processed on another EDT.
> --Semyon
>> I have modified it to look for only FOCUS_LAST + 1 events, which has fixed the problem.
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Thursday, March 15, 2018 9:14 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>> awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>> sequenced events
>>
>> Hi Krishna,
>>
>> You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is absolutely different event.
>>
>> They can be used interchangeably?
>>
>> --Semyon
>>
>>
>> On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
>>> Hi Sergey,
>>>
>>> As per our discussion, I have modified the fix to process only SequencedEvents and ignore others. I have also modified the test case to include some dummy events between two SequencedEvents, and it works.
>>> Here is the new webrev:
>>> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>>>
>>> However, could you point me to a doc/spec which says that all the SequencedEvents have to be processed together, even if other events in the queue have arrived before?
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Krishna Addepalli
>>> Sent: Saturday, February 17, 2018 7:57 AM
>>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>;
>>> awt-dev at openjdk.java.net; Semyon Sadetsky
>>> <semyon.sadetsky at oracle.com>
>>> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>> sequenced events
>>>
>>> Hi Sergey,
>>>
>>> The event is present, but with the id "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is pumping the events, it is looking for "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Saturday, February 17, 2018 1:49 AM
>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>> awt-dev at openjdk.java.net; Semyon Sadetsky
>>> <semyon.sadetsky at oracle.com>
>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>> sequenced events
>>>
>>> Hi, Krishna.
>>> On 16/02/2018 00:42, Krishna Addepalli wrote:
>>>> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.
>>> But both events are posted by the test, why the second event is not present in the queue?
>>>
>>>


From erik.joelsson at oracle.com  Thu Mar 15 17:21:14 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 15 Mar 2018 10:21:14 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
 exclude of sound native libraries after source code restructure
In-Reply-To: <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
 <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
Message-ID: <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>

Digging a bit, those files came with the initial Macosx support. It 
doesn't look like they were ever used.

/Erik


On 2018-03-15 09:53, Phil Race wrote:
> It is very hard to follow all the moved around files, but one thing
> that sticks out is there is a "bsd" directory created and I can't
> work out how the files in there are used.
> If they are for a BSD port of OpenJDK where is rest of the support for 
> that ?
>
> On 03/15/2018 07:20 AM, Erik Joelsson wrote:
>> Looks good to me. I tried cleaning this up before but failed to find 
>> a reasonable split, but this seems like a good split between common 
>> and library specific.
>>
>> /Erik
>>
>>
>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>>> I forgot to add the client mailing lists as recipients. Sorry. (Not 
>>> sure if "sounds" belong to "awt" or "2d".)
>
> In fact, there is a sound-specific list, which I've added.
>
> -phil.
>>>
>>> /Magnus
>>>
>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>>> From the bug description:
>>>>
>>>> Moving this to a separate bug from JDK-8055190. In 
>>>> SoundLibraries.gmk, the source code splitting is not complete. The 
>>>> directory libjsound is used to build not only libjsound but 
>>>> libjsoundalsa and libjsoundds, and thus needs a complex 
>>>> include/exclude system like before.
>>>>
>>>> I have tested this using COMPARE_BUILD. Windows and solaris are 
>>>> completely clean. On macosx, there's a binary diff (but nothing 
>>>> else) on libjsound.dylib. On linux, some offset seems to have 
>>>> changed, which caused a slight change in disass and fulldump for 
>>>> libjsound.so. I'm not quite sure what's causing it, but I'm 
>>>> convinced it's harmless.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>>> WebRev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01
>>>>
>>>> /Magnus
>>>>
>>>
>>
>


From philip.race at oracle.com  Thu Mar 15 17:23:19 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 15 Mar 2018 10:23:19 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
 exclude of sound native libraries after source code restructure
In-Reply-To: <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
 <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
 <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>
Message-ID: <ba7941b1-960d-4c87-6ac8-cb5d045dabeb@oracle.com>

I wondered if that might be the case since it was a "BSD" port .. using 
X11 ..

Maybe we should be getting rid of them ?

-phil.

On 03/15/2018 10:21 AM, Erik Joelsson wrote:
> Digging a bit, those files came with the initial Macosx support. It 
> doesn't look like they were ever used.
>
> /Erik
>
>
> On 2018-03-15 09:53, Phil Race wrote:
>> It is very hard to follow all the moved around files, but one thing
>> that sticks out is there is a "bsd" directory created and I can't
>> work out how the files in there are used.
>> If they are for a BSD port of OpenJDK where is rest of the support 
>> for that ?
>>
>> On 03/15/2018 07:20 AM, Erik Joelsson wrote:
>>> Looks good to me. I tried cleaning this up before but failed to find 
>>> a reasonable split, but this seems like a good split between common 
>>> and library specific.
>>>
>>> /Erik
>>>
>>>
>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>>>> I forgot to add the client mailing lists as recipients. Sorry. (Not 
>>>> sure if "sounds" belong to "awt" or "2d".)
>>
>> In fact, there is a sound-specific list, which I've added.
>>
>> -phil.
>>>>
>>>> /Magnus
>>>>
>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>>>> From the bug description:
>>>>>
>>>>> Moving this to a separate bug from JDK-8055190. In 
>>>>> SoundLibraries.gmk, the source code splitting is not complete. The 
>>>>> directory libjsound is used to build not only libjsound but 
>>>>> libjsoundalsa and libjsoundds, and thus needs a complex 
>>>>> include/exclude system like before.
>>>>>
>>>>> I have tested this using COMPARE_BUILD. Windows and solaris are 
>>>>> completely clean. On macosx, there's a binary diff (but nothing 
>>>>> else) on libjsound.dylib. On linux, some offset seems to have 
>>>>> changed, which caused a slight change in disass and fulldump for 
>>>>> libjsound.so. I'm not quite sure what's causing it, but I'm 
>>>>> convinced it's harmless.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>>>> WebRev: 
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01
>>>>>
>>>>> /Magnus
>>>>>
>>>>
>>>
>>
>


From krishna.addepalli at oracle.com  Thu Mar 15 17:30:24 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 15 Mar 2018 10:30:24 -0700 (PDT)
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <ee2a5bd2-9ffd-e322-3281-c0a9f09cf109@oracle.com>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
 <46db1312-af5e-42a1-aca4-942798e74df8@default>
 <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>
 <0a2b1ccd-cf94-4c84-8b31-d33415a0e82d@default>
 <ee2a5bd2-9ffd-e322-3281-c0a9f09cf109@oracle.com>
Message-ID: <040c6d01-16cd-4561-8405-d7ba860fe889@default>

Yes, When we create SequencedEvents, only FOCUS_LAST+1 ids are pushed to the queue, but no event with FOCUS_LAST+2 are pushed. The order(creation) is maintained by having a static List.
There is only one public constructor for SequencedEvents, and it always creates with FOCUS_LAST + 1 as the id for all the events. So, there is no event with FOCUS_LAST + 2 being pushed in the context of a SequencedEvent.,

Also, looking at the logic of the code, what we are saying is that all the SequencedEvents should be processed before any other events in the event queue. Thanks to Sergey for pointing this one out.

My test case already contains two app contexts, and I have posted events on both, creating a dependency between them. Let me know if you want me to add more app contexts.

Thanks,
Krishna

-----Original Message-----
From: Semyon Sadetsky 
Sent: Thursday, March 15, 2018 10:48 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events

On 03/15/2018 10:11 AM, Krishna Addepalli wrote:

> If no such event is posted to the queue, it will lead to hang right?
Are you sure that the root cause is that there are no such event?
I think the event is enqueued but its order is wrong.

The test to the fix must contain several application contexts because this mechanism provides synchronization between contexts.

--Semyon
> And also, the correct order of processing is not by the event number, but rather by the condition check to see if the current event is the first event in the separate list maintained for SequencedEvents.
> Just repeating it for reference:
> "edt.pumpEvents(ID, () -> !SequencedEvent.this.isFirstOrDisposed());"
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Thursday, March 15, 2018 10:36 PM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
> awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
> sequenced events
>
> On 03/15/2018 09:59 AM, Krishna Addepalli wrote:
>
>> Hi Semyon,
>>
>> SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas when it is dispatching events, it is looking for FOCUS_LAST + 2, which is causing the hang.
> I think it correctly waits for FOCUS_LAST + 2 to guaranty the right order of processing in which the sequenced event is first processed on another EDT.
> --Semyon
>> I have modified it to look for only FOCUS_LAST + 1 events, which has fixed the problem.
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Thursday, March 15, 2018 9:14 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>> sequenced events
>>
>> Hi Krishna,
>>
>> You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is absolutely different event.
>>
>> They can be used interchangeably?
>>
>> --Semyon
>>
>>
>> On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
>>> Hi Sergey,
>>>
>>> As per our discussion, I have modified the fix to process only SequencedEvents and ignore others. I have also modified the test case to include some dummy events between two SequencedEvents, and it works.
>>> Here is the new webrev:
>>> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>>>
>>> However, could you point me to a doc/spec which says that all the SequencedEvents have to be processed together, even if other events in the queue have arrived before?
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Krishna Addepalli
>>> Sent: Saturday, February 17, 2018 7:57 AM
>>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; 
>>> awt-dev at openjdk.java.net; Semyon Sadetsky 
>>> <semyon.sadetsky at oracle.com>
>>> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>> sequenced events
>>>
>>> Hi Sergey,
>>>
>>> The event is present, but with the id "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is pumping the events, it is looking for "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Saturday, February 17, 2018 1:49 AM
>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>> awt-dev at openjdk.java.net; Semyon Sadetsky 
>>> <semyon.sadetsky at oracle.com>
>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>> sequenced events
>>>
>>> Hi, Krishna.
>>> On 16/02/2018 00:42, Krishna Addepalli wrote:
>>>> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.
>>> But both events are posted by the test, why the second event is not present in the queue?
>>>
>>>


From semyon.sadetsky at oracle.com  Thu Mar 15 18:30:44 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 15 Mar 2018 11:30:44 -0700
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <040c6d01-16cd-4561-8405-d7ba860fe889@default>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
 <46db1312-af5e-42a1-aca4-942798e74df8@default>
 <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>
 <0a2b1ccd-cf94-4c84-8b31-d33415a0e82d@default>
 <ee2a5bd2-9ffd-e322-3281-c0a9f09cf109@oracle.com>
 <040c6d01-16cd-4561-8405-d7ba860fe889@default>
Message-ID: <4a103e51-78aa-a9cc-34f8-d1de5281af95@oracle.com>

Please understand that you are modifying the mechanism that is 
responsible for synchronization between different application contexts.

You must prove that you did not broke it with your change. But the 
provided test contains one context only.

On 03/15/2018 10:30 AM, Krishna Addepalli wrote:
> Yes, When we create SequencedEvents, only FOCUS_LAST+1 ids are pushed to the queue, but no event with FOCUS_LAST+2 are pushed. The order(creation) is maintained by having a static List.
> There is only one public constructor for SequencedEvents, and it always creates with FOCUS_LAST + 1 as the id for all the events. So, there is no event with FOCUS_LAST + 2 being pushed in the context of a SequencedEvent.,
>
> Also, looking at the logic of the code, what we are saying is that all the SequencedEvents should be processed before any other events in the event queue. Thanks to Sergey for pointing this one out.
>
> My test case already contains two app contexts, and I have posted events on both, creating a dependency between them. Let me know if you want me to add more app contexts.
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Thursday, March 15, 2018 10:48 PM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events
>
> On 03/15/2018 10:11 AM, Krishna Addepalli wrote:
>
>> If no such event is posted to the queue, it will lead to hang right?
> Are you sure that the root cause is that there are no such event?
> I think the event is enqueued but its order is wrong.
>
> The test to the fix must contain several application contexts because this mechanism provides synchronization between contexts.
>
> --Semyon
>> And also, the correct order of processing is not by the event number, but rather by the condition check to see if the current event is the first event in the separate list maintained for SequencedEvents.
>> Just repeating it for reference:
>> "edt.pumpEvents(ID, () -> !SequencedEvent.this.isFirstOrDisposed());"
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Thursday, March 15, 2018 10:36 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>> awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>> sequenced events
>>
>> On 03/15/2018 09:59 AM, Krishna Addepalli wrote:
>>
>>> Hi Semyon,
>>>
>>> SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas when it is dispatching events, it is looking for FOCUS_LAST + 2, which is causing the hang.
>> I think it correctly waits for FOCUS_LAST + 2 to guaranty the right order of processing in which the sequenced event is first processed on another EDT.
>> --Semyon
>>> I have modified it to look for only FOCUS_LAST + 1 events, which has fixed the problem.
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Thursday, March 15, 2018 9:14 PM
>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>> awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>> sequenced events
>>>
>>> Hi Krishna,
>>>
>>> You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is absolutely different event.
>>>
>>> They can be used interchangeably?
>>>
>>> --Semyon
>>>
>>>
>>> On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
>>>> Hi Sergey,
>>>>
>>>> As per our discussion, I have modified the fix to process only SequencedEvents and ignore others. I have also modified the test case to include some dummy events between two SequencedEvents, and it works.
>>>> Here is the new webrev:
>>>> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>>>>
>>>> However, could you point me to a doc/spec which says that all the SequencedEvents have to be processed together, even if other events in the queue have arrived before?
>>>>
>>>> Thanks,
>>>> Krishna
>>>>
>>>> -----Original Message-----
>>>> From: Krishna Addepalli
>>>> Sent: Saturday, February 17, 2018 7:57 AM
>>>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>;
>>>> awt-dev at openjdk.java.net; Semyon Sadetsky
>>>> <semyon.sadetsky at oracle.com>
>>>> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>> sequenced events
>>>>
>>>> Hi Sergey,
>>>>
>>>> The event is present, but with the id "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is pumping the events, it is looking for "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>>>>
>>>> Thanks,
>>>> Krishna
>>>>
>>>> -----Original Message-----
>>>> From: Sergey Bylokhov
>>>> Sent: Saturday, February 17, 2018 1:49 AM
>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>> awt-dev at openjdk.java.net; Semyon Sadetsky
>>>> <semyon.sadetsky at oracle.com>
>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>> sequenced events
>>>>
>>>> Hi, Krishna.
>>>> On 16/02/2018 00:42, Krishna Addepalli wrote:
>>>>> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.
>>>> But both events are posted by the test, why the second event is not present in the queue?
>>>>
>>>>


From magnus.ihse.bursie at oracle.com  Thu Mar 15 18:44:46 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 15 Mar 2018 19:44:46 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
 exclude of sound native libraries after source code restructure
In-Reply-To: <ba7941b1-960d-4c87-6ac8-cb5d045dabeb@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
 <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
 <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>
 <ba7941b1-960d-4c87-6ac8-cb5d045dabeb@oracle.com>
Message-ID: <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com>

On 2018-03-15 18:23, Phil Race wrote:
> I wondered if that might be the case since it was a "BSD" port .. 
> using X11 ..
>
> Maybe we should be getting rid of them ?
I agree, we should delete them. I just shuffled them around in the hope 
that they would be useful for a potential future bsd port, but if/when 
that happens, we can dig them out from mercurial.

A short explanation of how the files moved. The sound library is 
apparently composed of either a single library (solaris and macosx) or 
two libraries (linux and windows). Two building blocks, MIDI + ports and 
DirectAudio is used for all platforms, but they go into either the main 
library (libjsound) or the helper library.

For Windows, MIDI+Ports go into libjsound, and DirectAudio go into 
libjsoundds. On Linux, MIDI+Ports and DirectAudio go into libjsoundalsa. 
On Macosx and Solaris, MIDI+Ports and DirectAudio go into the main 
libjsound.

I have no idea why this split is necessary, but this is how the 
libraries de facto is compiled, and the code needs to match that. If it 
would be possible to move libjsoundds and libjsoundalsa into libjsound 
directly, things would be greatly simplified.

/Magnus

>
> -phil.
>
> On 03/15/2018 10:21 AM, Erik Joelsson wrote:
>> Digging a bit, those files came with the initial Macosx support. It 
>> doesn't look like they were ever used.
>>
>> /Erik
>>
>>
>> On 2018-03-15 09:53, Phil Race wrote:
>>> It is very hard to follow all the moved around files, but one thing
>>> that sticks out is there is a "bsd" directory created and I can't
>>> work out how the files in there are used.
>>> If they are for a BSD port of OpenJDK where is rest of the support 
>>> for that ?
>>>
>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote:
>>>> Looks good to me. I tried cleaning this up before but failed to 
>>>> find a reasonable split, but this seems like a good split between 
>>>> common and library specific.
>>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>>>>> I forgot to add the client mailing lists as recipients. Sorry. 
>>>>> (Not sure if "sounds" belong to "awt" or "2d".)
>>>
>>> In fact, there is a sound-specific list, which I've added.
>>>
>>> -phil.
>>>>>
>>>>> /Magnus
>>>>>
>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>>>>> From the bug description:
>>>>>>
>>>>>> Moving this to a separate bug from JDK-8055190. In 
>>>>>> SoundLibraries.gmk, the source code splitting is not complete. 
>>>>>> The directory libjsound is used to build not only libjsound but 
>>>>>> libjsoundalsa and libjsoundds, and thus needs a complex 
>>>>>> include/exclude system like before.
>>>>>>
>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris are 
>>>>>> completely clean. On macosx, there's a binary diff (but nothing 
>>>>>> else) on libjsound.dylib. On linux, some offset seems to have 
>>>>>> changed, which caused a slight change in disass and fulldump for 
>>>>>> libjsound.so. I'm not quite sure what's causing it, but I'm 
>>>>>> convinced it's harmless.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>>>>> WebRev: 
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01
>>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>
>>>>
>>>
>>
>


From alexey.menkov at oracle.com  Thu Mar 15 19:06:30 2018
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Thu, 15 Mar 2018 12:06:30 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
 exclude of sound native libraries after source code restructure
In-Reply-To: <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
 <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
 <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>
 <ba7941b1-960d-4c87-6ac8-cb5d045dabeb@oracle.com>
 <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com>
Message-ID: <a92da605-aad7-5481-7369-b16788e098c6@oracle.com>



On 03/15/2018 11:44, Magnus Ihse Bursie wrote:
> On 2018-03-15 18:23, Phil Race wrote:
>> I wondered if that might be the case since it was a "BSD" port .. 
>> using X11 ..
>>
>> Maybe we should be getting rid of them ?
> I agree, we should delete them. I just shuffled them around in the hope 
> that they would be useful for a potential future bsd port, but if/when 
> that happens, we can dig them out from mercurial.
> 
> A short explanation of how the files moved. The sound library is 
> apparently composed of either a single library (solaris and macosx) or 
> two libraries (linux and windows). Two building blocks, MIDI + ports and 
> DirectAudio is used for all platforms, but they go into either the main 
> library (libjsound) or the helper library.
> 
> For Windows, MIDI+Ports go into libjsound, and DirectAudio go into 
> libjsoundds. On Linux, MIDI+Ports and DirectAudio go into libjsoundalsa. 
> On Macosx and Solaris, MIDI+Ports and DirectAudio go into the main 
> libjsound.
> 
> I have no idea why this split is necessary, but this is how the 
> libraries de facto is compiled, and the code needs to match that. If it 
> would be possible to move libjsoundds and libjsoundalsa into libjsound 
> directly, things would be greatly simplified.

As far as I know the split was made to dynamically load ALSA/DirectSound 
stuff. If it's not available (or old unsupported version is installed), 
libjsound stuff continues to work (in pre-OpenJDK libjsound supported 
WaveIn/WaveOut on Windows and OSS on Linux).
For now Windows (DirectSound) libjsoundds stuff can be merged into 
libjsound, but I'm not sure we can rely on ALSA is always available on 
Linux (but most likely if ALSA is not available, libjsound does not 
provide any functionality, so I suppose libjsoundalsa stuff can be moved 
to libjsound as well)

--alex

> 
> /Magnus
> 
>>
>> -phil.
>>
>> On 03/15/2018 10:21 AM, Erik Joelsson wrote:
>>> Digging a bit, those files came with the initial Macosx support. It 
>>> doesn't look like they were ever used.
>>>
>>> /Erik
>>>
>>>
>>> On 2018-03-15 09:53, Phil Race wrote:
>>>> It is very hard to follow all the moved around files, but one thing
>>>> that sticks out is there is a "bsd" directory created and I can't
>>>> work out how the files in there are used.
>>>> If they are for a BSD port of OpenJDK where is rest of the support 
>>>> for that ?
>>>>
>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote:
>>>>> Looks good to me. I tried cleaning this up before but failed to 
>>>>> find a reasonable split, but this seems like a good split between 
>>>>> common and library specific.
>>>>>
>>>>> /Erik
>>>>>
>>>>>
>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>>>>>> I forgot to add the client mailing lists as recipients. Sorry. 
>>>>>> (Not sure if "sounds" belong to "awt" or "2d".)
>>>>
>>>> In fact, there is a sound-specific list, which I've added.
>>>>
>>>> -phil.
>>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>>>>>> From the bug description:
>>>>>>>
>>>>>>> Moving this to a separate bug from JDK-8055190. In 
>>>>>>> SoundLibraries.gmk, the source code splitting is not complete. 
>>>>>>> The directory libjsound is used to build not only libjsound but 
>>>>>>> libjsoundalsa and libjsoundds, and thus needs a complex 
>>>>>>> include/exclude system like before.
>>>>>>>
>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris are 
>>>>>>> completely clean. On macosx, there's a binary diff (but nothing 
>>>>>>> else) on libjsound.dylib. On linux, some offset seems to have 
>>>>>>> changed, which caused a slight change in disass and fulldump for 
>>>>>>> libjsound.so. I'm not quite sure what's causing it, but I'm 
>>>>>>> convinced it's harmless.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>>>>>> WebRev: 
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 
>>>>>>>
>>>>>>>
>>>>>>> /Magnus
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

From philip.race at oracle.com  Thu Mar 15 19:13:12 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 15 Mar 2018 12:13:12 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
 exclude of sound native libraries after source code restructure
In-Reply-To: <a92da605-aad7-5481-7369-b16788e098c6@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
 <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
 <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>
 <ba7941b1-960d-4c87-6ac8-cb5d045dabeb@oracle.com>
 <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com>
 <a92da605-aad7-5481-7369-b16788e098c6@oracle.com>
Message-ID: <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com>


 > As far as I know the split was made to dynamically load 
ALSA/DirectSound stuff

Yes, I think it is something like that for Linux
ie if at runtime a dependent-but-not-essential .so was not
installed it was not fatal. I don't know to what extent this is no longer a
possible issue, or one that matters.

-phil.

On 03/15/2018 12:06 PM, Alex Menkov wrote:
>
>
> On 03/15/2018 11:44, Magnus Ihse Bursie wrote:
>> On 2018-03-15 18:23, Phil Race wrote:
>>> I wondered if that might be the case since it was a "BSD" port .. 
>>> using X11 ..
>>>
>>> Maybe we should be getting rid of them ?
>> I agree, we should delete them. I just shuffled them around in the 
>> hope that they would be useful for a potential future bsd port, but 
>> if/when that happens, we can dig them out from mercurial.
>>
>> A short explanation of how the files moved. The sound library is 
>> apparently composed of either a single library (solaris and macosx) 
>> or two libraries (linux and windows). Two building blocks, MIDI + 
>> ports and DirectAudio is used for all platforms, but they go into 
>> either the main library (libjsound) or the helper library.
>>
>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go into 
>> libjsoundds. On Linux, MIDI+Ports and DirectAudio go into 
>> libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio go 
>> into the main libjsound.
>>
>> I have no idea why this split is necessary, but this is how the 
>> libraries de facto is compiled, and the code needs to match that. If 
>> it would be possible to move libjsoundds and libjsoundalsa into 
>> libjsound directly, things would be greatly simplified.
>
> As far as I know the split was made to dynamically load 
> ALSA/DirectSound stuff. If it's not available (or old unsupported 
> version is installed), libjsound stuff continues to work (in 
> pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS on 
> Linux).
> For now Windows (DirectSound) libjsoundds stuff can be merged into 
> libjsound, but I'm not sure we can rely on ALSA is always available on 
> Linux (but most likely if ALSA is not available, libjsound does not 
> provide any functionality, so I suppose libjsoundalsa stuff can be 
> moved to libjsound as well)
>
> --alex
>
>>
>> /Magnus
>>
>>>
>>> -phil.
>>>
>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote:
>>>> Digging a bit, those files came with the initial Macosx support. It 
>>>> doesn't look like they were ever used.
>>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2018-03-15 09:53, Phil Race wrote:
>>>>> It is very hard to follow all the moved around files, but one thing
>>>>> that sticks out is there is a "bsd" directory created and I can't
>>>>> work out how the files in there are used.
>>>>> If they are for a BSD port of OpenJDK where is rest of the support 
>>>>> for that ?
>>>>>
>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote:
>>>>>> Looks good to me. I tried cleaning this up before but failed to 
>>>>>> find a reasonable split, but this seems like a good split between 
>>>>>> common and library specific.
>>>>>>
>>>>>> /Erik
>>>>>>
>>>>>>
>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>>>>>>> I forgot to add the client mailing lists as recipients. Sorry. 
>>>>>>> (Not sure if "sounds" belong to "awt" or "2d".)
>>>>>
>>>>> In fact, there is a sound-specific list, which I've added.
>>>>>
>>>>> -phil.
>>>>>>>
>>>>>>> /Magnus
>>>>>>>
>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>>>>>>> From the bug description:
>>>>>>>>
>>>>>>>> Moving this to a separate bug from JDK-8055190. In 
>>>>>>>> SoundLibraries.gmk, the source code splitting is not complete. 
>>>>>>>> The directory libjsound is used to build not only libjsound but 
>>>>>>>> libjsoundalsa and libjsoundds, and thus needs a complex 
>>>>>>>> include/exclude system like before.
>>>>>>>>
>>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris are 
>>>>>>>> completely clean. On macosx, there's a binary diff (but nothing 
>>>>>>>> else) on libjsound.dylib. On linux, some offset seems to have 
>>>>>>>> changed, which caused a slight change in disass and fulldump 
>>>>>>>> for libjsound.so. I'm not quite sure what's causing it, but I'm 
>>>>>>>> convinced it's harmless.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>>>>>>> WebRev: 
>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 
>>>>>>>>
>>>>>>>>
>>>>>>>> /Magnus
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>


From magnus.ihse.bursie at oracle.com  Thu Mar 15 20:09:06 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 15 Mar 2018 21:09:06 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
	exclude of sound native libraries after source code restructure
In-Reply-To: <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
 <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
 <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>
 <ba7941b1-960d-4c87-6ac8-cb5d045dabeb@oracle.com>
 <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com>
 <a92da605-aad7-5481-7369-b16788e098c6@oracle.com>
 <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com>
Message-ID: <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com>


> 15 mars 2018 kl. 20:13 skrev Phil Race <philip.race at oracle.com>:
> 
> 
> > As far as I know the split was made to dynamically load ALSA/DirectSound stuff
> 
> Yes, I think it is something like that for Linux
> ie if at runtime a dependent-but-not-essential .so was not
> installed it was not fatal. I don't know to what extent this is no longer a
> possible issue, or one that matters.

I have not heard of any mainstream Linux distro in years that was lacking ALSA. 

If ALSA was not present, will the libraries fall back to OSS, or will there be just no sound available?

In any case, I think that whatever Linux distros we're targeting as supported, ALSA will be present. 

Alex, did I understand you correctly that in any case, a separate Windows library is always unnecessary, since we can rely on DirectAudio always being present in our supported versions of Windows?

/Magnus

> 
> -phil.
> 
>> On 03/15/2018 12:06 PM, Alex Menkov wrote:
>> 
>> 
>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote:
>>>> On 2018-03-15 18:23, Phil Race wrote:
>>>> I wondered if that might be the case since it was a "BSD" port .. using X11 ..
>>>> 
>>>> Maybe we should be getting rid of them ?
>>> I agree, we should delete them. I just shuffled them around in the hope that they would be useful for a potential future bsd port, but if/when that happens, we can dig them out from mercurial.
>>> 
>>> A short explanation of how the files moved. The sound library is apparently composed of either a single library (solaris and macosx) or two libraries (linux and windows). Two building blocks, MIDI + ports and DirectAudio is used for all platforms, but they go into either the main library (libjsound) or the helper library.
>>> 
>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go into libjsoundds. On Linux, MIDI+Ports and DirectAudio go into libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio go into the main libjsound.
>>> 
>>> I have no idea why this split is necessary, but this is how the libraries de facto is compiled, and the code needs to match that. If it would be possible to move libjsoundds and libjsoundalsa into libjsound directly, things would be greatly simplified.
>> 
>> As far as I know the split was made to dynamically load ALSA/DirectSound stuff. If it's not available (or old unsupported version is installed), libjsound stuff continues to work (in pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS on Linux).
>> For now Windows (DirectSound) libjsoundds stuff can be merged into libjsound, but I'm not sure we can rely on ALSA is always available on Linux (but most likely if ALSA is not available, libjsound does not provide any functionality, so I suppose libjsoundalsa stuff can be moved to libjsound as well)
>> 
>> --alex
>> 
>>> 
>>> /Magnus
>>> 
>>>> 
>>>> -phil.
>>>> 
>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote:
>>>>> Digging a bit, those files came with the initial Macosx support. It doesn't look like they were ever used.
>>>>> 
>>>>> /Erik
>>>>> 
>>>>> 
>>>>>> On 2018-03-15 09:53, Phil Race wrote:
>>>>>> It is very hard to follow all the moved around files, but one thing
>>>>>> that sticks out is there is a "bsd" directory created and I can't
>>>>>> work out how the files in there are used.
>>>>>> If they are for a BSD port of OpenJDK where is rest of the support for that ?
>>>>>> 
>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote:
>>>>>>> Looks good to me. I tried cleaning this up before but failed to find a reasonable split, but this seems like a good split between common and library specific.
>>>>>>> 
>>>>>>> /Erik
>>>>>>> 
>>>>>>> 
>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>>>>>>>> I forgot to add the client mailing lists as recipients. Sorry. (Not sure if "sounds" belong to "awt" or "2d".)
>>>>>> 
>>>>>> In fact, there is a sound-specific list, which I've added.
>>>>>> 
>>>>>> -phil.
>>>>>>>> 
>>>>>>>> /Magnus
>>>>>>>> 
>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>>>>>>>> From the bug description:
>>>>>>>>> 
>>>>>>>>> Moving this to a separate bug from JDK-8055190. In SoundLibraries.gmk, the source code splitting is not complete. The directory libjsound is used to build not only libjsound but libjsoundalsa and libjsoundds, and thus needs a complex include/exclude system like before.
>>>>>>>>> 
>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris are completely clean. On macosx, there's a binary diff (but nothing else) on libjsound.dylib. On linux, some offset seems to have changed, which caused a slight change in disass and fulldump for libjsound.so. I'm not quite sure what's causing it, but I'm convinced it's harmless.
>>>>>>>>> 
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>>>>>>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 
>>>>>>>>> 
>>>>>>>>> /Magnus
> 


From semyon.sadetsky at oracle.com  Thu Mar 15 20:29:24 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 15 Mar 2018 13:29:24 -0700
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <4a103e51-78aa-a9cc-34f8-d1de5281af95@oracle.com>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
 <46db1312-af5e-42a1-aca4-942798e74df8@default>
 <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>
 <0a2b1ccd-cf94-4c84-8b31-d33415a0e82d@default>
 <ee2a5bd2-9ffd-e322-3281-c0a9f09cf109@oracle.com>
 <040c6d01-16cd-4561-8405-d7ba860fe889@default>
 <4a103e51-78aa-a9cc-34f8-d1de5281af95@oracle.com>
Message-ID: <25dec6b0-105e-e87e-c0b0-ee098c318da4@oracle.com>

I was wrong I see the application context in the test but the test is 
not sufficient to prove anything. You even do not check the final 
dispatching order. Actually it tests nothing. In addition to that the 
test passes before the fix.

The things that need to be explained:

1. Since you get rid of waiting for? FOCUS_LAST + 2. Then for what do 
you continue to enqueue them in lines 244 and 264? They are not needed 
anymore with your fix.

2. Before your fix the logic was: dispatch if the event is in the head 
of the queue otherwise wait for the? FOCUS_LAST + 2 event. After 
dispatching any sequence? event the FOCUS_LAST + 2 is generated to wake 
up the waiting context. Since it is done in the finally block, I didn't 
get how the FOCUS_LAST + 2 may be missed as you are insisting?

3. The special FOCUS_LAST + 2 event was used because the nested event of 
another sequence event should never be dispatched on the same EDT as the 
waiting event otherwise this is a security hole.

In your fix pumpEvents() is directly waiting for a sequence event from 
any application contexts. This means that the nested event belonged to 
another application will be dispatched on the calling EDT?


On 03/15/2018 11:30 AM, Semyon Sadetsky wrote:
> Please understand that you are modifying the mechanism that is 
> responsible for synchronization between different application contexts.
>
> You must prove that you did not broke it with your change. But the 
> provided test contains one context only.
>
> On 03/15/2018 10:30 AM, Krishna Addepalli wrote:
>> Yes, When we create SequencedEvents, only FOCUS_LAST+1 ids are pushed 
>> to the queue, but no event with FOCUS_LAST+2 are pushed. The 
>> order(creation) is maintained by having a static List.
>> There is only one public constructor for SequencedEvents, and it 
>> always creates with FOCUS_LAST + 1 as the id for all the events. So, 
>> there is no event with FOCUS_LAST + 2 being pushed in the context of 
>> a SequencedEvent.,
>>
>> Also, looking at the logic of the code, what we are saying is that 
>> all the SequencedEvents should be processed before any other events 
>> in the event queue. Thanks to Sergey for pointing this one out.
>>
>> My test case already contains two app contexts, and I have posted 
>> events on both, creating a dependency between them. Let me know if 
>> you want me to add more app contexts.
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Thursday, March 15, 2018 10:48 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>> sequenced events
>>
>> On 03/15/2018 10:11 AM, Krishna Addepalli wrote:
>>
>>> If no such event is posted to the queue, it will lead to hang right?
>> Are you sure that the root cause is that there are no such event?
>> I think the event is enqueued but its order is wrong.
>>
>> The test to the fix must contain several application contexts because 
>> this mechanism provides synchronization between contexts.
>>
>> --Semyon
>>> And also, the correct order of processing is not by the event 
>>> number, but rather by the condition check to see if the current 
>>> event is the first event in the separate list maintained for 
>>> SequencedEvents.
>>> Just repeating it for reference:
>>> "edt.pumpEvents(ID, () -> !SequencedEvent.this.isFirstOrDisposed());"
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Thursday, March 15, 2018 10:36 PM
>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>> awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>> sequenced events
>>>
>>> On 03/15/2018 09:59 AM, Krishna Addepalli wrote:
>>>
>>>> Hi Semyon,
>>>>
>>>> SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas 
>>>> when it is dispatching events, it is looking for FOCUS_LAST + 2, 
>>>> which is causing the hang.
>>> I think it correctly waits for FOCUS_LAST + 2 to guaranty the right 
>>> order of processing in which the sequenced event is first processed 
>>> on another EDT.
>>> --Semyon
>>>> I have modified it to look for only FOCUS_LAST + 1 events, which 
>>>> has fixed the problem.
>>>>
>>>> Thanks,
>>>> Krishna
>>>>
>>>> -----Original Message-----
>>>> From: Semyon Sadetsky
>>>> Sent: Thursday, March 15, 2018 9:14 PM
>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>> awt-dev at openjdk.java.net
>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>> sequenced events
>>>>
>>>> Hi Krishna,
>>>>
>>>> You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is 
>>>> absolutely different event.
>>>>
>>>> They can be used interchangeably?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> As per our discussion, I have modified the fix to process only 
>>>>> SequencedEvents and ignore others. I have also modified the test 
>>>>> case to include some dummy events between two SequencedEvents, and 
>>>>> it works.
>>>>> Here is the new webrev:
>>>>> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>>>>>
>>>>> However, could you point me to a doc/spec which says that all the 
>>>>> SequencedEvents have to be processed together, even if other 
>>>>> events in the queue have arrived before?
>>>>>
>>>>> Thanks,
>>>>> Krishna
>>>>>
>>>>> -----Original Message-----
>>>>> From: Krishna Addepalli
>>>>> Sent: Saturday, February 17, 2018 7:57 AM
>>>>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>;
>>>>> awt-dev at openjdk.java.net; Semyon Sadetsky
>>>>> <semyon.sadetsky at oracle.com>
>>>>> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>>> sequenced events
>>>>>
>>>>> Hi Sergey,
>>>>>
>>>>> The event is present, but with the id 
>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is 
>>>>> pumping the events, it is looking for 
>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>>>>>
>>>>> Thanks,
>>>>> Krishna
>>>>>
>>>>> -----Original Message-----
>>>>> From: Sergey Bylokhov
>>>>> Sent: Saturday, February 17, 2018 1:49 AM
>>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>>> awt-dev at openjdk.java.net; Semyon Sadetsky
>>>>> <semyon.sadetsky at oracle.com>
>>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>>> sequenced events
>>>>>
>>>>> Hi, Krishna.
>>>>> On 16/02/2018 00:42, Krishna Addepalli wrote:
>>>>>> The SentEvent.ID value is 
>>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the 
>>>>>> function pumpOneEventForFilters, it tries to call 
>>>>>> EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is 
>>>>>> not present, and then the queue blocks in the hope that someone 
>>>>>> will post that event. This is what is leading to the hang.
>>>>> But both events are posted by the test, why the second event is 
>>>>> not present in the queue?
>>>>>
>>>>>
>


From krishna.addepalli at oracle.com  Fri Mar 16 01:09:42 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 15 Mar 2018 18:09:42 -0700 (PDT)
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <4a103e51-78aa-a9cc-34f8-d1de5281af95@oracle.com>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
 <46db1312-af5e-42a1-aca4-942798e74df8@default>
 <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>
 <0a2b1ccd-cf94-4c84-8b31-d33415a0e82d@default>
 <ee2a5bd2-9ffd-e322-3281-c0a9f09cf109@oracle.com>
 <040c6d01-16cd-4561-8405-d7ba860fe889@default>
 <4a103e51-78aa-a9cc-34f8-d1de5281af95@oracle.com>
Message-ID: <d5d60e6a-81f4-4789-b897-cc9cafa9706a@default>

Yes I understand the change I'm making and also pretty confident about it.

When I said two app contexts, one is created by default, and I have created another one explicitly, which is why I said 2 app contexts.
Event one is posted on the default context, whereas the other two are posted on the newly created context. And I have also added two dummy events between two sequenced events just to make sure that, that case also works.

Thanks,
Krishna

-----Original Message-----
From: Semyon Sadetsky 
Sent: Friday, March 16, 2018 12:01 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events

Please understand that you are modifying the mechanism that is responsible for synchronization between different application contexts.

You must prove that you did not broke it with your change. But the provided test contains one context only.

On 03/15/2018 10:30 AM, Krishna Addepalli wrote:
> Yes, When we create SequencedEvents, only FOCUS_LAST+1 ids are pushed to the queue, but no event with FOCUS_LAST+2 are pushed. The order(creation) is maintained by having a static List.
> There is only one public constructor for SequencedEvents, and it 
> always creates with FOCUS_LAST + 1 as the id for all the events. So, 
> there is no event with FOCUS_LAST + 2 being pushed in the context of a 
> SequencedEvent.,
>
> Also, looking at the logic of the code, what we are saying is that all the SequencedEvents should be processed before any other events in the event queue. Thanks to Sergey for pointing this one out.
>
> My test case already contains two app contexts, and I have posted events on both, creating a dependency between them. Let me know if you want me to add more app contexts.
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Thursday, March 15, 2018 10:48 PM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
> awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
> sequenced events
>
> On 03/15/2018 10:11 AM, Krishna Addepalli wrote:
>
>> If no such event is posted to the queue, it will lead to hang right?
> Are you sure that the root cause is that there are no such event?
> I think the event is enqueued but its order is wrong.
>
> The test to the fix must contain several application contexts because this mechanism provides synchronization between contexts.
>
> --Semyon
>> And also, the correct order of processing is not by the event number, but rather by the condition check to see if the current event is the first event in the separate list maintained for SequencedEvents.
>> Just repeating it for reference:
>> "edt.pumpEvents(ID, () -> !SequencedEvent.this.isFirstOrDisposed());"
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Thursday, March 15, 2018 10:36 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>> sequenced events
>>
>> On 03/15/2018 09:59 AM, Krishna Addepalli wrote:
>>
>>> Hi Semyon,
>>>
>>> SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas when it is dispatching events, it is looking for FOCUS_LAST + 2, which is causing the hang.
>> I think it correctly waits for FOCUS_LAST + 2 to guaranty the right order of processing in which the sequenced event is first processed on another EDT.
>> --Semyon
>>> I have modified it to look for only FOCUS_LAST + 1 events, which has fixed the problem.
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Thursday, March 15, 2018 9:14 PM
>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>> awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>> sequenced events
>>>
>>> Hi Krishna,
>>>
>>> You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is absolutely different event.
>>>
>>> They can be used interchangeably?
>>>
>>> --Semyon
>>>
>>>
>>> On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
>>>> Hi Sergey,
>>>>
>>>> As per our discussion, I have modified the fix to process only SequencedEvents and ignore others. I have also modified the test case to include some dummy events between two SequencedEvents, and it works.
>>>> Here is the new webrev:
>>>> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>>>>
>>>> However, could you point me to a doc/spec which says that all the SequencedEvents have to be processed together, even if other events in the queue have arrived before?
>>>>
>>>> Thanks,
>>>> Krishna
>>>>
>>>> -----Original Message-----
>>>> From: Krishna Addepalli
>>>> Sent: Saturday, February 17, 2018 7:57 AM
>>>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; 
>>>> awt-dev at openjdk.java.net; Semyon Sadetsky 
>>>> <semyon.sadetsky at oracle.com>
>>>> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>>> sequenced events
>>>>
>>>> Hi Sergey,
>>>>
>>>> The event is present, but with the id "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is pumping the events, it is looking for "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>>>>
>>>> Thanks,
>>>> Krishna
>>>>
>>>> -----Original Message-----
>>>> From: Sergey Bylokhov
>>>> Sent: Saturday, February 17, 2018 1:49 AM
>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>>> awt-dev at openjdk.java.net; Semyon Sadetsky 
>>>> <semyon.sadetsky at oracle.com>
>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>>> sequenced events
>>>>
>>>> Hi, Krishna.
>>>> On 16/02/2018 00:42, Krishna Addepalli wrote:
>>>>> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.
>>>> But both events are posted by the test, why the second event is not present in the queue?
>>>>
>>>>


From Sergey.Bylokhov at oracle.com  Fri Mar 16 05:29:30 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 15 Mar 2018 22:29:30 -0700
Subject: <AWT Dev> [11] Review Request: 8198895 Compilation errors in
 java.desktop with VS 2017
Message-ID: <62b4e7e5-c24d-8831-39d5-b529de367a1c@oracle.com>

Hello.
Please review fix for jdk11.

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

VS2017 produces the warnings when we use casts some integral types to 
pointers or use casts of pointers to types.
The fix simply suppress such warnings using the intermediate casts to 
intptr_t(same approach as in JDK-8196884[1])

[1] https://bugs.openjdk.java.net/browse/JDK-8196884

-- 
Best regards, Sergey.

From philip.race at oracle.com  Fri Mar 16 05:55:22 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 15 Mar 2018 22:55:22 -0700
Subject: <AWT Dev> [11] Review Request: 8198895 Compilation errors in
 java.desktop with VS 2017
In-Reply-To: <62b4e7e5-c24d-8831-39d5-b529de367a1c@oracle.com>
References: <62b4e7e5-c24d-8831-39d5-b529de367a1c@oracle.com>
Message-ID: <5AAB5C4A.2040601@oracle.com>

Looks OK .. can you confirm this builds without issue with VS2013 as 
well, and that some
AWT tests that use the components touched are OK ?

-phil

On 3/15/18, 10:29 PM, Sergey Bylokhov wrote:
> Hello.
> Please review fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198895
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8198895/webrev.01
>
> VS2017 produces the warnings when we use casts some integral types to 
> pointers or use casts of pointers to types.
> The fix simply suppress such warnings using the intermediate casts to 
> intptr_t(same approach as in JDK-8196884[1])
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8196884
>

From krishna.addepalli at oracle.com  Fri Mar 16 11:48:29 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 16 Mar 2018 04:48:29 -0700 (PDT)
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <25dec6b0-105e-e87e-c0b0-ee098c318da4@oracle.com>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
 <46db1312-af5e-42a1-aca4-942798e74df8@default>
 <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>
 <0a2b1ccd-cf94-4c84-8b31-d33415a0e82d@default>
 <ee2a5bd2-9ffd-e322-3281-c0a9f09cf109@oracle.com>
 <040c6d01-16cd-4561-8405-d7ba860fe889@default>
 <4a103e51-78aa-a9cc-34f8-d1de5281af95@oracle.com>
 <25dec6b0-105e-e87e-c0b0-ee098c318da4@oracle.com>
Message-ID: <396e6fa0-f984-47b7-a392-a874b025c1cd@default>

Hi Semyon,

Thanks for asking the questions, as it makes my understanding deeper.

"You even do not check the final dispatching order"
I would love to do that. However, I did not find anything in AWTEvent, SentEvent classes, that reliably lets me know that, that event was processed. Let me know if you know of a way and I'll add to the testcase.

"In addition to that the test passes before the fix."
Yes, the test passes before the fix, because of the multiple app contexts. I pointed this one out, long before, when I first sent the review.
However I have modified the test case, which fails before the fix, and passes after the fix. Here it is: http://cr.openjdk.java.net/~kaddepalli/8152974/webrev02/

"1. Since you get rid of waiting for  FOCUS_LAST + 2. Then for what do you continue to enqueue them in lines 244 and 264? They are not needed anymore with your fix."
Possibly. But with my fix they act as dummy events posted to the queue.

"2. Before your fix the logic was: dispatch if the event is in the head of the queue otherwise wait for the  FOCUS_LAST + 2 event. After dispatching any sequence  event the FOCUS_LAST + 2 is generated to wake up the waiting context. Since it is done in the finally block, I didn't get how the FOCUS_LAST + 2 may be missed as you are insisting?"
The problem is, the "dispatch" function gets called on the EDT. So, when it calls edt.pumpEvents, the thread gets blocked, looking for an event with FOCUS_LAST + 2 id, which will only get posted in the finally block. Hence my insistence that the SentEvent doesnot get posted. However, this happens only in the case of a single AppContext, and the events are posted out of order of creation.

"3. The special FOCUS_LAST + 2 event was used because the nested event of another sequence event should never be dispatched on the same EDT as the waiting event otherwise this is a security hole.
In your fix pumpEvents() is directly waiting for a sequence event from any application contexts. This means that the nested event belonged to another application will be dispatched on the calling EDT?"

My fix did not change any of the appcontext waiting logic. Neither was the earlier code doing that. I guess the premise of SequencedEvents itself is that, it synchronizes events across multiple appContexts.

Hope this clarifies your concerns.

Thanks,
Krishna

-----Original Message-----
From: Semyon Sadetsky 
Sent: Friday, March 16, 2018 1:59 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events

I was wrong I see the application context in the test but the test is not sufficient to prove anything. You even do not check the final dispatching order. Actually it tests nothing. In addition to that the test passes before the fix.

The things that need to be explained:

1. Since you get rid of waiting for? FOCUS_LAST + 2. Then for what do you continue to enqueue them in lines 244 and 264? They are not needed anymore with your fix.

2. Before your fix the logic was: dispatch if the event is in the head of the queue otherwise wait for the? FOCUS_LAST + 2 event. After dispatching any sequence? event the FOCUS_LAST + 2 is generated to wake up the waiting context. Since it is done in the finally block, I didn't get how the FOCUS_LAST + 2 may be missed as you are insisting?

3. The special FOCUS_LAST + 2 event was used because the nested event of another sequence event should never be dispatched on the same EDT as the waiting event otherwise this is a security hole.

In your fix pumpEvents() is directly waiting for a sequence event from any application contexts. This means that the nested event belonged to another application will be dispatched on the calling EDT?


On 03/15/2018 11:30 AM, Semyon Sadetsky wrote:
> Please understand that you are modifying the mechanism that is 
> responsible for synchronization between different application contexts.
>
> You must prove that you did not broke it with your change. But the 
> provided test contains one context only.
>
> On 03/15/2018 10:30 AM, Krishna Addepalli wrote:
>> Yes, When we create SequencedEvents, only FOCUS_LAST+1 ids are pushed 
>> to the queue, but no event with FOCUS_LAST+2 are pushed. The
>> order(creation) is maintained by having a static List.
>> There is only one public constructor for SequencedEvents, and it 
>> always creates with FOCUS_LAST + 1 as the id for all the events. So, 
>> there is no event with FOCUS_LAST + 2 being pushed in the context of 
>> a SequencedEvent.,
>>
>> Also, looking at the logic of the code, what we are saying is that 
>> all the SequencedEvents should be processed before any other events 
>> in the event queue. Thanks to Sergey for pointing this one out.
>>
>> My test case already contains two app contexts, and I have posted 
>> events on both, creating a dependency between them. Let me know if 
>> you want me to add more app contexts.
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Thursday, March 15, 2018 10:48 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>> sequenced events
>>
>> On 03/15/2018 10:11 AM, Krishna Addepalli wrote:
>>
>>> If no such event is posted to the queue, it will lead to hang right?
>> Are you sure that the root cause is that there are no such event?
>> I think the event is enqueued but its order is wrong.
>>
>> The test to the fix must contain several application contexts because 
>> this mechanism provides synchronization between contexts.
>>
>> --Semyon
>>> And also, the correct order of processing is not by the event 
>>> number, but rather by the condition check to see if the current 
>>> event is the first event in the separate list maintained for 
>>> SequencedEvents.
>>> Just repeating it for reference:
>>> "edt.pumpEvents(ID, () -> !SequencedEvent.this.isFirstOrDisposed());"
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Thursday, March 15, 2018 10:36 PM
>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>> awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>> sequenced events
>>>
>>> On 03/15/2018 09:59 AM, Krishna Addepalli wrote:
>>>
>>>> Hi Semyon,
>>>>
>>>> SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas 
>>>> when it is dispatching events, it is looking for FOCUS_LAST + 2, 
>>>> which is causing the hang.
>>> I think it correctly waits for FOCUS_LAST + 2 to guaranty the right 
>>> order of processing in which the sequenced event is first processed 
>>> on another EDT.
>>> --Semyon
>>>> I have modified it to look for only FOCUS_LAST + 1 events, which 
>>>> has fixed the problem.
>>>>
>>>> Thanks,
>>>> Krishna
>>>>
>>>> -----Original Message-----
>>>> From: Semyon Sadetsky
>>>> Sent: Thursday, March 15, 2018 9:14 PM
>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>>> awt-dev at openjdk.java.net
>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>>> sequenced events
>>>>
>>>> Hi Krishna,
>>>>
>>>> You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is 
>>>> absolutely different event.
>>>>
>>>> They can be used interchangeably?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> As per our discussion, I have modified the fix to process only 
>>>>> SequencedEvents and ignore others. I have also modified the test 
>>>>> case to include some dummy events between two SequencedEvents, and 
>>>>> it works.
>>>>> Here is the new webrev:
>>>>> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>>>>>
>>>>> However, could you point me to a doc/spec which says that all the 
>>>>> SequencedEvents have to be processed together, even if other 
>>>>> events in the queue have arrived before?
>>>>>
>>>>> Thanks,
>>>>> Krishna
>>>>>
>>>>> -----Original Message-----
>>>>> From: Krishna Addepalli
>>>>> Sent: Saturday, February 17, 2018 7:57 AM
>>>>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; 
>>>>> awt-dev at openjdk.java.net; Semyon Sadetsky 
>>>>> <semyon.sadetsky at oracle.com>
>>>>> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>>>> sequenced events
>>>>>
>>>>> Hi Sergey,
>>>>>
>>>>> The event is present, but with the id 
>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is 
>>>>> pumping the events, it is looking for 
>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>>>>>
>>>>> Thanks,
>>>>> Krishna
>>>>>
>>>>> -----Original Message-----
>>>>> From: Sergey Bylokhov
>>>>> Sent: Saturday, February 17, 2018 1:49 AM
>>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>>>> awt-dev at openjdk.java.net; Semyon Sadetsky 
>>>>> <semyon.sadetsky at oracle.com>
>>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>>>> sequenced events
>>>>>
>>>>> Hi, Krishna.
>>>>> On 16/02/2018 00:42, Krishna Addepalli wrote:
>>>>>> The SentEvent.ID value is
>>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the 
>>>>>> function pumpOneEventForFilters, it tries to call 
>>>>>> EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is 
>>>>>> not present, and then the queue blocks in the hope that someone 
>>>>>> will post that event. This is what is leading to the hang.
>>>>> But both events are posted by the test, why the second event is 
>>>>> not present in the queue?
>>>>>
>>>>>
>


From semyon.sadetsky at oracle.com  Fri Mar 16 15:42:07 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Fri, 16 Mar 2018 08:42:07 -0700
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <d5d60e6a-81f4-4789-b897-cc9cafa9706a@default>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
 <46db1312-af5e-42a1-aca4-942798e74df8@default>
 <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>
 <0a2b1ccd-cf94-4c84-8b31-d33415a0e82d@default>
 <ee2a5bd2-9ffd-e322-3281-c0a9f09cf109@oracle.com>
 <040c6d01-16cd-4561-8405-d7ba860fe889@default>
 <4a103e51-78aa-a9cc-34f8-d1de5281af95@oracle.com>
 <d5d60e6a-81f4-4789-b897-cc9cafa9706a@default>
Message-ID: <2fb231ce-b22f-67ae-7e67-ebabb40f565f@oracle.com>

On 3/15/18 6:09 PM, Krishna Addepalli wrote:

> Yes I understand the change I'm making and also pretty confident about it.
That's funny. And who gave you such strong confidence? Sergey? to whom 
you are so grateful?
I'd better ask him for other ideas because the change should never go 
into the repo.
>
> When I said two app contexts, one is created by default, and I have created another one explicitly, which is why I said 2 app contexts.
> Event one is posted on the default context, whereas the other two are posted on the newly created context. And I have also added two dummy events between two sequenced events just to make sure that, that case also works.
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Semyon Sadetsky
> Sent: Friday, March 16, 2018 12:01 AM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events
>
> Please understand that you are modifying the mechanism that is responsible for synchronization between different application contexts.
>
> You must prove that you did not broke it with your change. But the provided test contains one context only.
>
> On 03/15/2018 10:30 AM, Krishna Addepalli wrote:
>> Yes, When we create SequencedEvents, only FOCUS_LAST+1 ids are pushed to the queue, but no event with FOCUS_LAST+2 are pushed. The order(creation) is maintained by having a static List.
>> There is only one public constructor for SequencedEvents, and it
>> always creates with FOCUS_LAST + 1 as the id for all the events. So,
>> there is no event with FOCUS_LAST + 2 being pushed in the context of a
>> SequencedEvent.,
>>
>> Also, looking at the logic of the code, what we are saying is that all the SequencedEvents should be processed before any other events in the event queue. Thanks to Sergey for pointing this one out.
>>
>> My test case already contains two app contexts, and I have posted events on both, creating a dependency between them. Let me know if you want me to add more app contexts.
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Thursday, March 15, 2018 10:48 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>> awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>> sequenced events
>>
>> On 03/15/2018 10:11 AM, Krishna Addepalli wrote:
>>
>>> If no such event is posted to the queue, it will lead to hang right?
>> Are you sure that the root cause is that there are no such event?
>> I think the event is enqueued but its order is wrong.
>>
>> The test to the fix must contain several application contexts because this mechanism provides synchronization between contexts.
>>
>> --Semyon
>>> And also, the correct order of processing is not by the event number, but rather by the condition check to see if the current event is the first event in the separate list maintained for SequencedEvents.
>>> Just repeating it for reference:
>>> "edt.pumpEvents(ID, () -> !SequencedEvent.this.isFirstOrDisposed());"
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Thursday, March 15, 2018 10:36 PM
>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>> awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>> sequenced events
>>>
>>> On 03/15/2018 09:59 AM, Krishna Addepalli wrote:
>>>
>>>> Hi Semyon,
>>>>
>>>> SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas when it is dispatching events, it is looking for FOCUS_LAST + 2, which is causing the hang.
>>> I think it correctly waits for FOCUS_LAST + 2 to guaranty the right order of processing in which the sequenced event is first processed on another EDT.
>>> --Semyon
>>>> I have modified it to look for only FOCUS_LAST + 1 events, which has fixed the problem.
>>>>
>>>> Thanks,
>>>> Krishna
>>>>
>>>> -----Original Message-----
>>>> From: Semyon Sadetsky
>>>> Sent: Thursday, March 15, 2018 9:14 PM
>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>> awt-dev at openjdk.java.net
>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>> sequenced events
>>>>
>>>> Hi Krishna,
>>>>
>>>> You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is absolutely different event.
>>>>
>>>> They can be used interchangeably?
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> As per our discussion, I have modified the fix to process only SequencedEvents and ignore others. I have also modified the test case to include some dummy events between two SequencedEvents, and it works.
>>>>> Here is the new webrev:
>>>>> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>>>>>
>>>>> However, could you point me to a doc/spec which says that all the SequencedEvents have to be processed together, even if other events in the queue have arrived before?
>>>>>
>>>>> Thanks,
>>>>> Krishna
>>>>>
>>>>> -----Original Message-----
>>>>> From: Krishna Addepalli
>>>>> Sent: Saturday, February 17, 2018 7:57 AM
>>>>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>;
>>>>> awt-dev at openjdk.java.net; Semyon Sadetsky
>>>>> <semyon.sadetsky at oracle.com>
>>>>> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>>> sequenced events
>>>>>
>>>>> Hi Sergey,
>>>>>
>>>>> The event is present, but with the id "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is pumping the events, it is looking for "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>>>>>
>>>>> Thanks,
>>>>> Krishna
>>>>>
>>>>> -----Original Message-----
>>>>> From: Sergey Bylokhov
>>>>> Sent: Saturday, February 17, 2018 1:49 AM
>>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>>> awt-dev at openjdk.java.net; Semyon Sadetsky
>>>>> <semyon.sadetsky at oracle.com>
>>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>>> sequenced events
>>>>>
>>>>> Hi, Krishna.
>>>>> On 16/02/2018 00:42, Krishna Addepalli wrote:
>>>>>> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.
>>>>> But both events are posted by the test, why the second event is not present in the queue?
>>>>>
>>>>>


From alexey.menkov at oracle.com  Fri Mar 16 16:49:22 2018
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Fri, 16 Mar 2018 09:49:22 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
 exclude of sound native libraries after source code restructure
In-Reply-To: <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
 <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
 <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>
 <ba7941b1-960d-4c87-6ac8-cb5d045dabeb@oracle.com>
 <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com>
 <a92da605-aad7-5481-7369-b16788e098c6@oracle.com>
 <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com>
 <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com>
Message-ID: <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com>



On 03/15/2018 13:09, Magnus Ihse Bursie wrote:
> 
>> 15 mars 2018 kl. 20:13 skrev Phil Race <philip.race at oracle.com>:
>>
>>
>>> As far as I know the split was made to dynamically load ALSA/DirectSound stuff
>>
>> Yes, I think it is something like that for Linux
>> ie if at runtime a dependent-but-not-essential .so was not
>> installed it was not fatal. I don't know to what extent this is no longer a
>> possible issue, or one that matters.
> 
> I have not heard of any mainstream Linux distro in years that was lacking ALSA.
> 
> If ALSA was not present, will the libraries fall back to OSS, or will there be just no sound available?

No sound.
OSS support was dropped many years ago (IIRC in jdk7)

> In any case, I think that whatever Linux distros we're targeting as supported, ALSA will be present.
> 
> Alex, did I understand you correctly that in any case, a separate Windows library is always unnecessary, since we can rely on DirectAudio always being present in our supported versions of Windows?

Yes, that's right.
Windows always has DirectSound pre-installed and its version is greater 
than required (IIRC javasoundds requires DirectX 5).

For now failure of libjsound loading is fatal (see 
com.sun.media.sound.Platform.loadLibraries()), loading of extra libs is 
non-fatal.
I believe libjsound loading failure should be made non-fatal, then all 
the functionality will remain the same as we have now.

--alex

> 
> /Magnus
> 
>>
>> -phil.
>>
>>> On 03/15/2018 12:06 PM, Alex Menkov wrote:
>>>
>>>
>>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote:
>>>>> On 2018-03-15 18:23, Phil Race wrote:
>>>>> I wondered if that might be the case since it was a "BSD" port .. using X11 ..
>>>>>
>>>>> Maybe we should be getting rid of them ?
>>>> I agree, we should delete them. I just shuffled them around in the hope that they would be useful for a potential future bsd port, but if/when that happens, we can dig them out from mercurial.
>>>>
>>>> A short explanation of how the files moved. The sound library is apparently composed of either a single library (solaris and macosx) or two libraries (linux and windows). Two building blocks, MIDI + ports and DirectAudio is used for all platforms, but they go into either the main library (libjsound) or the helper library.
>>>>
>>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go into libjsoundds. On Linux, MIDI+Ports and DirectAudio go into libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio go into the main libjsound.
>>>>
>>>> I have no idea why this split is necessary, but this is how the libraries de facto is compiled, and the code needs to match that. If it would be possible to move libjsoundds and libjsoundalsa into libjsound directly, things would be greatly simplified.
>>>
>>> As far as I know the split was made to dynamically load ALSA/DirectSound stuff. If it's not available (or old unsupported version is installed), libjsound stuff continues to work (in pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS on Linux).
>>> For now Windows (DirectSound) libjsoundds stuff can be merged into libjsound, but I'm not sure we can rely on ALSA is always available on Linux (but most likely if ALSA is not available, libjsound does not provide any functionality, so I suppose libjsoundalsa stuff can be moved to libjsound as well)
>>>
>>> --alex
>>>
>>>>
>>>> /Magnus
>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote:
>>>>>> Digging a bit, those files came with the initial Macosx support. It doesn't look like they were ever used.
>>>>>>
>>>>>> /Erik
>>>>>>
>>>>>>
>>>>>>> On 2018-03-15 09:53, Phil Race wrote:
>>>>>>> It is very hard to follow all the moved around files, but one thing
>>>>>>> that sticks out is there is a "bsd" directory created and I can't
>>>>>>> work out how the files in there are used.
>>>>>>> If they are for a BSD port of OpenJDK where is rest of the support for that ?
>>>>>>>
>>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote:
>>>>>>>> Looks good to me. I tried cleaning this up before but failed to find a reasonable split, but this seems like a good split between common and library specific.
>>>>>>>>
>>>>>>>> /Erik
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>>>>>>>>> I forgot to add the client mailing lists as recipients. Sorry. (Not sure if "sounds" belong to "awt" or "2d".)
>>>>>>>
>>>>>>> In fact, there is a sound-specific list, which I've added.
>>>>>>>
>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>> /Magnus
>>>>>>>>>
>>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>>>>>>>>>  From the bug description:
>>>>>>>>>>
>>>>>>>>>> Moving this to a separate bug from JDK-8055190. In SoundLibraries.gmk, the source code splitting is not complete. The directory libjsound is used to build not only libjsound but libjsoundalsa and libjsoundds, and thus needs a complex include/exclude system like before.
>>>>>>>>>>
>>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris are completely clean. On macosx, there's a binary diff (but nothing else) on libjsound.dylib. On linux, some offset seems to have changed, which caused a slight change in disass and fulldump for libjsound.so. I'm not quite sure what's causing it, but I'm convinced it's harmless.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>>>>>>>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01
>>>>>>>>>>
>>>>>>>>>> /Magnus
>>
> 

From Sergey.Bylokhov at oracle.com  Fri Mar 16 16:56:37 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 16 Mar 2018 09:56:37 -0700
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <2fb231ce-b22f-67ae-7e67-ebabb40f565f@oracle.com>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
 <46db1312-af5e-42a1-aca4-942798e74df8@default>
 <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>
 <0a2b1ccd-cf94-4c84-8b31-d33415a0e82d@default>
 <ee2a5bd2-9ffd-e322-3281-c0a9f09cf109@oracle.com>
 <040c6d01-16cd-4561-8405-d7ba860fe889@default>
 <4a103e51-78aa-a9cc-34f8-d1de5281af95@oracle.com>
 <d5d60e6a-81f4-4789-b897-cc9cafa9706a@default>
 <2fb231ce-b22f-67ae-7e67-ebabb40f565f@oracle.com>
Message-ID: <f5d4c212-4500-4327-0466-58a2aa5f5f44@oracle.com>

On 16/03/2018 08:42, semyon.sadetsky at oracle.com wrote:
> That's funny. And who gave you such strong confidence? Sergey? to whom 
> you are so grateful?
> I'd better ask him for other ideas because the change should never go 
> into the repo.

We are grateful to you for your opinion, but you haven't provided the 
reasonable claims, this change corrects the bug (proved by the test), 
works in several appcontext(proved by the test), about what you objects?

>>
>> When I said two app contexts, one is created by default, and I have 
>> created another one explicitly, which is why I said 2 app contexts.
>> Event one is posted on the default context, whereas the other two are 
>> posted on the newly created context. And I have also added two dummy 
>> events between two sequenced events just to make sure that, that case 
>> also works.
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Friday, March 16, 2018 12:01 AM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>> sequenced events
>>
>> Please understand that you are modifying the mechanism that is 
>> responsible for synchronization between different application contexts.
>>
>> You must prove that you did not broke it with your change. But the 
>> provided test contains one context only.
>>
>> On 03/15/2018 10:30 AM, Krishna Addepalli wrote:
>>> Yes, When we create SequencedEvents, only FOCUS_LAST+1 ids are pushed 
>>> to the queue, but no event with FOCUS_LAST+2 are pushed. The 
>>> order(creation) is maintained by having a static List.
>>> There is only one public constructor for SequencedEvents, and it
>>> always creates with FOCUS_LAST + 1 as the id for all the events. So,
>>> there is no event with FOCUS_LAST + 2 being pushed in the context of a
>>> SequencedEvent.,
>>>
>>> Also, looking at the logic of the code, what we are saying is that 
>>> all the SequencedEvents should be processed before any other events 
>>> in the event queue. Thanks to Sergey for pointing this one out.
>>>
>>> My test case already contains two app contexts, and I have posted 
>>> events on both, creating a dependency between them. Let me know if 
>>> you want me to add more app contexts.
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Thursday, March 15, 2018 10:48 PM
>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>> awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>> sequenced events
>>>
>>> On 03/15/2018 10:11 AM, Krishna Addepalli wrote:
>>>
>>>> If no such event is posted to the queue, it will lead to hang right?
>>> Are you sure that the root cause is that there are no such event?
>>> I think the event is enqueued but its order is wrong.
>>>
>>> The test to the fix must contain several application contexts because 
>>> this mechanism provides synchronization between contexts.
>>>
>>> --Semyon
>>>> And also, the correct order of processing is not by the event 
>>>> number, but rather by the condition check to see if the current 
>>>> event is the first event in the separate list maintained for 
>>>> SequencedEvents.
>>>> Just repeating it for reference:
>>>> "edt.pumpEvents(ID, () -> !SequencedEvent.this.isFirstOrDisposed());"
>>>>
>>>> Thanks,
>>>> Krishna
>>>>
>>>> -----Original Message-----
>>>> From: Semyon Sadetsky
>>>> Sent: Thursday, March 15, 2018 10:36 PM
>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>> awt-dev at openjdk.java.net
>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>> sequenced events
>>>>
>>>> On 03/15/2018 09:59 AM, Krishna Addepalli wrote:
>>>>
>>>>> Hi Semyon,
>>>>>
>>>>> SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas 
>>>>> when it is dispatching events, it is looking for FOCUS_LAST + 2, 
>>>>> which is causing the hang.
>>>> I think it correctly waits for FOCUS_LAST + 2 to guaranty the right 
>>>> order of processing in which the sequenced event is first processed 
>>>> on another EDT.
>>>> --Semyon
>>>>> I have modified it to look for only FOCUS_LAST + 1 events, which 
>>>>> has fixed the problem.
>>>>>
>>>>> Thanks,
>>>>> Krishna
>>>>>
>>>>> -----Original Message-----
>>>>> From: Semyon Sadetsky
>>>>> Sent: Thursday, March 15, 2018 9:14 PM
>>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>>> awt-dev at openjdk.java.net
>>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>>> sequenced events
>>>>>
>>>>> Hi Krishna,
>>>>>
>>>>> You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is 
>>>>> absolutely different event.
>>>>>
>>>>> They can be used interchangeably?
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> As per our discussion, I have modified the fix to process only 
>>>>>> SequencedEvents and ignore others. I have also modified the test 
>>>>>> case to include some dummy events between two SequencedEvents, and 
>>>>>> it works.
>>>>>> Here is the new webrev:
>>>>>> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>>>>>>
>>>>>> However, could you point me to a doc/spec which says that all the 
>>>>>> SequencedEvents have to be processed together, even if other 
>>>>>> events in the queue have arrived before?
>>>>>>
>>>>>> Thanks,
>>>>>> Krishna
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Krishna Addepalli
>>>>>> Sent: Saturday, February 17, 2018 7:57 AM
>>>>>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>;
>>>>>> awt-dev at openjdk.java.net; Semyon Sadetsky
>>>>>> <semyon.sadetsky at oracle.com>
>>>>>> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>>>> sequenced events
>>>>>>
>>>>>> Hi Sergey,
>>>>>>
>>>>>> The event is present, but with the id 
>>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is 
>>>>>> pumping the events, it is looking for 
>>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>>>>>>
>>>>>> Thanks,
>>>>>> Krishna
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Sergey Bylokhov
>>>>>> Sent: Saturday, February 17, 2018 1:49 AM
>>>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>>>> awt-dev at openjdk.java.net; Semyon Sadetsky
>>>>>> <semyon.sadetsky at oracle.com>
>>>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>>>> sequenced events
>>>>>>
>>>>>> Hi, Krishna.
>>>>>> On 16/02/2018 00:42, Krishna Addepalli wrote:
>>>>>>> The SentEvent.ID value is 
>>>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the 
>>>>>>> function pumpOneEventForFilters, it tries to call 
>>>>>>> EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is 
>>>>>>> not present, and then the queue blocks in the hope that someone 
>>>>>>> will post that event. This is what is leading to the hang.
>>>>>> But both events are posted by the test, why the second event is 
>>>>>> not present in the queue?
>>>>>>
>>>>>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Mar 16 17:08:43 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 16 Mar 2018 10:08:43 -0700
Subject: <AWT Dev> [11] Review Request: 8198895 Compilation errors in
 java.desktop with VS 2017
In-Reply-To: <5AAB5C4A.2040601@oracle.com>
References: <62b4e7e5-c24d-8831-39d5-b529de367a1c@oracle.com>
 <5AAB5C4A.2040601@oracle.com>
Message-ID: <e294b987-6476-34dd-733d-61cf76d29e40@oracle.com>

On 15/03/2018 22:55, Philip Race wrote:
> Looks OK .. can you confirm this builds without issue with VS2013 as 
> well, and that some

I'll recheck that.

> AWT tests that use the components touched are OK ?

I cannot do that because the build still fails at the end, even for 
openjdk and if "disable-warnings-as-errors" is passed.

> 
> -phil
> 
> On 3/15/18, 10:29 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review fix for jdk11.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198895
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8198895/webrev.01
>>
>> VS2017 produces the warnings when we use casts some integral types to 
>> pointers or use casts of pointers to types.
>> The fix simply suppress such warnings using the intermediate casts to 
>> intptr_t(same approach as in JDK-8196884[1])
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8196884
>>


-- 
Best regards, Sergey.

From philip.race at oracle.com  Fri Mar 16 17:10:46 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 16 Mar 2018 10:10:46 -0700
Subject: <AWT Dev> [11] Review Request: 8198895 Compilation errors in
 java.desktop with VS 2017
In-Reply-To: <e294b987-6476-34dd-733d-61cf76d29e40@oracle.com>
References: <62b4e7e5-c24d-8831-39d5-b529de367a1c@oracle.com>
 <5AAB5C4A.2040601@oracle.com>
 <e294b987-6476-34dd-733d-61cf76d29e40@oracle.com>
Message-ID: <98e2a5b3-cd47-293f-b77b-aac053e4b27f@oracle.com>



On 03/16/2018 10:08 AM, Sergey Bylokhov wrote:
> On 15/03/2018 22:55, Philip Race wrote:
>> Looks OK .. can you confirm this builds without issue with VS2013 as 
>> well, and that some
>
> I'll recheck that.
>
>> AWT tests that use the components touched are OK ?
>
> I cannot do that because the build still fails at the end, even for 
> openjdk and if "disable-warnings-as-errors" is passed.

Oh yes .. well I guess step 1 is we get these build issues fixed.

-phil.

>
>>
>> -phil
>>
>> On 3/15/18, 10:29 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review fix for jdk11.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198895
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8198895/webrev.01
>>>
>>> VS2017 produces the warnings when we use casts some integral types 
>>> to pointers or use casts of pointers to types.
>>> The fix simply suppress such warnings using the intermediate casts 
>>> to intptr_t(same approach as in JDK-8196884[1])
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8196884
>>>
>
>


From philip.race at oracle.com  Fri Mar 16 17:34:52 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 16 Mar 2018 10:34:52 -0700
Subject: <AWT Dev> RFR: 8198649 : Switch AWT/Swing's default GTK version to 3
Message-ID: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8198649
Webrev: http://cr.openjdk.java.net/~prr/8198649/

This is a very small change to switch the default GTK library loaded
from GTK 2.2 to GTK 3.

Both are supported as of JDK 9 but it still defaults to 2.2 and you use
jdk.gtk.version=3 to switch.

Since only one of these can be loaded a switch is necessary in case
auto-detect fails or JDK get to load its version first, but making GTK3 load
by default will help with SWT interop as shown here  where we load
Swing's GTK L+F followed by SWT

---
import javax.swing.UIManager;
import org.eclipse.swt.widgets.Display;

public class SWT_Swing {
  public static void main(String[] args) throws Exception {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
         Display display = new Display();
  }
}

--

/jdk9/bin/java -Djdk.gtk.verbose=true  -cp swt.jar:. SWT_Swing Looking 
for GTK2 library...
GTK2 library loaded.

(java:21435): GLib-GObject-WARNING **: cannot register existing type 
'GdkDisplayManager'

(java:21435): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 
0' failed

(java:21435): GLib-GObject-CRITICAL **: g_object_new: assertion 
'G_TYPE_IS_OBJECT (object_type)' failed

---

As you can see SWT now cannot work since JDK loaded GTK 2.2 by default
and unlike JDK SWT has no detection code or automatic fall back

But with the proposed change we get no error :
~/jdk-11/build/linux-x86_64-normal-server-release/jdk/bin/java 
-Djdk.gtk.verbose=true  -cp swt.jar:. SWT_Swing
Looking for GTK3 library...
GTK3 library loaded.

Granted, the reverse problem would happen for apps that depend on GTK 2.2
but that is looking backwards ..

I have also run the SwingSet2 demo in the various cases and it is fine.

We expect to make the same switch for JavaFX.

-phil.




From krishna.addepalli at oracle.com  Fri Mar 16 17:38:45 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 16 Mar 2018 17:38:45 +0000 (UTC)
Subject: <AWT Dev> RFR: 8198649 : Switch AWT/Swing's default GTK version
 to 3
In-Reply-To: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>
References: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>
Message-ID: <c3607557-05bd-436b-b190-58174a7b22d3@default>

Hi Phil, 

The change looks fine for me.

Thanks,
Krishna

-----Original Message-----
From: Phil Race 
Sent: Friday, March 16, 2018 11:05 PM
To: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
Subject: <AWT Dev> RFR: 8198649 : Switch AWT/Swing's default GTK version to 3

Bug: https://bugs.openjdk.java.net/browse/JDK-8198649
Webrev: http://cr.openjdk.java.net/~prr/8198649/

This is a very small change to switch the default GTK library loaded from GTK 2.2 to GTK 3.

Both are supported as of JDK 9 but it still defaults to 2.2 and you use
jdk.gtk.version=3 to switch.

Since only one of these can be loaded a switch is necessary in case auto-detect fails or JDK get to load its version first, but making GTK3 load by default will help with SWT interop as shown here  where we load Swing's GTK L+F followed by SWT

---
import javax.swing.UIManager;
import org.eclipse.swt.widgets.Display;

public class SWT_Swing {
  public static void main(String[] args) throws Exception { UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
         Display display = new Display();
  }
}

--

/jdk9/bin/java -Djdk.gtk.verbose=true  -cp swt.jar:. SWT_Swing Looking for GTK2 library...
GTK2 library loaded.

(java:21435): GLib-GObject-WARNING **: cannot register existing type 'GdkDisplayManager'

(java:21435): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

(java:21435): GLib-GObject-CRITICAL **: g_object_new: assertion 'G_TYPE_IS_OBJECT (object_type)' failed

---

As you can see SWT now cannot work since JDK loaded GTK 2.2 by default and unlike JDK SWT has no detection code or automatic fall back

But with the proposed change we get no error :
~/jdk-11/build/linux-x86_64-normal-server-release/jdk/bin/java
-Djdk.gtk.verbose=true  -cp swt.jar:. SWT_Swing Looking for GTK3 library...
GTK3 library loaded.

Granted, the reverse problem would happen for apps that depend on GTK 2.2 but that is looking backwards ..

I have also run the SwingSet2 demo in the various cases and it is fine.

We expect to make the same switch for JavaFX.

-phil.




From krishna.addepalli at oracle.com  Fri Mar 16 17:43:21 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 16 Mar 2018 17:43:21 +0000 (UTC)
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <f5d4c212-4500-4327-0466-58a2aa5f5f44@oracle.com>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
 <46db1312-af5e-42a1-aca4-942798e74df8@default>
 <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>
 <0a2b1ccd-cf94-4c84-8b31-d33415a0e82d@default>
 <ee2a5bd2-9ffd-e322-3281-c0a9f09cf109@oracle.com>
 <040c6d01-16cd-4561-8405-d7ba860fe889@default>
 <4a103e51-78aa-a9cc-34f8-d1de5281af95@oracle.com>
 <d5d60e6a-81f4-4789-b897-cc9cafa9706a@default>
 <2fb231ce-b22f-67ae-7e67-ebabb40f565f@oracle.com>
 <f5d4c212-4500-4327-0466-58a2aa5f5f44@oracle.com>
Message-ID: <ada66e30-9358-440e-b8da-537a7e01b2a8@default>

On 16/03/2018 08:42, semyon.sadetsky at oracle.com wrote:
>> That's funny. And who gave you such strong confidence? Sergey? to whom 
>> you are so grateful?
>> I'd better ask him for other ideas because the change should never go 
>> into the repo.

>We are grateful to you for your opinion, but you haven't provided the reasonable claims, this change corrects the bug (proved by >the test), works in several appcontext(proved by the test), about what you objects?


Please see the other mail in which I provide a reason for my insistence of SentEvent not getting pushed to the event queue.
I derived my confidence from debugging the issue. I don?t think I'm wrong there.
As for the fix, mine is a simplistic one, which fixes the issue without much change. If you feel that, it is not sufficient, let me know what else you want to be changed.

PS: I did not see the other mail before I replied to this one.

Thanks,
Krishna

>>
>> When I said two app contexts, one is created by default, and I have 
>> created another one explicitly, which is why I said 2 app contexts.
>> Event one is posted on the default context, whereas the other two are 
>> posted on the newly created context. And I have also added two dummy 
>> events between two sequenced events just to make sure that, that case 
>> also works.
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Semyon Sadetsky
>> Sent: Friday, March 16, 2018 12:01 AM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>> sequenced events
>>
>> Please understand that you are modifying the mechanism that is 
>> responsible for synchronization between different application contexts.
>>
>> You must prove that you did not broke it with your change. But the 
>> provided test contains one context only.
>>
>> On 03/15/2018 10:30 AM, Krishna Addepalli wrote:
>>> Yes, When we create SequencedEvents, only FOCUS_LAST+1 ids are 
>>> pushed to the queue, but no event with FOCUS_LAST+2 are pushed. The
>>> order(creation) is maintained by having a static List.
>>> There is only one public constructor for SequencedEvents, and it 
>>> always creates with FOCUS_LAST + 1 as the id for all the events. So, 
>>> there is no event with FOCUS_LAST + 2 being pushed in the context of 
>>> a SequencedEvent.,
>>>
>>> Also, looking at the logic of the code, what we are saying is that 
>>> all the SequencedEvents should be processed before any other events 
>>> in the event queue. Thanks to Sergey for pointing this one out.
>>>
>>> My test case already contains two app contexts, and I have posted 
>>> events on both, creating a dependency between them. Let me know if 
>>> you want me to add more app contexts.
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Thursday, March 15, 2018 10:48 PM
>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>> awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>> sequenced events
>>>
>>> On 03/15/2018 10:11 AM, Krishna Addepalli wrote:
>>>
>>>> If no such event is posted to the queue, it will lead to hang right?
>>> Are you sure that the root cause is that there are no such event?
>>> I think the event is enqueued but its order is wrong.
>>>
>>> The test to the fix must contain several application contexts 
>>> because this mechanism provides synchronization between contexts.
>>>
>>> --Semyon
>>>> And also, the correct order of processing is not by the event 
>>>> number, but rather by the condition check to see if the current 
>>>> event is the first event in the separate list maintained for 
>>>> SequencedEvents.
>>>> Just repeating it for reference:
>>>> "edt.pumpEvents(ID, () -> !SequencedEvent.this.isFirstOrDisposed());"
>>>>
>>>> Thanks,
>>>> Krishna
>>>>
>>>> -----Original Message-----
>>>> From: Semyon Sadetsky
>>>> Sent: Thursday, March 15, 2018 10:36 PM
>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>>> awt-dev at openjdk.java.net
>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>>> sequenced events
>>>>
>>>> On 03/15/2018 09:59 AM, Krishna Addepalli wrote:
>>>>
>>>>> Hi Semyon,
>>>>>
>>>>> SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas 
>>>>> when it is dispatching events, it is looking for FOCUS_LAST + 2, 
>>>>> which is causing the hang.
>>>> I think it correctly waits for FOCUS_LAST + 2 to guaranty the right 
>>>> order of processing in which the sequenced event is first processed 
>>>> on another EDT.
>>>> --Semyon
>>>>> I have modified it to look for only FOCUS_LAST + 1 events, which 
>>>>> has fixed the problem.
>>>>>
>>>>> Thanks,
>>>>> Krishna
>>>>>
>>>>> -----Original Message-----
>>>>> From: Semyon Sadetsky
>>>>> Sent: Thursday, March 15, 2018 9:14 PM
>>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>>>> awt-dev at openjdk.java.net
>>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>>>> sequenced events
>>>>>
>>>>> Hi Krishna,
>>>>>
>>>>> You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is 
>>>>> absolutely different event.
>>>>>
>>>>> They can be used interchangeably?
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> As per our discussion, I have modified the fix to process only 
>>>>>> SequencedEvents and ignore others. I have also modified the test 
>>>>>> case to include some dummy events between two SequencedEvents, 
>>>>>> and it works.
>>>>>> Here is the new webrev:
>>>>>> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>>>>>>
>>>>>> However, could you point me to a doc/spec which says that all the 
>>>>>> SequencedEvents have to be processed together, even if other 
>>>>>> events in the queue have arrived before?
>>>>>>
>>>>>> Thanks,
>>>>>> Krishna
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Krishna Addepalli
>>>>>> Sent: Saturday, February 17, 2018 7:57 AM
>>>>>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; 
>>>>>> awt-dev at openjdk.java.net; Semyon Sadetsky 
>>>>>> <semyon.sadetsky at oracle.com>
>>>>>> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>>>>> sequenced events
>>>>>>
>>>>>> Hi Sergey,
>>>>>>
>>>>>> The event is present, but with the id 
>>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is 
>>>>>> pumping the events, it is looking for 
>>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>>>>>>
>>>>>> Thanks,
>>>>>> Krishna
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Sergey Bylokhov
>>>>>> Sent: Saturday, February 17, 2018 1:49 AM
>>>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>>>>> awt-dev at openjdk.java.net; Semyon Sadetsky 
>>>>>> <semyon.sadetsky at oracle.com>
>>>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when 
>>>>>> sequenced events
>>>>>>
>>>>>> Hi, Krishna.
>>>>>> On 16/02/2018 00:42, Krishna Addepalli wrote:
>>>>>>> The SentEvent.ID value is
>>>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the 
>>>>>>> function pumpOneEventForFilters, it tries to call 
>>>>>>> EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is 
>>>>>>> not present, and then the queue blocks in the hope that someone 
>>>>>>> will post that event. This is what is leading to the hang.
>>>>>> But both events are posted by the test, why the second event is 
>>>>>> not present in the queue?
>>>>>>
>>>>>>
> 


--
Best regards, Sergey.

From philip.race at oracle.com  Fri Mar 16 18:08:21 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 16 Mar 2018 11:08:21 -0700
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <ada66e30-9358-440e-b8da-537a7e01b2a8@default>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
 <528341f9-53da-4a0c-863f-c4580d7a4db2@default>
 <f8eb7ea5-59c6-4037-86a2-70bf5be49244@default>
 <74b0b7d8-62f1-1b37-3696-237339efc228@oracle.com>
 <46db1312-af5e-42a1-aca4-942798e74df8@default>
 <d524f71c-39e6-d280-6659-ec8a9b3eeb3a@oracle.com>
 <0a2b1ccd-cf94-4c84-8b31-d33415a0e82d@default>
 <ee2a5bd2-9ffd-e322-3281-c0a9f09cf109@oracle.com>
 <040c6d01-16cd-4561-8405-d7ba860fe889@default>
 <4a103e51-78aa-a9cc-34f8-d1de5281af95@oracle.com>
 <d5d60e6a-81f4-4789-b897-cc9cafa9706a@default>
 <2fb231ce-b22f-67ae-7e67-ebabb40f565f@oracle.com>
 <f5d4c212-4500-4327-0466-58a2aa5f5f44@oracle.com>
 <ada66e30-9358-440e-b8da-537a7e01b2a8@default>
Message-ID: <73725414-90a3-6711-f335-549acfe9cdcb@oracle.com>

I think you have done sufficient due diligence here and provided
reasoned explanations.

+1 from me.

-phil.

On 03/16/2018 10:43 AM, Krishna Addepalli wrote:
> On 16/03/2018 08:42, semyon.sadetsky at oracle.com wrote:
>>> That's funny. And who gave you such strong confidence? Sergey? to whom
>>> you are so grateful?
>>> I'd better ask him for other ideas because the change should never go
>>> into the repo.
>> We are grateful to you for your opinion, but you haven't provided the reasonable claims, this change corrects the bug (proved by >the test), works in several appcontext(proved by the test), about what you objects?
>
> Please see the other mail in which I provide a reason for my insistence of SentEvent not getting pushed to the event queue.
> I derived my confidence from debugging the issue. I don?t think I'm wrong there.
> As for the fix, mine is a simplistic one, which fixes the issue without much change. If you feel that, it is not sufficient, let me know what else you want to be changed.
>
> PS: I did not see the other mail before I replied to this one.
>
> Thanks,
> Krishna
>
>>> When I said two app contexts, one is created by default, and I have
>>> created another one explicitly, which is why I said 2 app contexts.
>>> Event one is posted on the default context, whereas the other two are
>>> posted on the newly created context. And I have also added two dummy
>>> events between two sequenced events just to make sure that, that case
>>> also works.
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Friday, March 16, 2018 12:01 AM
>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>> awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>> sequenced events
>>>
>>> Please understand that you are modifying the mechanism that is
>>> responsible for synchronization between different application contexts.
>>>
>>> You must prove that you did not broke it with your change. But the
>>> provided test contains one context only.
>>>
>>> On 03/15/2018 10:30 AM, Krishna Addepalli wrote:
>>>> Yes, When we create SequencedEvents, only FOCUS_LAST+1 ids are
>>>> pushed to the queue, but no event with FOCUS_LAST+2 are pushed. The
>>>> order(creation) is maintained by having a static List.
>>>> There is only one public constructor for SequencedEvents, and it
>>>> always creates with FOCUS_LAST + 1 as the id for all the events. So,
>>>> there is no event with FOCUS_LAST + 2 being pushed in the context of
>>>> a SequencedEvent.,
>>>>
>>>> Also, looking at the logic of the code, what we are saying is that
>>>> all the SequencedEvents should be processed before any other events
>>>> in the event queue. Thanks to Sergey for pointing this one out.
>>>>
>>>> My test case already contains two app contexts, and I have posted
>>>> events on both, creating a dependency between them. Let me know if
>>>> you want me to add more app contexts.
>>>>
>>>> Thanks,
>>>> Krishna
>>>>
>>>> -----Original Message-----
>>>> From: Semyon Sadetsky
>>>> Sent: Thursday, March 15, 2018 10:48 PM
>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>> awt-dev at openjdk.java.net
>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>> sequenced events
>>>>
>>>> On 03/15/2018 10:11 AM, Krishna Addepalli wrote:
>>>>
>>>>> If no such event is posted to the queue, it will lead to hang right?
>>>> Are you sure that the root cause is that there are no such event?
>>>> I think the event is enqueued but its order is wrong.
>>>>
>>>> The test to the fix must contain several application contexts
>>>> because this mechanism provides synchronization between contexts.
>>>>
>>>> --Semyon
>>>>> And also, the correct order of processing is not by the event
>>>>> number, but rather by the condition check to see if the current
>>>>> event is the first event in the separate list maintained for
>>>>> SequencedEvents.
>>>>> Just repeating it for reference:
>>>>> "edt.pumpEvents(ID, () -> !SequencedEvent.this.isFirstOrDisposed());"
>>>>>
>>>>> Thanks,
>>>>> Krishna
>>>>>
>>>>> -----Original Message-----
>>>>> From: Semyon Sadetsky
>>>>> Sent: Thursday, March 15, 2018 10:36 PM
>>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>>> awt-dev at openjdk.java.net
>>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>>> sequenced events
>>>>>
>>>>> On 03/15/2018 09:59 AM, Krishna Addepalli wrote:
>>>>>
>>>>>> Hi Semyon,
>>>>>>
>>>>>> SequencedEvent is created with FOCUS_LAST + 1 as its id, whereas
>>>>>> when it is dispatching events, it is looking for FOCUS_LAST + 2,
>>>>>> which is causing the hang.
>>>>> I think it correctly waits for FOCUS_LAST + 2 to guaranty the right
>>>>> order of processing in which the sequenced event is first processed
>>>>> on another EDT.
>>>>> --Semyon
>>>>>> I have modified it to look for only FOCUS_LAST + 1 events, which
>>>>>> has fixed the problem.
>>>>>>
>>>>>> Thanks,
>>>>>> Krishna
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Semyon Sadetsky
>>>>>> Sent: Thursday, March 15, 2018 9:14 PM
>>>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>>>> awt-dev at openjdk.java.net
>>>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>>>> sequenced events
>>>>>>
>>>>>> Hi Krishna,
>>>>>>
>>>>>> You have replaced FOCUS_LAST+2 with the FOCUS_LAST+1 which is
>>>>>> absolutely different event.
>>>>>>
>>>>>> They can be used interchangeably?
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 03/14/2018 07:53 AM, Krishna Addepalli wrote:
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> As per our discussion, I have modified the fix to process only
>>>>>>> SequencedEvents and ignore others. I have also modified the test
>>>>>>> case to include some dummy events between two SequencedEvents,
>>>>>>> and it works.
>>>>>>> Here is the new webrev:
>>>>>>> http://cr.openjdk.java.net/~kaddepalli/8152974/webrev01/
>>>>>>>
>>>>>>> However, could you point me to a doc/spec which says that all the
>>>>>>> SequencedEvents have to be processed together, even if other
>>>>>>> events in the queue have arrived before?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Krishna
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Krishna Addepalli
>>>>>>> Sent: Saturday, February 17, 2018 7:57 AM
>>>>>>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>;
>>>>>>> awt-dev at openjdk.java.net; Semyon Sadetsky
>>>>>>> <semyon.sadetsky at oracle.com>
>>>>>>> Subject: RE: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>>>>> sequenced events
>>>>>>>
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> The event is present, but with the id
>>>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is
>>>>>>> pumping the events, it is looking for
>>>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Krishna
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Sergey Bylokhov
>>>>>>> Sent: Saturday, February 17, 2018 1:49 AM
>>>>>>> To: Krishna Addepalli <krishna.addepalli at oracle.com>;
>>>>>>> awt-dev at openjdk.java.net; Semyon Sadetsky
>>>>>>> <semyon.sadetsky at oracle.com>
>>>>>>> Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
>>>>>>> sequenced events
>>>>>>>
>>>>>>> Hi, Krishna.
>>>>>>> On 16/02/2018 00:42, Krishna Addepalli wrote:
>>>>>>>> The SentEvent.ID value is
>>>>>>>> "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the
>>>>>>>> function pumpOneEventForFilters, it tries to call
>>>>>>>> EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is
>>>>>>>> not present, and then the queue blocks in the hope that someone
>>>>>>>> will post that event. This is what is leading to the hang.
>>>>>>> But both events are posted by the test, why the second event is
>>>>>>> not present in the queue?
>>>>>>>
>>>>>>>
>
> --
> Best regards, Sergey.


From kevin.rushforth at oracle.com  Fri Mar 16 20:11:10 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 16 Mar 2018 13:11:10 -0700
Subject: <AWT Dev> RFR: 8198649 : Switch AWT/Swing's default GTK version
	to 3
In-Reply-To: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>
References: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>
Message-ID: <5AAC24DE.5020105@oracle.com>

This looks fine to me. I checked FX / Swing interop and it works as 
expected. If there is a mismatch in defaults (which there will be until 
FX switches the default, or after we which when running FX on an older 
JDK), then whichever toolkit loads first will use its default, and then 
the other one will pick up the already loaded library.

-- Kevin


Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198649
> Webrev: http://cr.openjdk.java.net/~prr/8198649/
>
> This is a very small change to switch the default GTK library loaded
> from GTK 2.2 to GTK 3.
>
> Both are supported as of JDK 9 but it still defaults to 2.2 and you use
> jdk.gtk.version=3 to switch.
>
> Since only one of these can be loaded a switch is necessary in case
> auto-detect fails or JDK get to load its version first, but making 
> GTK3 load
> by default will help with SWT interop as shown here  where we load
> Swing's GTK L+F followed by SWT
>
> ---
> import javax.swing.UIManager;
> import org.eclipse.swt.widgets.Display;
>
> public class SWT_Swing {
>  public static void main(String[] args) throws Exception {
> UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
>         Display display = new Display();
>  }
> }
>
> -- 
>
> /jdk9/bin/java -Djdk.gtk.verbose=true  -cp swt.jar:. SWT_Swing Looking 
> for GTK2 library...
> GTK2 library loaded.
>
> (java:21435): GLib-GObject-WARNING **: cannot register existing type 
> 'GdkDisplayManager'
>
> (java:21435): GLib-CRITICAL **: g_once_init_leave: assertion 'result 
> != 0' failed
>
> (java:21435): GLib-GObject-CRITICAL **: g_object_new: assertion 
> 'G_TYPE_IS_OBJECT (object_type)' failed
>
> ---
>
> As you can see SWT now cannot work since JDK loaded GTK 2.2 by default
> and unlike JDK SWT has no detection code or automatic fall back
>
> But with the proposed change we get no error :
> ~/jdk-11/build/linux-x86_64-normal-server-release/jdk/bin/java 
> -Djdk.gtk.verbose=true  -cp swt.jar:. SWT_Swing
> Looking for GTK3 library...
> GTK3 library loaded.
>
> Granted, the reverse problem would happen for apps that depend on GTK 2.2
> but that is looking backwards ..
>
> I have also run the SwingSet2 demo in the various cases and it is fine.
>
> We expect to make the same switch for JavaFX.
>
> -phil.
>
>
>

From prasanta.sadhukhan at oracle.com  Sat Mar 17 07:17:58 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 17 Mar 2018 12:47:58 +0530
Subject: <AWT Dev> <Swing Dev> RFR: 8198649 : Switch AWT/Swing's default
 GTK version to 3
In-Reply-To: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>
References: <da7a00f5-389a-a532-12f0-433063e9aceb@oracle.com>
Message-ID: <9d3e17ab-4a72-d971-52c4-ff0b20e77d6d@oracle.com>

+1

Regards
Prasanta
On 3/16/2018 11:04 PM, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198649
> Webrev: http://cr.openjdk.java.net/~prr/8198649/
>
> This is a very small change to switch the default GTK library loaded
> from GTK 2.2 to GTK 3.
>
> Both are supported as of JDK 9 but it still defaults to 2.2 and you use
> jdk.gtk.version=3 to switch.
>
> Since only one of these can be loaded a switch is necessary in case
> auto-detect fails or JDK get to load its version first, but making 
> GTK3 load
> by default will help with SWT interop as shown here? where we load
> Swing's GTK L+F followed by SWT
>
> ---
> import javax.swing.UIManager;
> import org.eclipse.swt.widgets.Display;
>
> public class SWT_Swing {
> ?public static void main(String[] args) throws Exception {
> UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
> ??????? Display display = new Display();
> ?}
> }
>
> -- 
>
> /jdk9/bin/java -Djdk.gtk.verbose=true? -cp swt.jar:. SWT_Swing Looking 
> for GTK2 library...
> GTK2 library loaded.
>
> (java:21435): GLib-GObject-WARNING **: cannot register existing type 
> 'GdkDisplayManager'
>
> (java:21435): GLib-CRITICAL **: g_once_init_leave: assertion 'result 
> != 0' failed
>
> (java:21435): GLib-GObject-CRITICAL **: g_object_new: assertion 
> 'G_TYPE_IS_OBJECT (object_type)' failed
>
> ---
>
> As you can see SWT now cannot work since JDK loaded GTK 2.2 by default
> and unlike JDK SWT has no detection code or automatic fall back
>
> But with the proposed change we get no error :
> ~/jdk-11/build/linux-x86_64-normal-server-release/jdk/bin/java 
> -Djdk.gtk.verbose=true? -cp swt.jar:. SWT_Swing
> Looking for GTK3 library...
> GTK3 library loaded.
>
> Granted, the reverse problem would happen for apps that depend on GTK 2.2
> but that is looking backwards ..
>
> I have also run the SwingSet2 demo in the various cases and it is fine.
>
> We expect to make the same switch for JavaFX.
>
> -phil.
>
>
>


From dipak.kumar at oracle.com  Mon Mar 19 05:25:53 2018
From: dipak.kumar at oracle.com (Dipak Kumar)
Date: Sun, 18 Mar 2018 22:25:53 -0700 (PDT)
Subject: <AWT Dev> [8u-backport] Review request for 8195738 : scroll
 poistion in ScrollPane is reset after calling validate()
In-Reply-To: <CANmuJ8tWznJW+RrNWQWJP79e4b0-bhFdVVdrOsnoOQAsavR+ng@mail.gmail.com>
References: <10404fdb-0444-4d15-8d09-e7f499cbcb5a@default>
 <CANmuJ8tWznJW+RrNWQWJP79e4b0-bhFdVVdrOsnoOQAsavR+ng@mail.gmail.com>
Message-ID: <035c1dd3-f03a-46d5-88ed-fc7235a1ce76@default>

Hi Patrick,

?

File ?awt_ScrollPane.cpp? has already been reviewed as part of JDK 11. The only difference between JDK 11 changeset and JDK 8 backport is the test file (ScrollPaneValidateTest.java), not awt_ScrollPane.cpp.

I had mentioned that in my previous mail.

?

If at all there is any concern related awt_ScrollPane.cpp file then I think that should be dealt after filing another issue.

?

Moreover I didn't really get your question. Out of two nested if blocks, one has been removed and yes, variables are being used and their declarations are still intact.

?

Please let me know if you need any more info.

?

Thanks,

Dipak

?

From: Patrick Chen [mailto:chen.j.patrick at gmail.com] 
Sent: 14 March 2018 18:21
To: Dipak Kumar <dipak.kumar at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [8u-backport] Review request for 8195738 : scroll poistion in ScrollPane is reset after calling validate()

?

Hi, 

Why in src/windows/native/sun/windows/awt_ScrollPane.cpp did you delete? the main condition?

Means : the two variables are used isn't it ?

?

Cheers,

Pc 

?

2018-03-14 11:02 GMT+01:00 Dipak Kumar <HYPERLINK "mailto:dipak.kumar at oracle.com"dipak.kumar at oracle.com>:

Hi All,

?

Please review the below patch (for 8u-backport) - 

?

Webrev : http://cr.openjdk.java.net/~dkumar/8195738/webrev.00/ ?

JBS : https://bugs.openjdk.java.net/browse/JDK-8195738 ?

JDK 11 changeset - http://hg.openjdk.java.net/jdk/client/rev/96bebffe0be1 

?

Patch pushed for JDK 11 applies cleanly to JDK 8 after adjusting file path except 'headful' keyword has been removed from the test as this is not defined for 8.

Related Jtreg tests have been run against the proposed patch and results are fine.

?

Thanks,

Dipak

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180318/09aa8022/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Mar 19 18:24:33 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Mar 2018 11:24:33 -0700
Subject: <AWT Dev> [11] Review Request: 8198895 Compilation errors in
 java.desktop with VS 2017
In-Reply-To: <e294b987-6476-34dd-733d-61cf76d29e40@oracle.com>
References: <62b4e7e5-c24d-8831-39d5-b529de367a1c@oracle.com>
 <5AAB5C4A.2040601@oracle.com>
 <e294b987-6476-34dd-733d-61cf76d29e40@oracle.com>
Message-ID: <153e6cf6-918b-01ad-9135-b4c4eb580d46@oracle.com>

On 16/03/2018 10:08, Sergey Bylokhov wrote:
> On 15/03/2018 22:55, Philip Race wrote:
>> Looks OK .. can you confirm this builds without issue with VS2013 as 
>> well, and that some
> 
> I'll recheck that.

I have completed a test run of jtreg+jck on the fix using vs2013, no new 
issues were found.

> 
>> AWT tests that use the components touched are OK ?
> 
> I cannot do that because the build still fails at the end, even for 
> openjdk and if "disable-warnings-as-errors" is passed.
> 
>>
>> -phil
>>
>> On 3/15/18, 10:29 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review fix for jdk11.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198895
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8198895/webrev.01
>>>
>>> VS2017 produces the warnings when we use casts some integral types to 
>>> pointers or use casts of pointers to types.
>>> The fix simply suppress such warnings using the intermediate casts to 
>>> intptr_t(same approach as in JDK-8196884[1])
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8196884
>>>
> 
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Mon Mar 19 18:32:02 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 19 Mar 2018 11:32:02 -0700
Subject: <AWT Dev> [11] Review Request: 8198895 Compilation errors in
 java.desktop with VS 2017
In-Reply-To: <153e6cf6-918b-01ad-9135-b4c4eb580d46@oracle.com>
References: <62b4e7e5-c24d-8831-39d5-b529de367a1c@oracle.com>
 <5AAB5C4A.2040601@oracle.com>
 <e294b987-6476-34dd-733d-61cf76d29e40@oracle.com>
 <153e6cf6-918b-01ad-9135-b4c4eb580d46@oracle.com>
Message-ID: <c20ad556-e78c-a097-ac7c-68226a13bbfd@oracle.com>

All good then.

-phil.

On 03/19/2018 11:24 AM, Sergey Bylokhov wrote:
> On 16/03/2018 10:08, Sergey Bylokhov wrote:
>> On 15/03/2018 22:55, Philip Race wrote:
>>> Looks OK .. can you confirm this builds without issue with VS2013 as 
>>> well, and that some
>>
>> I'll recheck that.
>
> I have completed a test run of jtreg+jck on the fix using vs2013, no 
> new issues were found.
>
>>
>>> AWT tests that use the components touched are OK ?
>>
>> I cannot do that because the build still fails at the end, even for 
>> openjdk and if "disable-warnings-as-errors" is passed.
>>
>>>
>>> -phil
>>>
>>> On 3/15/18, 10:29 PM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review fix for jdk11.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198895
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8198895/webrev.01
>>>>
>>>> VS2017 produces the warnings when we use casts some integral types 
>>>> to pointers or use casts of pointers to types.
>>>> The fix simply suppress such warnings using the intermediate casts 
>>>> to intptr_t(same approach as in JDK-8196884[1])
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8196884
>>>>
>>
>>
>
>


From chen.j.patrick at gmail.com  Mon Mar 19 08:35:58 2018
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Mon, 19 Mar 2018 09:35:58 +0100
Subject: <AWT Dev> [8u-backport] Review request for 8195738 : scroll
 poistion in ScrollPane is reset after calling validate()
In-Reply-To: <035c1dd3-f03a-46d5-88ed-fc7235a1ce76@default>
References: <10404fdb-0444-4d15-8d09-e7f499cbcb5a@default>
 <CANmuJ8tWznJW+RrNWQWJP79e4b0-bhFdVVdrOsnoOQAsavR+ng@mail.gmail.com>
 <035c1dd3-f03a-46d5-88ed-fc7235a1ce76@default>
Message-ID: <CANmuJ8tCsuOuXObMO0ZfVYBtBoKbScVzoyTZg-dRUFSJVx4B9Q@mail.gmail.com>

Hi,
I am not to understand why ScrollPane.cpp was changed ?

And why cpp files?

Cheers


2018-03-19 6:25 GMT+01:00 Dipak Kumar <dipak.kumar at oracle.com>:

> Hi Patrick,
>
>
>
> File ?awt_ScrollPane.cpp? has already been reviewed as part of JDK 11. The
> only difference between JDK 11 changeset and JDK 8 backport is the test
> file (ScrollPaneValidateTest.java), not awt_ScrollPane.cpp.
>
> I had mentioned that in my previous mail.
>
>
>
> If at all there is any concern related awt_ScrollPane.cpp file then I
> think that should be dealt after filing another issue.
>
>
>
> Moreover I didn't really get your question. Out of two nested if blocks,
> one has been removed and yes, variables are being used and their
> declarations are still intact.
>
>
>
> Please let me know if you need any more info.
>
>
>
> Thanks,
>
> Dipak
>
>
>
> *From:* Patrick Chen [mailto:chen.j.patrick at gmail.com]
> *Sent:* 14 March 2018 18:21
> *To:* Dipak Kumar <dipak.kumar at oracle.com>
> *Cc:* awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [8u-backport] Review request for 8195738 :
> scroll poistion in ScrollPane is reset after calling validate()
>
>
>
> Hi,
>
> Why in src/windows/native/sun/windows/awt_ScrollPane.cpp did you delete
> the main condition?
>
> Means : the two variables are used isn't it ?
>
>
>
> Cheers,
>
> Pc
>
>
>
> 2018-03-14 11:02 GMT+01:00 Dipak Kumar <dipak.kumar at oracle.com>:
>
> Hi All,
>
>
>
> Please review the below patch (for 8u-backport) -
>
>
>
> Webrev : http://cr.openjdk.java.net/~dkumar/8195738/webrev.00/
>
> JBS : https://bugs.openjdk.java.net/browse/JDK-8195738
>
> JDK 11 changeset - http://hg.openjdk.java.net/jdk/client/rev/96bebffe0be1
>
>
>
> Patch pushed for JDK 11 applies cleanly to JDK 8 after adjusting file path
> except 'headful' keyword has been removed from the test as this is not
> defined for 8.
>
> Related Jtreg tests have been run against the proposed patch and results
> are fine.
>
>
>
> Thanks,
>
> Dipak
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180319/03619063/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Tue Mar 20 03:55:46 2018
From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com)
Date: Tue, 20 Mar 2018 09:25:46 +0530
Subject: <AWT Dev> [8u-backport] Review request for 8195738 : scroll
 poistion in ScrollPane is reset after calling validate()
In-Reply-To: <CANmuJ8tCsuOuXObMO0ZfVYBtBoKbScVzoyTZg-dRUFSJVx4B9Q@mail.gmail.com>
References: <10404fdb-0444-4d15-8d09-e7f499cbcb5a@default>
 <CANmuJ8tWznJW+RrNWQWJP79e4b0-bhFdVVdrOsnoOQAsavR+ng@mail.gmail.com>
 <035c1dd3-f03a-46d5-88ed-fc7235a1ce76@default>
 <CANmuJ8tCsuOuXObMO0ZfVYBtBoKbScVzoyTZg-dRUFSJVx4B9Q@mail.gmail.com>
Message-ID: <e665fe01-00fd-5533-3182-fa1c2636310f@oracle.com>

Hi Patrick, For the case of scroll bar policy as SCROLLBARS_NEVER, we 
used to call SetScrollInfo() with nMin and nMax as zero which used to 
reset the already set value for the scroll bars. There is a better way 
to resolve this by calling ShowScrollBar() and maintain the set size of 
the scroll bar without resetting it.

Since the code that does this job is present in cpp files which calls 
the native api's, they need to be updated to accommodate this fix which 
fixes the JBS bug.

Hope this answers your question and do have a good day.

Thanks and regards,
Shashi


On 19/03/18 2:05 PM, Patrick Chen wrote:
> Hi,
> I am not to understand why ScrollPane.cpp was changed ?
>
> And why cpp files?
>
> Cheers
>
>
> 2018-03-19 6:25 GMT+01:00 Dipak Kumar <dipak.kumar at oracle.com 
> <mailto:dipak.kumar at oracle.com>>:
>
>     Hi Patrick,
>
>     File ?awt_ScrollPane.cpp? has already been reviewed as part of JDK
>     11. The only difference between JDK 11 changeset and JDK 8
>     backport is the test file (ScrollPaneValidateTest.java), not
>     awt_ScrollPane.cpp.
>
>     I had mentioned that in my previous mail.
>
>     If at all there is any concern related awt_ScrollPane.cpp file
>     then I think that should be dealt after filing another issue.
>
>     Moreover I didn't really get your question. Out of two nested if
>     blocks, one has been removed and yes, variables are being used and
>     their declarations are still intact.
>
>     Please let me know if you need any more info.
>
>     Thanks,
>
>     Dipak
>
>     *From:* Patrick Chen [mailto:chen.j.patrick at gmail.com
>     <mailto:chen.j.patrick at gmail.com>]
>     *Sent:* 14 March 2018 18:21
>     *To:* Dipak Kumar <dipak.kumar at oracle.com
>     <mailto:dipak.kumar at oracle.com>>
>     *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> [8u-backport] Review request for 8195738
>     : scroll poistion in ScrollPane is reset after calling validate()
>
>     Hi,
>
>     Why in src/windows/native/sun/windows/awt_ScrollPane.cpp did you
>     delete? the main condition?
>
>     Means : the two variables are used isn't it ?
>
>     Cheers,
>
>     Pc
>
>     2018-03-14 11:02 GMT+01:00 Dipak Kumar <dipak.kumar at oracle.com
>     <mailto:dipak.kumar at oracle.com>>:
>
>         Hi All,
>
>         Please review the below patch (for 8u-backport) -
>
>         Webrev : http://cr.openjdk.java.net/~dkumar/8195738/webrev.00/
>         <http://cr.openjdk.java.net/%7Edkumar/8195738/webrev.00/>
>
>         JBS : https://bugs.openjdk.java.net/browse/JDK-8195738
>         <https://bugs.openjdk.java.net/browse/JDK-8195738>
>
>         JDK 11 changeset -
>         http://hg.openjdk.java.net/jdk/client/rev/96bebffe0be1
>         <http://hg.openjdk.java.net/jdk/client/rev/96bebffe0be1>
>
>         Patch pushed for JDK 11 applies cleanly to JDK 8 after
>         adjusting file path except 'headful' keyword has been removed
>         from the test as this is not defined for 8.
>
>         Related Jtreg tests have been run against the proposed patch
>         and results are fine.
>
>         Thanks,
>
>         Dipak
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180320/cc9ad5fd/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Tue Mar 20 18:48:29 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Mar 2018 11:48:29 -0700
Subject: <AWT Dev> [11] Review Request: 8198335
 java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java
 fails in headless mode
Message-ID: <125498b3-9658-4912-6e9c-b44b021206e4@oracle.com>

Hello.
Please review fix for jdk11.

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

This bug cause the random failures of our headless tests. The reason is 
that we try to notify the 
GraphicsEnvironment(HeadlessGraphicsEnvironment), which does not 
implement DisplayChangedListener, about display change.

It is possible to skip this notification for headlesGE only, but I think 
that it is better to make instanceof before cast to 
DisplayChangedListener, usually we use this pattern in other places.

PS. Note that WToolkit.paletteChanged and WToolkit.displayChanged use 
different threads for notifications, I have created a bug to investigate 
this: https://bugs.openjdk.java.net/browse/JDK-8199881


-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Mar 20 21:26:09 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 20 Mar 2018 14:26:09 -0700
Subject: <AWT Dev> Subject: <AWT dev>[11] Review request for
 JDK-7158623: [macosx] Should an unfocusable maximized Frame be resizable?
In-Reply-To: <870C4A8A-931C-492A-BC97-4D856FEA083E@oracle.com>
References: <D9D0E2F1-34F0-4ACC-B2A4-A8C945D519A8@oracle.com>
 <5A870416.1030009@oracle.com>
 <1506b6ce-01db-ddbb-d00f-6647a62c76fc@oracle.com>
 <0D6F1EFB-65B5-4823-B136-6DE71AA4DA28@oracle.com>
 <870C4A8A-931C-492A-BC97-4D856FEA083E@oracle.com>
Message-ID: <baa2e75c-fa1a-6c5e-e537-249709ca01c0@oracle.com>

Makes sense once I'd looked at the native side.

Approved.

-phil.

On 03/08/2018 01:57 AM, Manajit Halder wrote:
> Hi Phil,
>
> Please find my answers inline:
>
> Before: if its unfocusable, then setStyleBits will set the mask to 0 :
>
> // this is the counter-point to -[CWindow _nativeSetStyleBit:]
> private void setStyleBits(final int mask, final boolean value) {
> execute(ptr -> nativeSetNSWindowStyleBits(ptr, mask, value ? mask : 0));
> }
>
> Before if its unfocusable, then setStyleBits will not set the bits 
> SHOULD_BECOME_KEY and SHOULD_BECOME_MAIN if the window is not focusable.
> While debugging it was observed that the bits set on the window in 
> this case was0000111110000010 (the 9th bit is set, whereas the 12th 
> and 13th bits are not set)
>
> After: .. well exactly the same thing .. you just added a RESIZABLE 
> bit that will be ignored.
>
> Now after my fix RESIZABLE bit along with the other bits won?t be set 
> if the window is not focusable. Bits set on the window in this case 
> was 0000110110000010 (the 9th bit is not set)
>
> The bit setting is done in the native method 
> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowStyleBits.
>
> Thanks,
> Manajit
>
>
>> On 26-Feb-2018, at 1:28 PM, Manajit Halder <manajit.halder at oracle.com 
>> <mailto:manajit.halder at oracle.com>> wrote:
>>
>> Hi Phil and Kevin,
>>
>> Sorry for specifying wrong JDK version. This review is for JDK 11.
>>
>> Regarding spec:
>> It is not mentioned in the focus spec whether the unfocusable 
>> maximized frames should be resizable or not.
>> The fix is given based on the implementation on other platforms 
>> (windows and linux/unix) . On both the platforms (windows and 
>> unix/linux) the test passes whereas the test fails on Mac.
>> An old Issue https://bugs.openjdk.java.net/browse/JDK-4980161 is 
>> related to this fix.
>> Regarding fix:
>> The test case 
>> java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java 
>> fails on Mac and passes on windows and linux/unix.
>> As per the test case when setFocusableWindowState is set to false 
>> frame should not be resizable.
>> updateFocusableWindowState() updates the window focusable state and 
>> the fix under review sets RESIZABLE property to true or false based 
>> on focusability of the frame.
>> Regards,
>> Manajit
>>
>>
>>> webrev appears to be against the correct repo :
>>> sh://hg.openjdk.java.net/jdk/client
>>>
>>>
>>> First can you point to what in the spec. or whatever points to
>>> the correct desired behaviour being what you describe :
>>> >If the frame is focusable then it is resizable otherwise not.
>>>
>>> And regarding the fix, it isn't obvious how adding RESIZABLE changes 
>>> anything here
>>> for the unfocusable case which seems to be the situation that is 
>>> under discussion.
>>>
>>> Before: if its unfocusable, then setStyleBits will set the mask to 0 :
>>>
>>>     // this is the counter-point to -[CWindow _nativeSetStyleBit:]
>>>     private void setStyleBits(final int mask, final boolean value) {
>>>         execute(ptr -> nativeSetNSWindowStyleBits(ptr, mask, value ? 
>>> mask : 0));
>>>     }
>>>
>>> After: .. well exactly the same thing .. you just added a RESIZABLE 
>>> bit that will be ignored.
>>>
>>> It may make a difference in the isFocusable case .. but that does 
>>> not match what you
>>> say you are doing.
>>>
>>> -phil.
>>>
>>> On 02/16/2018 08:17 AM, Kevin Rushforth wrote:
>>>>
>>>> > Kindly review the fix for JDK10.
>>>>
>>>> You mean JDK 11, right?
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> Manajit Halder wrote:
>>>>> Hi All,
>>>>>
>>>>> Kindly review the fix for JDK10.
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-7158623
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mhalder/7158623/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Emhalder/7158623/webrev.00/>
>>>>>
>>>>> Issue:
>>>>> Unfocusable frame was resizable.
>>>>>
>>>>> Fix:
>>>>> After the fix resizability of the frame depends on focusability of 
>>>>> the frame. If the frame is focusable then it is resizable 
>>>>> otherwise not.
>>>>> The test code was cleaned to remove old test machinery code.
>>>>>
>>>>> Regards,
>>>>> Manajit
>>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180320/7ffc7456/attachment-0001.html>

From shashidhara.veerabhadraiah at oracle.com  Wed Mar 21 06:26:50 2018
From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com)
Date: Wed, 21 Mar 2018 11:56:50 +0530
Subject: <AWT Dev> Subject: <AWT dev>[11] Review request for
 JDK-7158623: [macosx] Should an unfocusable maximized Frame be resizable?
In-Reply-To: <baa2e75c-fa1a-6c5e-e537-249709ca01c0@oracle.com>
References: <D9D0E2F1-34F0-4ACC-B2A4-A8C945D519A8@oracle.com>
 <5A870416.1030009@oracle.com>
 <1506b6ce-01db-ddbb-d00f-6647a62c76fc@oracle.com>
 <0D6F1EFB-65B5-4823-B136-6DE71AA4DA28@oracle.com>
 <870C4A8A-931C-492A-BC97-4D856FEA083E@oracle.com>
 <baa2e75c-fa1a-6c5e-e537-249709ca01c0@oracle.com>
Message-ID: <2595923d-9035-f218-1a37-e7404689277b@oracle.com>

The changes looks fine to me.

Thanks and regards,

Shashi


On 21/03/18 2:56 AM, Phil Race wrote:
> Makes sense once I'd looked at the native side.
>
> Approved.
>
> -phil.
>
> On 03/08/2018 01:57 AM, Manajit Halder wrote:
>> Hi Phil,
>>
>> Please find my answers inline:
>>
>> Before: if its unfocusable, then setStyleBits will set the mask to 0 :
>>
>> ??? // this is the counter-point to -[CWindow _nativeSetStyleBit:]
>> ??? private void setStyleBits(final int mask, final boolean value) {
>> ??????? execute(ptr -> nativeSetNSWindowStyleBits(ptr, mask, value ? 
>> mask : 0));
>> ??? }
>>
>> Before if its unfocusable, then setStyleBits will not set the bits 
>> SHOULD_BECOME_KEY and SHOULD_BECOME_MAIN if the window is not focusable.
>> While debugging it was observed that the?bits set on the window in 
>> this case was0000111110000010 (the 9th bit is set, whereas the 12th 
>> and 13th bits are not set)
>>
>> After: .. well exactly the same thing .. you just added a RESIZABLE 
>> bit that will be ignored.
>>
>> Now after my fix RESIZABLE bit along with the other bits?won?t be set 
>> if the window is not focusable. Bits set on the window in this case 
>> was 0000110110000010 (the 9th bit is not set)
>>
>> The bit setting is done in the native method 
>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowStyleBits.
>>
>> Thanks,
>> Manajit
>>
>>
>>> On 26-Feb-2018, at 1:28 PM, Manajit Halder 
>>> <manajit.halder at oracle.com <mailto:manajit.halder at oracle.com>> wrote:
>>>
>>> Hi Phil and Kevin,
>>>
>>> Sorry for specifying wrong JDK version. This review is for JDK 11.
>>>
>>> Regarding spec:
>>> It is not mentioned in the focus spec whether the unfocusable 
>>> maximized frames should be resizable or not.
>>> The fix is given based on the implementation on other platforms 
>>> (windows and linux/unix) . On both the platforms (windows and 
>>> unix/linux) the test passes whereas the test fails on Mac.
>>> An old?Issue https://bugs.openjdk.java.net/browse/JDK-4980161?is 
>>> related to this fix.
>>> Regarding fix:
>>> The test case 
>>> java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java 
>>> fails on Mac and passes on windows and linux/unix.
>>> As per the test case when setFocusableWindowState is set to false 
>>> frame should not be resizable.
>>> updateFocusableWindowState() updates the window focusable state?and 
>>> the fix under review sets RESIZABLE property to true or false based 
>>> on focusability of the frame.
>>> Regards,
>>> Manajit
>>>
>>>
>>>> webrev appears to be against the correct repo :
>>>> sh://hg.openjdk.java.net/jdk/client
>>>>
>>>>
>>>> First can you point to what in the spec. or whatever points to
>>>> the correct desired behaviour being what you describe :
>>>> >If the frame is focusable then it is resizable otherwise not.
>>>>
>>>> And regarding the fix, it isn't obvious how adding RESIZABLE 
>>>> changes anything here
>>>> for the unfocusable case which seems to be the situation that is 
>>>> under discussion.
>>>>
>>>> Before: if its unfocusable, then setStyleBits will set the mask to 0 :
>>>>
>>>> ??? // this is the counter-point to -[CWindow _nativeSetStyleBit:]
>>>> ??? private void setStyleBits(final int mask, final boolean value) {
>>>> ??????? execute(ptr -> nativeSetNSWindowStyleBits(ptr, mask, value 
>>>> ? mask : 0));
>>>> ??? }
>>>>
>>>> After: .. well exactly the same thing .. you just added a RESIZABLE 
>>>> bit that will be ignored.
>>>>
>>>> It may make a difference in the isFocusable case .. but that does 
>>>> not match what you
>>>> say you are doing.
>>>>
>>>> -phil.
>>>>
>>>> On 02/16/2018 08:17 AM, Kevin Rushforth wrote:
>>>>>
>>>>> > Kindly review the fix for JDK10.
>>>>>
>>>>> You mean JDK 11, right?
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>> Manajit Halder wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Kindly review the fix for JDK10.
>>>>>>
>>>>>> Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-7158623
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~mhalder/7158623/webrev.00/ 
>>>>>> <http://cr.openjdk.java.net/%7Emhalder/7158623/webrev.00/>
>>>>>>
>>>>>> Issue:
>>>>>> Unfocusable frame was resizable.
>>>>>>
>>>>>> Fix:
>>>>>> After the fix resizability of the frame depends on focusability 
>>>>>> of the frame. If the frame is focusable then it is resizable 
>>>>>> otherwise not.
>>>>>> The test code was cleaned to remove old test machinery code.
>>>>>>
>>>>>> Regards,
>>>>>> Manajit
>>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180321/4c00854b/attachment-0001.html>

From magnus.ihse.bursie at oracle.com  Wed Mar 21 14:09:52 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 21 Mar 2018 15:09:52 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
 exclude of sound native libraries after source code restructure
In-Reply-To: <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
 <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
 <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>
 <ba7941b1-960d-4c87-6ac8-cb5d045dabeb@oracle.com>
 <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com>
 <a92da605-aad7-5481-7369-b16788e098c6@oracle.com>
 <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com>
 <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com>
 <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com>
Message-ID: <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com>

On 2018-03-16 17:49, Alex Menkov wrote:
>
>
> On 03/15/2018 13:09, Magnus Ihse Bursie wrote:
>>
>>> 15 mars 2018 kl. 20:13 skrev Phil Race <philip.race at oracle.com>:
>>>
>>>
>>>> As far as I know the split was made to dynamically load 
>>>> ALSA/DirectSound stuff
>>>
>>> Yes, I think it is something like that for Linux
>>> ie if at runtime a dependent-but-not-essential .so was not
>>> installed it was not fatal. I don't know to what extent this is no 
>>> longer a
>>> possible issue, or one that matters.
>>
>> I have not heard of any mainstream Linux distro in years that was 
>> lacking ALSA.
>>
>> If ALSA was not present, will the libraries fall back to OSS, or will 
>> there be just no sound available?
>
> No sound.
> OSS support was dropped many years ago (IIRC in jdk7)
>
>> In any case, I think that whatever Linux distros we're targeting as 
>> supported, ALSA will be present.
>>
>> Alex, did I understand you correctly that in any case, a separate 
>> Windows library is always unnecessary, since we can rely on 
>> DirectAudio always being present in our supported versions of Windows?
>
> Yes, that's right.
> Windows always has DirectSound pre-installed and its version is 
> greater than required (IIRC javasoundds requires DirectX 5).
>
> For now failure of libjsound loading is fatal (see 
> com.sun.media.sound.Platform.loadLibraries()), loading of extra libs 
> is non-fatal.
> I believe libjsound loading failure should be made non-fatal, then all 
> the functionality will remain the same as we have now.

Ok.

Here is an updated webrev. I have made the following changes:
* libjavasoundalsa and libjavasoundds is now folded into the main 
libjavasound native library, so there's exactly one library built on all 
platforms.
* Loading of libjsound is made non-fatal.
* I have cleaned out all obvious parts of the code that handle multiple 
libraries. Since loading the native library is now a all-or-nothing 
situation, the checks for various subsystems have been turned into a 
generic check if the native library is loaded.

There is a lot of defines like USE_DSOUND which are always true. This 
could probably be cleaned up further, but it is not a build issue so I'm 
leaving that to the client team to handle.

I have tested the following:
 ?* COMPARE_BUILD shows me just the expected changes in the build.
 ?* On my linux machine, failure to load libjsound.so was not fatal.
 ?* I have looked for sound tests. I found the test/jdk/javax/sound 
suite, which was included in tier3. So I've run tier3 testing on all 
platforms using our internal test system, and all tests pass.

I don't know if there is any other tests I should run. If so, let me know.

Updated webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03

/Magnus

>
> --alex
>
>>
>> /Magnus
>>
>>>
>>> -phil.
>>>
>>>> On 03/15/2018 12:06 PM, Alex Menkov wrote:
>>>>
>>>>
>>>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote:
>>>>>> On 2018-03-15 18:23, Phil Race wrote:
>>>>>> I wondered if that might be the case since it was a "BSD" port .. 
>>>>>> using X11 ..
>>>>>>
>>>>>> Maybe we should be getting rid of them ?
>>>>> I agree, we should delete them. I just shuffled them around in the 
>>>>> hope that they would be useful for a potential future bsd port, 
>>>>> but if/when that happens, we can dig them out from mercurial.
>>>>>
>>>>> A short explanation of how the files moved. The sound library is 
>>>>> apparently composed of either a single library (solaris and 
>>>>> macosx) or two libraries (linux and windows). Two building blocks, 
>>>>> MIDI + ports and DirectAudio is used for all platforms, but they 
>>>>> go into either the main library (libjsound) or the helper library.
>>>>>
>>>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go into 
>>>>> libjsoundds. On Linux, MIDI+Ports and DirectAudio go into 
>>>>> libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio 
>>>>> go into the main libjsound.
>>>>>
>>>>> I have no idea why this split is necessary, but this is how the 
>>>>> libraries de facto is compiled, and the code needs to match that. 
>>>>> If it would be possible to move libjsoundds and libjsoundalsa into 
>>>>> libjsound directly, things would be greatly simplified.
>>>>
>>>> As far as I know the split was made to dynamically load 
>>>> ALSA/DirectSound stuff. If it's not available (or old unsupported 
>>>> version is installed), libjsound stuff continues to work (in 
>>>> pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS 
>>>> on Linux).
>>>> For now Windows (DirectSound) libjsoundds stuff can be merged into 
>>>> libjsound, but I'm not sure we can rely on ALSA is always available 
>>>> on Linux (but most likely if ALSA is not available, libjsound does 
>>>> not provide any functionality, so I suppose libjsoundalsa stuff can 
>>>> be moved to libjsound as well)
>>>>
>>>> --alex
>>>>
>>>>>
>>>>> /Magnus
>>>>>
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote:
>>>>>>> Digging a bit, those files came with the initial Macosx support. 
>>>>>>> It doesn't look like they were ever used.
>>>>>>>
>>>>>>> /Erik
>>>>>>>
>>>>>>>
>>>>>>>> On 2018-03-15 09:53, Phil Race wrote:
>>>>>>>> It is very hard to follow all the moved around files, but one 
>>>>>>>> thing
>>>>>>>> that sticks out is there is a "bsd" directory created and I can't
>>>>>>>> work out how the files in there are used.
>>>>>>>> If they are for a BSD port of OpenJDK where is rest of the 
>>>>>>>> support for that ?
>>>>>>>>
>>>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote:
>>>>>>>>> Looks good to me. I tried cleaning this up before but failed 
>>>>>>>>> to find a reasonable split, but this seems like a good split 
>>>>>>>>> between common and library specific.
>>>>>>>>>
>>>>>>>>> /Erik
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>>>>>>>>>> I forgot to add the client mailing lists as recipients. 
>>>>>>>>>> Sorry. (Not sure if "sounds" belong to "awt" or "2d".)
>>>>>>>>
>>>>>>>> In fact, there is a sound-specific list, which I've added.
>>>>>>>>
>>>>>>>> -phil.
>>>>>>>>>>
>>>>>>>>>> /Magnus
>>>>>>>>>>
>>>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>>>>>>>>>> ?From the bug description:
>>>>>>>>>>>
>>>>>>>>>>> Moving this to a separate bug from JDK-8055190. In 
>>>>>>>>>>> SoundLibraries.gmk, the source code splitting is not 
>>>>>>>>>>> complete. The directory libjsound is used to build not only 
>>>>>>>>>>> libjsound but libjsoundalsa and libjsoundds, and thus needs 
>>>>>>>>>>> a complex include/exclude system like before.
>>>>>>>>>>>
>>>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris 
>>>>>>>>>>> are completely clean. On macosx, there's a binary diff (but 
>>>>>>>>>>> nothing else) on libjsound.dylib. On linux, some offset 
>>>>>>>>>>> seems to have changed, which caused a slight change in 
>>>>>>>>>>> disass and fulldump for libjsound.so. I'm not quite sure 
>>>>>>>>>>> what's causing it, but I'm convinced it's harmless.
>>>>>>>>>>>
>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>>>>>>>>>> WebRev: 
>>>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01
>>>>>>>>>>>
>>>>>>>>>>> /Magnus
>>>
>>


From erik.joelsson at oracle.com  Wed Mar 21 15:22:15 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 21 Mar 2018 08:22:15 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
 exclude of sound native libraries after source code restructure
In-Reply-To: <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
 <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
 <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>
 <ba7941b1-960d-4c87-6ac8-cb5d045dabeb@oracle.com>
 <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com>
 <a92da605-aad7-5481-7369-b16788e098c6@oracle.com>
 <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com>
 <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com>
 <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com>
 <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com>
Message-ID: <bd316c65-2ea1-c6e2-96b4-e1f9ab55eaf5@oracle.com>

Build changes look good.

/Erik


On 2018-03-21 07:09, Magnus Ihse Bursie wrote:
> On 2018-03-16 17:49, Alex Menkov wrote:
>>
>>
>> On 03/15/2018 13:09, Magnus Ihse Bursie wrote:
>>>
>>>> 15 mars 2018 kl. 20:13 skrev Phil Race <philip.race at oracle.com>:
>>>>
>>>>
>>>>> As far as I know the split was made to dynamically load 
>>>>> ALSA/DirectSound stuff
>>>>
>>>> Yes, I think it is something like that for Linux
>>>> ie if at runtime a dependent-but-not-essential .so was not
>>>> installed it was not fatal. I don't know to what extent this is no 
>>>> longer a
>>>> possible issue, or one that matters.
>>>
>>> I have not heard of any mainstream Linux distro in years that was 
>>> lacking ALSA.
>>>
>>> If ALSA was not present, will the libraries fall back to OSS, or 
>>> will there be just no sound available?
>>
>> No sound.
>> OSS support was dropped many years ago (IIRC in jdk7)
>>
>>> In any case, I think that whatever Linux distros we're targeting as 
>>> supported, ALSA will be present.
>>>
>>> Alex, did I understand you correctly that in any case, a separate 
>>> Windows library is always unnecessary, since we can rely on 
>>> DirectAudio always being present in our supported versions of Windows?
>>
>> Yes, that's right.
>> Windows always has DirectSound pre-installed and its version is 
>> greater than required (IIRC javasoundds requires DirectX 5).
>>
>> For now failure of libjsound loading is fatal (see 
>> com.sun.media.sound.Platform.loadLibraries()), loading of extra libs 
>> is non-fatal.
>> I believe libjsound loading failure should be made non-fatal, then 
>> all the functionality will remain the same as we have now.
>
> Ok.
>
> Here is an updated webrev. I have made the following changes:
> * libjavasoundalsa and libjavasoundds is now folded into the main 
> libjavasound native library, so there's exactly one library built on 
> all platforms.
> * Loading of libjsound is made non-fatal.
> * I have cleaned out all obvious parts of the code that handle 
> multiple libraries. Since loading the native library is now a 
> all-or-nothing situation, the checks for various subsystems have been 
> turned into a generic check if the native library is loaded.
>
> There is a lot of defines like USE_DSOUND which are always true. This 
> could probably be cleaned up further, but it is not a build issue so 
> I'm leaving that to the client team to handle.
>
> I have tested the following:
> ?* COMPARE_BUILD shows me just the expected changes in the build.
> ?* On my linux machine, failure to load libjsound.so was not fatal.
> ?* I have looked for sound tests. I found the test/jdk/javax/sound 
> suite, which was included in tier3. So I've run tier3 testing on all 
> platforms using our internal test system, and all tests pass.
>
> I don't know if there is any other tests I should run. If so, let me 
> know.
>
> Updated webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03
>
> /Magnus
>
>>
>> --alex
>>
>>>
>>> /Magnus
>>>
>>>>
>>>> -phil.
>>>>
>>>>> On 03/15/2018 12:06 PM, Alex Menkov wrote:
>>>>>
>>>>>
>>>>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote:
>>>>>>> On 2018-03-15 18:23, Phil Race wrote:
>>>>>>> I wondered if that might be the case since it was a "BSD" port 
>>>>>>> .. using X11 ..
>>>>>>>
>>>>>>> Maybe we should be getting rid of them ?
>>>>>> I agree, we should delete them. I just shuffled them around in 
>>>>>> the hope that they would be useful for a potential future bsd 
>>>>>> port, but if/when that happens, we can dig them out from mercurial.
>>>>>>
>>>>>> A short explanation of how the files moved. The sound library is 
>>>>>> apparently composed of either a single library (solaris and 
>>>>>> macosx) or two libraries (linux and windows). Two building 
>>>>>> blocks, MIDI + ports and DirectAudio is used for all platforms, 
>>>>>> but they go into either the main library (libjsound) or the 
>>>>>> helper library.
>>>>>>
>>>>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go 
>>>>>> into libjsoundds. On Linux, MIDI+Ports and DirectAudio go into 
>>>>>> libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio 
>>>>>> go into the main libjsound.
>>>>>>
>>>>>> I have no idea why this split is necessary, but this is how the 
>>>>>> libraries de facto is compiled, and the code needs to match that. 
>>>>>> If it would be possible to move libjsoundds and libjsoundalsa 
>>>>>> into libjsound directly, things would be greatly simplified.
>>>>>
>>>>> As far as I know the split was made to dynamically load 
>>>>> ALSA/DirectSound stuff. If it's not available (or old unsupported 
>>>>> version is installed), libjsound stuff continues to work (in 
>>>>> pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS 
>>>>> on Linux).
>>>>> For now Windows (DirectSound) libjsoundds stuff can be merged into 
>>>>> libjsound, but I'm not sure we can rely on ALSA is always 
>>>>> available on Linux (but most likely if ALSA is not available, 
>>>>> libjsound does not provide any functionality, so I suppose 
>>>>> libjsoundalsa stuff can be moved to libjsound as well)
>>>>>
>>>>> --alex
>>>>>
>>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote:
>>>>>>>> Digging a bit, those files came with the initial Macosx 
>>>>>>>> support. It doesn't look like they were ever used.
>>>>>>>>
>>>>>>>> /Erik
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 2018-03-15 09:53, Phil Race wrote:
>>>>>>>>> It is very hard to follow all the moved around files, but one 
>>>>>>>>> thing
>>>>>>>>> that sticks out is there is a "bsd" directory created and I can't
>>>>>>>>> work out how the files in there are used.
>>>>>>>>> If they are for a BSD port of OpenJDK where is rest of the 
>>>>>>>>> support for that ?
>>>>>>>>>
>>>>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote:
>>>>>>>>>> Looks good to me. I tried cleaning this up before but failed 
>>>>>>>>>> to find a reasonable split, but this seems like a good split 
>>>>>>>>>> between common and library specific.
>>>>>>>>>>
>>>>>>>>>> /Erik
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>>>>>>>>>>> I forgot to add the client mailing lists as recipients. 
>>>>>>>>>>> Sorry. (Not sure if "sounds" belong to "awt" or "2d".)
>>>>>>>>>
>>>>>>>>> In fact, there is a sound-specific list, which I've added.
>>>>>>>>>
>>>>>>>>> -phil.
>>>>>>>>>>>
>>>>>>>>>>> /Magnus
>>>>>>>>>>>
>>>>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>>>>>>>>>>> ?From the bug description:
>>>>>>>>>>>>
>>>>>>>>>>>> Moving this to a separate bug from JDK-8055190. In 
>>>>>>>>>>>> SoundLibraries.gmk, the source code splitting is not 
>>>>>>>>>>>> complete. The directory libjsound is used to build not only 
>>>>>>>>>>>> libjsound but libjsoundalsa and libjsoundds, and thus needs 
>>>>>>>>>>>> a complex include/exclude system like before.
>>>>>>>>>>>>
>>>>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris 
>>>>>>>>>>>> are completely clean. On macosx, there's a binary diff (but 
>>>>>>>>>>>> nothing else) on libjsound.dylib. On linux, some offset 
>>>>>>>>>>>> seems to have changed, which caused a slight change in 
>>>>>>>>>>>> disass and fulldump for libjsound.so. I'm not quite sure 
>>>>>>>>>>>> what's causing it, but I'm convinced it's harmless.
>>>>>>>>>>>>
>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>>>>>>>>>>> WebRev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01
>>>>>>>>>>>>
>>>>>>>>>>>> /Magnus
>>>>
>>>
>


From alexey.menkov at oracle.com  Wed Mar 21 18:08:07 2018
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Wed, 21 Mar 2018 11:08:07 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
 exclude of sound native libraries after source code restructure
In-Reply-To: <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
 <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
 <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>
 <ba7941b1-960d-4c87-6ac8-cb5d045dabeb@oracle.com>
 <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com>
 <a92da605-aad7-5481-7369-b16788e098c6@oracle.com>
 <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com>
 <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com>
 <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com>
 <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com>
Message-ID: <5860c201-7084-9903-8f9d-73ba7a28ca68@oracle.com>

Hi Magnus,

 > I have tested the following:
 >   * On my linux machine, failure to load libjsound.so was not fatal.

In Platform.java:
   54         loadLibraries();
   55         readProperties();

and readProperties calls native nIsBigEndian

if libjsound loading fails I'd expect nIsBigEndian fails too.

--alex

On 03/21/2018 07:09, Magnus Ihse Bursie wrote:
> On 2018-03-16 17:49, Alex Menkov wrote:
>>
>>
>> On 03/15/2018 13:09, Magnus Ihse Bursie wrote:
>>>
>>>> 15 mars 2018 kl. 20:13 skrev Phil Race <philip.race at oracle.com>:
>>>>
>>>>
>>>>> As far as I know the split was made to dynamically load 
>>>>> ALSA/DirectSound stuff
>>>>
>>>> Yes, I think it is something like that for Linux
>>>> ie if at runtime a dependent-but-not-essential .so was not
>>>> installed it was not fatal. I don't know to what extent this is no 
>>>> longer a
>>>> possible issue, or one that matters.
>>>
>>> I have not heard of any mainstream Linux distro in years that was 
>>> lacking ALSA.
>>>
>>> If ALSA was not present, will the libraries fall back to OSS, or will 
>>> there be just no sound available?
>>
>> No sound.
>> OSS support was dropped many years ago (IIRC in jdk7)
>>
>>> In any case, I think that whatever Linux distros we're targeting as 
>>> supported, ALSA will be present.
>>>
>>> Alex, did I understand you correctly that in any case, a separate 
>>> Windows library is always unnecessary, since we can rely on 
>>> DirectAudio always being present in our supported versions of Windows?
>>
>> Yes, that's right.
>> Windows always has DirectSound pre-installed and its version is 
>> greater than required (IIRC javasoundds requires DirectX 5).
>>
>> For now failure of libjsound loading is fatal (see 
>> com.sun.media.sound.Platform.loadLibraries()), loading of extra libs 
>> is non-fatal.
>> I believe libjsound loading failure should be made non-fatal, then all 
>> the functionality will remain the same as we have now.
> 
> Ok.
> 
> Here is an updated webrev. I have made the following changes:
> * libjavasoundalsa and libjavasoundds is now folded into the main 
> libjavasound native library, so there's exactly one library built on all 
> platforms.
> * Loading of libjsound is made non-fatal.
> * I have cleaned out all obvious parts of the code that handle multiple 
> libraries. Since loading the native library is now a all-or-nothing 
> situation, the checks for various subsystems have been turned into a 
> generic check if the native library is loaded.
> 
> There is a lot of defines like USE_DSOUND which are always true. This 
> could probably be cleaned up further, but it is not a build issue so I'm 
> leaving that to the client team to handle.
> 
> I have tested the following:
>  ?* COMPARE_BUILD shows me just the expected changes in the build.
>  ?* On my linux machine, failure to load libjsound.so was not fatal.
>  ?* I have looked for sound tests. I found the test/jdk/javax/sound 
> suite, which was included in tier3. So I've run tier3 testing on all 
> platforms using our internal test system, and all tests pass.
> 
> I don't know if there is any other tests I should run. If so, let me know.
> 
> Updated webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03
> 
> /Magnus
> 
>>
>> --alex
>>
>>>
>>> /Magnus
>>>
>>>>
>>>> -phil.
>>>>
>>>>> On 03/15/2018 12:06 PM, Alex Menkov wrote:
>>>>>
>>>>>
>>>>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote:
>>>>>>> On 2018-03-15 18:23, Phil Race wrote:
>>>>>>> I wondered if that might be the case since it was a "BSD" port .. 
>>>>>>> using X11 ..
>>>>>>>
>>>>>>> Maybe we should be getting rid of them ?
>>>>>> I agree, we should delete them. I just shuffled them around in the 
>>>>>> hope that they would be useful for a potential future bsd port, 
>>>>>> but if/when that happens, we can dig them out from mercurial.
>>>>>>
>>>>>> A short explanation of how the files moved. The sound library is 
>>>>>> apparently composed of either a single library (solaris and 
>>>>>> macosx) or two libraries (linux and windows). Two building blocks, 
>>>>>> MIDI + ports and DirectAudio is used for all platforms, but they 
>>>>>> go into either the main library (libjsound) or the helper library.
>>>>>>
>>>>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go into 
>>>>>> libjsoundds. On Linux, MIDI+Ports and DirectAudio go into 
>>>>>> libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio 
>>>>>> go into the main libjsound.
>>>>>>
>>>>>> I have no idea why this split is necessary, but this is how the 
>>>>>> libraries de facto is compiled, and the code needs to match that. 
>>>>>> If it would be possible to move libjsoundds and libjsoundalsa into 
>>>>>> libjsound directly, things would be greatly simplified.
>>>>>
>>>>> As far as I know the split was made to dynamically load 
>>>>> ALSA/DirectSound stuff. If it's not available (or old unsupported 
>>>>> version is installed), libjsound stuff continues to work (in 
>>>>> pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS 
>>>>> on Linux).
>>>>> For now Windows (DirectSound) libjsoundds stuff can be merged into 
>>>>> libjsound, but I'm not sure we can rely on ALSA is always available 
>>>>> on Linux (but most likely if ALSA is not available, libjsound does 
>>>>> not provide any functionality, so I suppose libjsoundalsa stuff can 
>>>>> be moved to libjsound as well)
>>>>>
>>>>> --alex
>>>>>
>>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote:
>>>>>>>> Digging a bit, those files came with the initial Macosx support. 
>>>>>>>> It doesn't look like they were ever used.
>>>>>>>>
>>>>>>>> /Erik
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 2018-03-15 09:53, Phil Race wrote:
>>>>>>>>> It is very hard to follow all the moved around files, but one 
>>>>>>>>> thing
>>>>>>>>> that sticks out is there is a "bsd" directory created and I can't
>>>>>>>>> work out how the files in there are used.
>>>>>>>>> If they are for a BSD port of OpenJDK where is rest of the 
>>>>>>>>> support for that ?
>>>>>>>>>
>>>>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote:
>>>>>>>>>> Looks good to me. I tried cleaning this up before but failed 
>>>>>>>>>> to find a reasonable split, but this seems like a good split 
>>>>>>>>>> between common and library specific.
>>>>>>>>>>
>>>>>>>>>> /Erik
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>>>>>>>>>>> I forgot to add the client mailing lists as recipients. 
>>>>>>>>>>> Sorry. (Not sure if "sounds" belong to "awt" or "2d".)
>>>>>>>>>
>>>>>>>>> In fact, there is a sound-specific list, which I've added.
>>>>>>>>>
>>>>>>>>> -phil.
>>>>>>>>>>>
>>>>>>>>>>> /Magnus
>>>>>>>>>>>
>>>>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>>>>>>>>>>> ?From the bug description:
>>>>>>>>>>>>
>>>>>>>>>>>> Moving this to a separate bug from JDK-8055190. In 
>>>>>>>>>>>> SoundLibraries.gmk, the source code splitting is not 
>>>>>>>>>>>> complete. The directory libjsound is used to build not only 
>>>>>>>>>>>> libjsound but libjsoundalsa and libjsoundds, and thus needs 
>>>>>>>>>>>> a complex include/exclude system like before.
>>>>>>>>>>>>
>>>>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and solaris 
>>>>>>>>>>>> are completely clean. On macosx, there's a binary diff (but 
>>>>>>>>>>>> nothing else) on libjsound.dylib. On linux, some offset 
>>>>>>>>>>>> seems to have changed, which caused a slight change in 
>>>>>>>>>>>> disass and fulldump for libjsound.so. I'm not quite sure 
>>>>>>>>>>>> what's causing it, but I'm convinced it's harmless.
>>>>>>>>>>>>
>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>>>>>>>>>>> WebRev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> /Magnus
>>>>
>>>
> 

From magnus.ihse.bursie at oracle.com  Thu Mar 22 07:41:27 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 22 Mar 2018 08:41:27 +0100
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
 exclude of sound native libraries after source code restructure
In-Reply-To: <5860c201-7084-9903-8f9d-73ba7a28ca68@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
 <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
 <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>
 <ba7941b1-960d-4c87-6ac8-cb5d045dabeb@oracle.com>
 <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com>
 <a92da605-aad7-5481-7369-b16788e098c6@oracle.com>
 <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com>
 <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com>
 <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com>
 <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com>
 <5860c201-7084-9903-8f9d-73ba7a28ca68@oracle.com>
Message-ID: <b9dbca53-f503-2f7f-fb88-a9cfc700a2cd@oracle.com>

On 2018-03-21 19:08, Alex Menkov wrote:
> Hi Magnus,
>
> > I have tested the following:
> >?? * On my linux machine, failure to load libjsound.so was not fatal.
>
> In Platform.java:
> ? 54???????? loadLibraries();
> ? 55???????? readProperties();
>
> and readProperties calls native nIsBigEndian
>
> if libjsound loading fails I'd expect nIsBigEndian fails too.

You are absolutely correct. I managed to publish a half-ass fix of 
Platform.java. :-(

Here is the correct version: 
http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.04

/Magnus


>
> --alex
>
> On 03/21/2018 07:09, Magnus Ihse Bursie wrote:
>> On 2018-03-16 17:49, Alex Menkov wrote:
>>>
>>>
>>> On 03/15/2018 13:09, Magnus Ihse Bursie wrote:
>>>>
>>>>> 15 mars 2018 kl. 20:13 skrev Phil Race <philip.race at oracle.com>:
>>>>>
>>>>>
>>>>>> As far as I know the split was made to dynamically load 
>>>>>> ALSA/DirectSound stuff
>>>>>
>>>>> Yes, I think it is something like that for Linux
>>>>> ie if at runtime a dependent-but-not-essential .so was not
>>>>> installed it was not fatal. I don't know to what extent this is no 
>>>>> longer a
>>>>> possible issue, or one that matters.
>>>>
>>>> I have not heard of any mainstream Linux distro in years that was 
>>>> lacking ALSA.
>>>>
>>>> If ALSA was not present, will the libraries fall back to OSS, or 
>>>> will there be just no sound available?
>>>
>>> No sound.
>>> OSS support was dropped many years ago (IIRC in jdk7)
>>>
>>>> In any case, I think that whatever Linux distros we're targeting as 
>>>> supported, ALSA will be present.
>>>>
>>>> Alex, did I understand you correctly that in any case, a separate 
>>>> Windows library is always unnecessary, since we can rely on 
>>>> DirectAudio always being present in our supported versions of Windows?
>>>
>>> Yes, that's right.
>>> Windows always has DirectSound pre-installed and its version is 
>>> greater than required (IIRC javasoundds requires DirectX 5).
>>>
>>> For now failure of libjsound loading is fatal (see 
>>> com.sun.media.sound.Platform.loadLibraries()), loading of extra libs 
>>> is non-fatal.
>>> I believe libjsound loading failure should be made non-fatal, then 
>>> all the functionality will remain the same as we have now.
>>
>> Ok.
>>
>> Here is an updated webrev. I have made the following changes:
>> * libjavasoundalsa and libjavasoundds is now folded into the main 
>> libjavasound native library, so there's exactly one library built on 
>> all platforms.
>> * Loading of libjsound is made non-fatal.
>> * I have cleaned out all obvious parts of the code that handle 
>> multiple libraries. Since loading the native library is now a 
>> all-or-nothing situation, the checks for various subsystems have been 
>> turned into a generic check if the native library is loaded.
>>
>> There is a lot of defines like USE_DSOUND which are always true. This 
>> could probably be cleaned up further, but it is not a build issue so 
>> I'm leaving that to the client team to handle.
>>
>> I have tested the following:
>> ??* COMPARE_BUILD shows me just the expected changes in the build.
>> ??* On my linux machine, failure to load libjsound.so was not fatal.
>> ??* I have looked for sound tests. I found the test/jdk/javax/sound 
>> suite, which was included in tier3. So I've run tier3 testing on all 
>> platforms using our internal test system, and all tests pass.
>>
>> I don't know if there is any other tests I should run. If so, let me 
>> know.
>>
>> Updated webrev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03
>>
>> /Magnus
>>
>>>
>>> --alex
>>>
>>>>
>>>> /Magnus
>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>>>> On 03/15/2018 12:06 PM, Alex Menkov wrote:
>>>>>>
>>>>>>
>>>>>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote:
>>>>>>>> On 2018-03-15 18:23, Phil Race wrote:
>>>>>>>> I wondered if that might be the case since it was a "BSD" port 
>>>>>>>> .. using X11 ..
>>>>>>>>
>>>>>>>> Maybe we should be getting rid of them ?
>>>>>>> I agree, we should delete them. I just shuffled them around in 
>>>>>>> the hope that they would be useful for a potential future bsd 
>>>>>>> port, but if/when that happens, we can dig them out from mercurial.
>>>>>>>
>>>>>>> A short explanation of how the files moved. The sound library is 
>>>>>>> apparently composed of either a single library (solaris and 
>>>>>>> macosx) or two libraries (linux and windows). Two building 
>>>>>>> blocks, MIDI + ports and DirectAudio is used for all platforms, 
>>>>>>> but they go into either the main library (libjsound) or the 
>>>>>>> helper library.
>>>>>>>
>>>>>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go 
>>>>>>> into libjsoundds. On Linux, MIDI+Ports and DirectAudio go into 
>>>>>>> libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio 
>>>>>>> go into the main libjsound.
>>>>>>>
>>>>>>> I have no idea why this split is necessary, but this is how the 
>>>>>>> libraries de facto is compiled, and the code needs to match 
>>>>>>> that. If it would be possible to move libjsoundds and 
>>>>>>> libjsoundalsa into libjsound directly, things would be greatly 
>>>>>>> simplified.
>>>>>>
>>>>>> As far as I know the split was made to dynamically load 
>>>>>> ALSA/DirectSound stuff. If it's not available (or old unsupported 
>>>>>> version is installed), libjsound stuff continues to work (in 
>>>>>> pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS 
>>>>>> on Linux).
>>>>>> For now Windows (DirectSound) libjsoundds stuff can be merged 
>>>>>> into libjsound, but I'm not sure we can rely on ALSA is always 
>>>>>> available on Linux (but most likely if ALSA is not available, 
>>>>>> libjsound does not provide any functionality, so I suppose 
>>>>>> libjsoundalsa stuff can be moved to libjsound as well)
>>>>>>
>>>>>> --alex
>>>>>>
>>>>>>>
>>>>>>> /Magnus
>>>>>>>
>>>>>>>>
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote:
>>>>>>>>> Digging a bit, those files came with the initial Macosx 
>>>>>>>>> support. It doesn't look like they were ever used.
>>>>>>>>>
>>>>>>>>> /Erik
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 2018-03-15 09:53, Phil Race wrote:
>>>>>>>>>> It is very hard to follow all the moved around files, but one 
>>>>>>>>>> thing
>>>>>>>>>> that sticks out is there is a "bsd" directory created and I 
>>>>>>>>>> can't
>>>>>>>>>> work out how the files in there are used.
>>>>>>>>>> If they are for a BSD port of OpenJDK where is rest of the 
>>>>>>>>>> support for that ?
>>>>>>>>>>
>>>>>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote:
>>>>>>>>>>> Looks good to me. I tried cleaning this up before but failed 
>>>>>>>>>>> to find a reasonable split, but this seems like a good split 
>>>>>>>>>>> between common and library specific.
>>>>>>>>>>>
>>>>>>>>>>> /Erik
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>>>>>>>>>>>> I forgot to add the client mailing lists as recipients. 
>>>>>>>>>>>> Sorry. (Not sure if "sounds" belong to "awt" or "2d".)
>>>>>>>>>>
>>>>>>>>>> In fact, there is a sound-specific list, which I've added.
>>>>>>>>>>
>>>>>>>>>> -phil.
>>>>>>>>>>>>
>>>>>>>>>>>> /Magnus
>>>>>>>>>>>>
>>>>>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>>>>>>>>>>>> ?From the bug description:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Moving this to a separate bug from JDK-8055190. In 
>>>>>>>>>>>>> SoundLibraries.gmk, the source code splitting is not 
>>>>>>>>>>>>> complete. The directory libjsound is used to build not 
>>>>>>>>>>>>> only libjsound but libjsoundalsa and libjsoundds, and thus 
>>>>>>>>>>>>> needs a complex include/exclude system like before.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and 
>>>>>>>>>>>>> solaris are completely clean. On macosx, there's a binary 
>>>>>>>>>>>>> diff (but nothing else) on libjsound.dylib. On linux, some 
>>>>>>>>>>>>> offset seems to have changed, which caused a slight change 
>>>>>>>>>>>>> in disass and fulldump for libjsound.so. I'm not quite 
>>>>>>>>>>>>> sure what's causing it, but I'm convinced it's harmless.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>>>>>>>>>>>> WebRev: 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Magnus
>>>>>
>>>>
>>


From alexey.menkov at oracle.com  Thu Mar 22 18:50:57 2018
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Thu, 22 Mar 2018 11:50:57 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and
 exclude of sound native libraries after source code restructure
In-Reply-To: <b9dbca53-f503-2f7f-fb88-a9cfc700a2cd@oracle.com>
References: <828724cd-a9f7-6c47-ef90-1f64bfa384dc@oracle.com>
 <ffa43062-d5ac-73e1-51d9-4576752bb5c9@oracle.com>
 <558ac224-6c96-7d04-05e5-4110b5b4aa69@oracle.com>
 <85c4dfa9-e66f-8b4b-7645-32b4026c32e9@oracle.com>
 <1e70f945-0c4f-1b9f-6bdc-af24cf6815b3@oracle.com>
 <ba7941b1-960d-4c87-6ac8-cb5d045dabeb@oracle.com>
 <25e2965b-67d3-d78a-e0aa-8f039e502bc7@oracle.com>
 <a92da605-aad7-5481-7369-b16788e098c6@oracle.com>
 <99962135-b67a-9ce1-1aca-c6f11971e326@oracle.com>
 <845F9100-6D52-48BB-AD00-81E0FD013C1B@oracle.com>
 <10e31da6-3b9f-f0c1-f874-b2ee9949fe6c@oracle.com>
 <71cfb60f-6df0-db24-69b6-4e1ca8460dd4@oracle.com>
 <5860c201-7084-9903-8f9d-73ba7a28ca68@oracle.com>
 <b9dbca53-f503-2f7f-fb88-a9cfc700a2cd@oracle.com>
Message-ID: <0f62757f-4976-3edd-9e13-f9197afd96f6@oracle.com>

Hi Magnus,

the fix looks good to me.

--alex

On 03/22/2018 00:41, Magnus Ihse Bursie wrote:
> On 2018-03-21 19:08, Alex Menkov wrote:
>> Hi Magnus,
>>
>> > I have tested the following:
>> >?? * On my linux machine, failure to load libjsound.so was not fatal.
>>
>> In Platform.java:
>> ? 54???????? loadLibraries();
>> ? 55???????? readProperties();
>>
>> and readProperties calls native nIsBigEndian
>>
>> if libjsound loading fails I'd expect nIsBigEndian fails too.
> 
> You are absolutely correct. I managed to publish a half-ass fix of 
> Platform.java. :-(
> 
> Here is the correct version: 
> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.04
> 
> /Magnus
> 
> 
>>
>> --alex
>>
>> On 03/21/2018 07:09, Magnus Ihse Bursie wrote:
>>> On 2018-03-16 17:49, Alex Menkov wrote:
>>>>
>>>>
>>>> On 03/15/2018 13:09, Magnus Ihse Bursie wrote:
>>>>>
>>>>>> 15 mars 2018 kl. 20:13 skrev Phil Race <philip.race at oracle.com>:
>>>>>>
>>>>>>
>>>>>>> As far as I know the split was made to dynamically load 
>>>>>>> ALSA/DirectSound stuff
>>>>>>
>>>>>> Yes, I think it is something like that for Linux
>>>>>> ie if at runtime a dependent-but-not-essential .so was not
>>>>>> installed it was not fatal. I don't know to what extent this is no 
>>>>>> longer a
>>>>>> possible issue, or one that matters.
>>>>>
>>>>> I have not heard of any mainstream Linux distro in years that was 
>>>>> lacking ALSA.
>>>>>
>>>>> If ALSA was not present, will the libraries fall back to OSS, or 
>>>>> will there be just no sound available?
>>>>
>>>> No sound.
>>>> OSS support was dropped many years ago (IIRC in jdk7)
>>>>
>>>>> In any case, I think that whatever Linux distros we're targeting as 
>>>>> supported, ALSA will be present.
>>>>>
>>>>> Alex, did I understand you correctly that in any case, a separate 
>>>>> Windows library is always unnecessary, since we can rely on 
>>>>> DirectAudio always being present in our supported versions of Windows?
>>>>
>>>> Yes, that's right.
>>>> Windows always has DirectSound pre-installed and its version is 
>>>> greater than required (IIRC javasoundds requires DirectX 5).
>>>>
>>>> For now failure of libjsound loading is fatal (see 
>>>> com.sun.media.sound.Platform.loadLibraries()), loading of extra libs 
>>>> is non-fatal.
>>>> I believe libjsound loading failure should be made non-fatal, then 
>>>> all the functionality will remain the same as we have now.
>>>
>>> Ok.
>>>
>>> Here is an updated webrev. I have made the following changes:
>>> * libjavasoundalsa and libjavasoundds is now folded into the main 
>>> libjavasound native library, so there's exactly one library built on 
>>> all platforms.
>>> * Loading of libjsound is made non-fatal.
>>> * I have cleaned out all obvious parts of the code that handle 
>>> multiple libraries. Since loading the native library is now a 
>>> all-or-nothing situation, the checks for various subsystems have been 
>>> turned into a generic check if the native library is loaded.
>>>
>>> There is a lot of defines like USE_DSOUND which are always true. This 
>>> could probably be cleaned up further, but it is not a build issue so 
>>> I'm leaving that to the client team to handle.
>>>
>>> I have tested the following:
>>> ??* COMPARE_BUILD shows me just the expected changes in the build.
>>> ??* On my linux machine, failure to load libjsound.so was not fatal.
>>> ??* I have looked for sound tests. I found the test/jdk/javax/sound 
>>> suite, which was included in tier3. So I've run tier3 testing on all 
>>> platforms using our internal test system, and all tests pass.
>>>
>>> I don't know if there is any other tests I should run. If so, let me 
>>> know.
>>>
>>> Updated webrev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03 
>>>
>>>
>>> /Magnus
>>>
>>>>
>>>> --alex
>>>>
>>>>>
>>>>> /Magnus
>>>>>
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>>> On 03/15/2018 12:06 PM, Alex Menkov wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 03/15/2018 11:44, Magnus Ihse Bursie wrote:
>>>>>>>>> On 2018-03-15 18:23, Phil Race wrote:
>>>>>>>>> I wondered if that might be the case since it was a "BSD" port 
>>>>>>>>> .. using X11 ..
>>>>>>>>>
>>>>>>>>> Maybe we should be getting rid of them ?
>>>>>>>> I agree, we should delete them. I just shuffled them around in 
>>>>>>>> the hope that they would be useful for a potential future bsd 
>>>>>>>> port, but if/when that happens, we can dig them out from mercurial.
>>>>>>>>
>>>>>>>> A short explanation of how the files moved. The sound library is 
>>>>>>>> apparently composed of either a single library (solaris and 
>>>>>>>> macosx) or two libraries (linux and windows). Two building 
>>>>>>>> blocks, MIDI + ports and DirectAudio is used for all platforms, 
>>>>>>>> but they go into either the main library (libjsound) or the 
>>>>>>>> helper library.
>>>>>>>>
>>>>>>>> For Windows, MIDI+Ports go into libjsound, and DirectAudio go 
>>>>>>>> into libjsoundds. On Linux, MIDI+Ports and DirectAudio go into 
>>>>>>>> libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio 
>>>>>>>> go into the main libjsound.
>>>>>>>>
>>>>>>>> I have no idea why this split is necessary, but this is how the 
>>>>>>>> libraries de facto is compiled, and the code needs to match 
>>>>>>>> that. If it would be possible to move libjsoundds and 
>>>>>>>> libjsoundalsa into libjsound directly, things would be greatly 
>>>>>>>> simplified.
>>>>>>>
>>>>>>> As far as I know the split was made to dynamically load 
>>>>>>> ALSA/DirectSound stuff. If it's not available (or old unsupported 
>>>>>>> version is installed), libjsound stuff continues to work (in 
>>>>>>> pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS 
>>>>>>> on Linux).
>>>>>>> For now Windows (DirectSound) libjsoundds stuff can be merged 
>>>>>>> into libjsound, but I'm not sure we can rely on ALSA is always 
>>>>>>> available on Linux (but most likely if ALSA is not available, 
>>>>>>> libjsound does not provide any functionality, so I suppose 
>>>>>>> libjsoundalsa stuff can be moved to libjsound as well)
>>>>>>>
>>>>>>> --alex
>>>>>>>
>>>>>>>>
>>>>>>>> /Magnus
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>>> On 03/15/2018 10:21 AM, Erik Joelsson wrote:
>>>>>>>>>> Digging a bit, those files came with the initial Macosx 
>>>>>>>>>> support. It doesn't look like they were ever used.
>>>>>>>>>>
>>>>>>>>>> /Erik
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 2018-03-15 09:53, Phil Race wrote:
>>>>>>>>>>> It is very hard to follow all the moved around files, but one 
>>>>>>>>>>> thing
>>>>>>>>>>> that sticks out is there is a "bsd" directory created and I 
>>>>>>>>>>> can't
>>>>>>>>>>> work out how the files in there are used.
>>>>>>>>>>> If they are for a BSD port of OpenJDK where is rest of the 
>>>>>>>>>>> support for that ?
>>>>>>>>>>>
>>>>>>>>>>>> On 03/15/2018 07:20 AM, Erik Joelsson wrote:
>>>>>>>>>>>> Looks good to me. I tried cleaning this up before but failed 
>>>>>>>>>>>> to find a reasonable split, but this seems like a good split 
>>>>>>>>>>>> between common and library specific.
>>>>>>>>>>>>
>>>>>>>>>>>> /Erik
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
>>>>>>>>>>>>> I forgot to add the client mailing lists as recipients. 
>>>>>>>>>>>>> Sorry. (Not sure if "sounds" belong to "awt" or "2d".)
>>>>>>>>>>>
>>>>>>>>>>> In fact, there is a sound-specific list, which I've added.
>>>>>>>>>>>
>>>>>>>>>>> -phil.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Magnus
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
>>>>>>>>>>>>>> ?From the bug description:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Moving this to a separate bug from JDK-8055190. In 
>>>>>>>>>>>>>> SoundLibraries.gmk, the source code splitting is not 
>>>>>>>>>>>>>> complete. The directory libjsound is used to build not 
>>>>>>>>>>>>>> only libjsound but libjsoundalsa and libjsoundds, and thus 
>>>>>>>>>>>>>> needs a complex include/exclude system like before.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have tested this using COMPARE_BUILD. Windows and 
>>>>>>>>>>>>>> solaris are completely clean. On macosx, there's a binary 
>>>>>>>>>>>>>> diff (but nothing else) on libjsound.dylib. On linux, some 
>>>>>>>>>>>>>> offset seems to have changed, which caused a slight change 
>>>>>>>>>>>>>> in disass and fulldump for libjsound.so. I'm not quite 
>>>>>>>>>>>>>> sure what's causing it, but I'm convinced it's harmless.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
>>>>>>>>>>>>>> WebRev: 
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Magnus
>>>>>>
>>>>>
>>>
> 

From dipak.kumar at oracle.com  Fri Mar 23 07:12:53 2018
From: dipak.kumar at oracle.com (Dipak Kumar)
Date: Fri, 23 Mar 2018 00:12:53 -0700 (PDT)
Subject: <AWT Dev> [8u-backport] Review request for 8195738 : scroll
 poistion in ScrollPane is reset after calling validate()
In-Reply-To: <e665fe01-00fd-5533-3182-fa1c2636310f@oracle.com>
References: <10404fdb-0444-4d15-8d09-e7f499cbcb5a@default>
 <CANmuJ8tWznJW+RrNWQWJP79e4b0-bhFdVVdrOsnoOQAsavR+ng@mail.gmail.com>
 <035c1dd3-f03a-46d5-88ed-fc7235a1ce76@default>
 <CANmuJ8tCsuOuXObMO0ZfVYBtBoKbScVzoyTZg-dRUFSJVx4B9Q@mail.gmail.com>
 <e665fe01-00fd-5533-3182-fa1c2636310f@oracle.com>
Message-ID: <7f697864-ce44-4693-9a17-99f01fc659e6@default>

Just a gentle reminder. Requesting again to review the changes.

?

Thanks,

Dipak

?

From: Shashidhara Veerabhadraiah 
Sent: 20 March 2018 09:26
To: Patrick Chen <chen.j.patrick at gmail.com>; Dipak Kumar <dipak.kumar at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [8u-backport] Review request for 8195738 : scroll poistion in ScrollPane is reset after calling validate()

?

Hi Patrick, For the case of scroll bar policy as SCROLLBARS_NEVER, we used to call SetScrollInfo() with nMin and nMax as zero which used to reset the already set value for the scroll bars. There is a better way to resolve this by calling ShowScrollBar() and maintain the set size of the scroll bar without resetting it.

Since the code that does this job is present in cpp files which calls the native api's, they need to be updated to accommodate this fix which fixes the JBS bug.

Hope this answers your question and do have a good day.

Thanks and regards,
Shashi

?

On 19/03/18 2:05 PM, Patrick Chen wrote:

Hi,

I am not to understand why ScrollPane.cpp was changed ? 

And why cpp files? 

Cheers

?

2018-03-19 6:25 GMT+01:00 Dipak Kumar <HYPERLINK "mailto:dipak.kumar at oracle.com"dipak.kumar at oracle.com>:

Hi Patrick,

?

File ?awt_ScrollPane.cpp? has already been reviewed as part of JDK 11. The only difference between JDK 11 changeset and JDK 8 backport is the test file (ScrollPaneValidateTest.java), not awt_ScrollPane.cpp.

I had mentioned that in my previous mail.

?

If at all there is any concern related awt_ScrollPane.cpp file then I think that should be dealt after filing another issue.

?

Moreover I didn't really get your question. Out of two nested if blocks, one has been removed and yes, variables are being used and their declarations are still intact.

?

Please let me know if you need any more info.

?

Thanks,

Dipak

?

From: Patrick Chen [mailto:HYPERLINK "mailto:chen.j.patrick at gmail.com"chen.j.patrick at gmail.com] 
Sent: 14 March 2018 18:21
To: Dipak Kumar <HYPERLINK "mailto:dipak.kumar at oracle.com"dipak.kumar at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [8u-backport] Review request for 8195738 : scroll poistion in ScrollPane is reset after calling validate()

?

Hi, 

Why in src/windows/native/sun/windows/awt_ScrollPane.cpp did you delete? the main condition?

Means : the two variables are used isn't it ?

?

Cheers,

Pc 

?

2018-03-14 11:02 GMT+01:00 Dipak Kumar <HYPERLINK "mailto:dipak.kumar at oracle.com"dipak.kumar at oracle.com>:

Hi All,

?

Please review the below patch (for 8u-backport) - 

?

Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Edkumar/8195738/webrev.00/"http://cr.openjdk.java.net/~dkumar/8195738/webrev.00/ ?

JBS : https://bugs.openjdk.java.net/browse/JDK-8195738 ?

JDK 11 changeset - http://hg.openjdk.java.net/jdk/client/rev/96bebffe0be1 

?

Patch pushed for JDK 11 applies cleanly to JDK 8 after adjusting file path except 'headful' keyword has been removed from the test as this is not defined for 8.

Related Jtreg tests have been run against the proposed patch and results are fine.

?

Thanks,

Dipak

?

?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180323/e61401d7/attachment-0001.html>

From magnus.ihse.bursie at oracle.com  Fri Mar 23 13:56:34 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 23 Mar 2018 14:56:34 +0100
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native libraries
Message-ID: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>

With modern compilers, we can use compiler directives (such as 
_attribute__((visibility("default"))), or __declspec(dllexport)) to 
control symbol visibility, directly in the source code. This has 
historically not been present on all compilers, so we had to resort to 
using mapfiles (also known as linker scripts).

This is no longer the case. Now all compilers we use support symbol 
visibility directives, in one form or another. We should start using 
this. Since this has been the only way to control symbol visibility on 
Windows, for most of the shared code, we already have proper JNIEXPORT 
decorations in place.

If we fix the remaining platform-specific files to have proper JNIEXPORT 
tagging, then we can finally get rid of mapfiles.

This fix removed mapfiles for all JDK libraries. It does not touch 
hotspot libraries nor JDK executables; they will have to wait for a 
future fix -- this was complex enough. This change will not have any 
impact on macosx, since we do not use mapfiles there, but instead export 
all symbols. (This is not a good idea, but I'll address that 
separately.) This change will also have a minimal impact on Windows. The 
only reason Windows is impacted at all, is that some changes needed by 
Solaris and Linux were simpler to fix for all platforms.

I have strived for this change to have no impact on the actual generated 
code. Unfortunately, this was not possible to fully achieve. I do not 
believe that these changes will have any actual impact on the product, 
though. I will present the differences more in detail further down. 
Those who are not interested can probably skip that.

The patch has passed tier1 testing and is currently running tier2 and 
tier3. Since the running code is more or less (see caveat below) 
unmodified, I don't expect any testing issues.

Bug: https://bugs.openjdk.java.net/browse/JDK-8200178
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01

Details on changes:
Most of the source code changes are (unsurprisingly) in java.base and 
java.desktop. Remaining changes are in jdk.crypto.ucrypto, 
jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent.

Source code changes does almost to 100% consists in decorating an 
exported function with JNIEXPORT. I have also followed the long-standing 
convention of adding JNICALL. This is a no-op on non-Windows platforms, 
so for most of the changes this is purely cosmetic (and possibly adding 
in robustness, should the function ever be used on Windows in the 
future). I have also followed the stylistic convention of putting 
"JNIEXPORT <return type> JNICALL" on a separate line. For some 
functions, however, this might cause a change in calling convention on 
Windows. Since this can not apply to exported functions on Windows 
(otherwise they would already have had JNIEXPORT), I do not think this 
matters anything.

A few libraries did not have a mapfile, on Linux and/or Solaris. This 
actually meant that all symbols were exported. It is highly unclear if 
this was known and intended by the original make rule writer. I have 
emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these 
libraries. Hopefully, we can remove this flag and fix proper exported 
symbols in the future.

I have run the complete build using COMPARE_BUILD, and made a thourough 
analysis of the differences for Linux and Solaris. All native libraries 
have symbol differences, but most of them are trivial and/or harmless. 
As a result, most libraries have disasm differences as well, but these 
too seem trivial and harmless. The differences in symbols that are 
common to all libraries include:
 ?* Internal symbols such as __bss_start, _edata, _end and _fini are now 
global. (They are imported as such from the compiler libraries/archives, 
and we have no linker script to override this behavior).
 ?* The versioning tag SUNWprivate_1.1 is not included, and thus neither 
the .gnu.version_d symbol.
 ?* There are a few differences in the symbol and/or mangling of some 
local functions. I'm not sure what's causing this,
but it's unlikely to have any effect on the product.

Another common source for change in symbols is due to previous platform 
differences. For instance, if we had "JNIEXPORT int JNICALL do_foo() { 
... }", but do_foo was not in the mapfile, the symbol was exported on 
Windows but not on Linux and Solaris. (Presumable since it was not 
needed there, even though it was compiled for those platforms as well.) 
Now, with the mapfiles gone, do_foo() will be exported on all platforms. 
And contrary, functions that are compiled on all platforms, and were 
exported in mapfiles, but now have gotten an JNIEXPORT decoration, will 
now be visible even on Windows. (This accounts for half of the noticed 
symbol differences on Windows.) I could have made the JNIEXPORT 
conditional on OS, but I didn't think the mess in source code were worth 
the keeping of binary confidence with the old build.

A third common source for change in symbols is due to exported functions 
"leaking" across library borders. For instance, some functions in 
java.desktop is compiled in both libawt_xawt and libawt_headless, but 
they were previously only included in the mapfile for one of these 
libraries. Now, since the visibility is determined by the source code 
itself, it gets exported in both libraries. A variant of this is when a 
library depends on another JDK library, and includes the header file 
from that other library, which in turn declares a function as JNIEXPORT. 
This will cause the including library to also export the function. This 
accounts for the other half of the changes on Windows. A typical example 
of this is that multiple libraries now re-export hotspot symbols from 
libjvm.so, like jio_fprintf. (I have not listed the libjvm re-exports 
below.)

Note that? Java_java_io_FileOutputStream_close0 in 
java.base/unix/native/libjava/FileOutputStream_md.c is no longer exported,
and can probably be removed.

Here is a detailed table showing and accounting for all the remaining 
differences found on Linux and Solaris:
java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is 
now also exported on unix platforms due to JNIEXPORT.

java.base/jspawnlauncher: On solaris, we also include 
libjava/childproc.o, which
now exports less functions than it used to (it used to export all 
functions, now it is compiled with visibility=hidden).

java.base/java(w).exe: Is now also exporting the following symbols due 
to added JNIEXPORT in libjli on Windows:
(Yes, executables can export symbols on Windows. Confusing, I know.)
 ?JLI_AddArgsFromEnvVar
 ?JLI_CmdToArgs
 ?JLI_GetAppArgIndex
 ?JLI_GetStdArgc
 ?JLI_GetStdArgs
 ?JLI_InitArgProcessing
 ?JLI_Launch
 ?JLI_List_add
 ?JLI_List_new
 ?JLI_ManifestIterate
 ?JLI_MemAlloc
 ?JLI_MemFree
 ?JLI_PreprocessArg
 ?JLI_ReportErrorMessage
 ?JLI_ReportErrorMessageSys
 ?JLI_ReportExceptionDescription
 ?JLI_ReportMessage
 ?JLI_SetTraceLauncher
 ?JLI_StringDup

java.desktop:/libawt_xawt: The following symbols are now also exported 
on linux and solaris due to JNIEXPORT:
 ?awt_DrawingSurface_FreeDrawingSurfaceInfo
 ?awt_DrawingSurface_GetDrawingSurfaceInfo
 ?awt_DrawingSurface_Lock
 ?awt_DrawingSurface_Unlock
 ?awt_GetColor

The following symbols are now also exported on linux and solaris due to 
JNIEXPORT (they were previously
 ?exported only in libawt):
 ?Java_sun_awt_DebugSettings_setCTracingOn__Z
 ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2
 ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I
 ?Java_sun_awt_X11GraphicsConfig_getNumColors

java.desktop:/libawt_headless: The following symbols are now also 
exported due to JNIEXPORT (they were previously
 ?exported only in libawt_xawt and/or libawt):
 ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo
 ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities
 ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask
 ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable
 ?X11SurfaceData_GetOps

java.desktop/libawt: The following symbols are now also exported on 
Windows, due to added
JNIEXPORT:
 ?SurfaceData_InitOps
 ?mul8table
 ?div8table
 ?doDrawPath
 ?doFillPath
 ?g_CMpDataID
 ?initInverseGrayLut
 ?make_dither_arrays
 ?make_uns_ordered_dither_array
 ?path2DFloatCoordsID
 ?path2DNumTypesID
 ?path2DTypesID
 ?path2DWindingRuleID
 ?sg2dStrokeHintID
 ?std_img_oda_blue
 ?std_img_oda_green
 ?std_img_oda_red
 ?std_odas_computed
 ?sunHints_INTVAL_STROKE_PURE

java.desktop/libawt on solaris:
A number of "#pragma weak" directives was previously overridden by the 
mapfile.
Now these directives are respected, so these symbols are now weak 
instead of local:
 ?ByteGrayToIntArgbPreConvert_F
 ?ByteGrayToIntArgbPreScaleConvert_F
 ?IntArgbBmToFourByteAbgrPreScaleXparOver_F
 ?IntArgbToIntRgbXorBlit_F
 ?IntBgrToIntBgrAlphaMaskBlit_F

java.desktop/libawt on solaris: These are now also exported due to 
JNIEXPORT in libmlib_image.
 ?j2d_mlib_ImageCreate
 ?j2d_mlib_ImageCreateStruct
 ?j2d_mlib_ImageDelete

java.desktop/libawt on solaris: This is now also exported due to JNIEXPORT:
 ?GrPrim_CompGetXorColor
 ?SurfaceData_GetOpsNoSetup
 ?SurfaceData_IntersectBoundsXYWH
 ?SurfaceData_SetOps
 ?Transform_GetInfo
 ?Transform_transform

java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and 
solaris due to JNIEXPORT.
libspashscreen also had JNIEXPORT (actually a pure _declspec(dllexport)) 
but no JNICALL, which I added as
a part of converting to JNIEXPORT. The same goes for libmlib_image .

jdk.sctp/libsctp: handleSocketError is now exported on linux and solaris 
due to JNIEXPORT in libnio.

java.instrument:/libinstrument: Agent_OnUnload is now also exported on 
linux and solaris platforms due to JNIEXPORT.
JLI_ManifestIterate is now also exported on Windows, due to added 
JNIEXPORT in libjli.

jdk.management/libmanagement_ext: 
Java_com_sun_management_internal_Flag_setDoubleValue is now also 
exported on linux and solaris platforms due to JNIEXPORT.

/Magnus



From erik.joelsson at oracle.com  Fri Mar 23 14:30:14 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Mar 2018 07:30:14 -0700
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
Message-ID: <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com>

I have looked at the build changes and they look good.

Will you file followups for each component team to look over their 
exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)? 
It sure looks like there is some technical debt laying around here.

/Erik


On 2018-03-23 06:56, Magnus Ihse Bursie wrote:
> With modern compilers, we can use compiler directives (such as 
> _attribute__((visibility("default"))), or __declspec(dllexport)) to 
> control symbol visibility, directly in the source code. This has 
> historically not been present on all compilers, so we had to resort to 
> using mapfiles (also known as linker scripts).
>
> This is no longer the case. Now all compilers we use support symbol 
> visibility directives, in one form or another. We should start using 
> this. Since this has been the only way to control symbol visibility on 
> Windows, for most of the shared code, we already have proper JNIEXPORT 
> decorations in place.
>
> If we fix the remaining platform-specific files to have proper 
> JNIEXPORT tagging, then we can finally get rid of mapfiles.
>
> This fix removed mapfiles for all JDK libraries. It does not touch 
> hotspot libraries nor JDK executables; they will have to wait for a 
> future fix -- this was complex enough. This change will not have any 
> impact on macosx, since we do not use mapfiles there, but instead 
> export all symbols. (This is not a good idea, but I'll address that 
> separately.) This change will also have a minimal impact on Windows. 
> The only reason Windows is impacted at all, is that some changes 
> needed by Solaris and Linux were simpler to fix for all platforms.
>
> I have strived for this change to have no impact on the actual 
> generated code. Unfortunately, this was not possible to fully achieve. 
> I do not believe that these changes will have any actual impact on the 
> product, though. I will present the differences more in detail further 
> down. Those who are not interested can probably skip that.
>
> The patch has passed tier1 testing and is currently running tier2 and 
> tier3. Since the running code is more or less (see caveat below) 
> unmodified, I don't expect any testing issues.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01
>
> Details on changes:
> Most of the source code changes are (unsurprisingly) in java.base and 
> java.desktop. Remaining changes are in jdk.crypto.ucrypto, 
> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent.
>
> Source code changes does almost to 100% consists in decorating an 
> exported function with JNIEXPORT. I have also followed the 
> long-standing convention of adding JNICALL. This is a no-op on 
> non-Windows platforms, so for most of the changes this is purely 
> cosmetic (and possibly adding in robustness, should the function ever 
> be used on Windows in the future). I have also followed the stylistic 
> convention of putting "JNIEXPORT <return type> JNICALL" on a separate 
> line. For some functions, however, this might cause a change in 
> calling convention on Windows. Since this can not apply to exported 
> functions on Windows (otherwise they would already have had 
> JNIEXPORT), I do not think this matters anything.
>
> A few libraries did not have a mapfile, on Linux and/or Solaris. This 
> actually meant that all symbols were exported. It is highly unclear if 
> this was known and intended by the original make rule writer. I have 
> emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these 
> libraries. Hopefully, we can remove this flag and fix proper exported 
> symbols in the future.
>
> I have run the complete build using COMPARE_BUILD, and made a 
> thourough analysis of the differences for Linux and Solaris. All 
> native libraries have symbol differences, but most of them are trivial 
> and/or harmless. As a result, most libraries have disasm differences 
> as well, but these too seem trivial and harmless. The differences in 
> symbols that are common to all libraries include:
> ?* Internal symbols such as __bss_start, _edata, _end and _fini are 
> now global. (They are imported as such from the compiler 
> libraries/archives, and we have no linker script to override this 
> behavior).
> ?* The versioning tag SUNWprivate_1.1 is not included, and thus 
> neither the .gnu.version_d symbol.
> ?* There are a few differences in the symbol and/or mangling of some 
> local functions. I'm not sure what's causing this,
> but it's unlikely to have any effect on the product.
>
> Another common source for change in symbols is due to previous 
> platform differences. For instance, if we had "JNIEXPORT int JNICALL 
> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was 
> exported on Windows but not on Linux and Solaris. (Presumable since it 
> was not needed there, even though it was compiled for those platforms 
> as well.) Now, with the mapfiles gone, do_foo() will be exported on 
> all platforms. And contrary, functions that are compiled on all 
> platforms, and were exported in mapfiles, but now have gotten an 
> JNIEXPORT decoration, will now be visible even on Windows. (This 
> accounts for half of the noticed symbol differences on Windows.) I 
> could have made the JNIEXPORT conditional on OS, but I didn't think 
> the mess in source code were worth the keeping of binary confidence 
> with the old build.
>
> A third common source for change in symbols is due to exported 
> functions "leaking" across library borders. For instance, some 
> functions in java.desktop is compiled in both libawt_xawt and 
> libawt_headless, but they were previously only included in the mapfile 
> for one of these libraries. Now, since the visibility is determined by 
> the source code itself, it gets exported in both libraries. A variant 
> of this is when a library depends on another JDK library, and includes 
> the header file from that other library, which in turn declares a 
> function as JNIEXPORT. This will cause the including library to also 
> export the function. This accounts for the other half of the changes 
> on Windows. A typical example of this is that multiple libraries now 
> re-export hotspot symbols from libjvm.so, like jio_fprintf. (I have 
> not listed the libjvm re-exports below.)
>
> Note that? Java_java_io_FileOutputStream_close0 in 
> java.base/unix/native/libjava/FileOutputStream_md.c is no longer 
> exported,
> and can probably be removed.
>
> Here is a detailed table showing and accounting for all the remaining 
> differences found on Linux and Solaris:
> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is 
> now also exported on unix platforms due to JNIEXPORT.
>
> java.base/jspawnlauncher: On solaris, we also include 
> libjava/childproc.o, which
> now exports less functions than it used to (it used to export all 
> functions, now it is compiled with visibility=hidden).
>
> java.base/java(w).exe: Is now also exporting the following symbols due 
> to added JNIEXPORT in libjli on Windows:
> (Yes, executables can export symbols on Windows. Confusing, I know.)
> ?JLI_AddArgsFromEnvVar
> ?JLI_CmdToArgs
> ?JLI_GetAppArgIndex
> ?JLI_GetStdArgc
> ?JLI_GetStdArgs
> ?JLI_InitArgProcessing
> ?JLI_Launch
> ?JLI_List_add
> ?JLI_List_new
> ?JLI_ManifestIterate
> ?JLI_MemAlloc
> ?JLI_MemFree
> ?JLI_PreprocessArg
> ?JLI_ReportErrorMessage
> ?JLI_ReportErrorMessageSys
> ?JLI_ReportExceptionDescription
> ?JLI_ReportMessage
> ?JLI_SetTraceLauncher
> ?JLI_StringDup
>
> java.desktop:/libawt_xawt: The following symbols are now also exported 
> on linux and solaris due to JNIEXPORT:
> ?awt_DrawingSurface_FreeDrawingSurfaceInfo
> ?awt_DrawingSurface_GetDrawingSurfaceInfo
> ?awt_DrawingSurface_Lock
> ?awt_DrawingSurface_Unlock
> ?awt_GetColor
>
> The following symbols are now also exported on linux and solaris due 
> to JNIEXPORT (they were previously
> ?exported only in libawt):
> ?Java_sun_awt_DebugSettings_setCTracingOn__Z
> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2
> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I
> ?Java_sun_awt_X11GraphicsConfig_getNumColors
>
> java.desktop:/libawt_headless: The following symbols are now also 
> exported due to JNIEXPORT (they were previously
> ?exported only in libawt_xawt and/or libawt):
> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo
> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities
> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask
> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable
> ?X11SurfaceData_GetOps
>
> java.desktop/libawt: The following symbols are now also exported on 
> Windows, due to added
> JNIEXPORT:
> ?SurfaceData_InitOps
> ?mul8table
> ?div8table
> ?doDrawPath
> ?doFillPath
> ?g_CMpDataID
> ?initInverseGrayLut
> ?make_dither_arrays
> ?make_uns_ordered_dither_array
> ?path2DFloatCoordsID
> ?path2DNumTypesID
> ?path2DTypesID
> ?path2DWindingRuleID
> ?sg2dStrokeHintID
> ?std_img_oda_blue
> ?std_img_oda_green
> ?std_img_oda_red
> ?std_odas_computed
> ?sunHints_INTVAL_STROKE_PURE
>
> java.desktop/libawt on solaris:
> A number of "#pragma weak" directives was previously overridden by the 
> mapfile.
> Now these directives are respected, so these symbols are now weak 
> instead of local:
> ?ByteGrayToIntArgbPreConvert_F
> ?ByteGrayToIntArgbPreScaleConvert_F
> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F
> ?IntArgbToIntRgbXorBlit_F
> ?IntBgrToIntBgrAlphaMaskBlit_F
>
> java.desktop/libawt on solaris: These are now also exported due to 
> JNIEXPORT in libmlib_image.
> ?j2d_mlib_ImageCreate
> ?j2d_mlib_ImageCreateStruct
> ?j2d_mlib_ImageDelete
>
> java.desktop/libawt on solaris: This is now also exported due to 
> JNIEXPORT:
> ?GrPrim_CompGetXorColor
> ?SurfaceData_GetOpsNoSetup
> ?SurfaceData_IntersectBoundsXYWH
> ?SurfaceData_SetOps
> ?Transform_GetInfo
> ?Transform_transform
>
> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and 
> solaris due to JNIEXPORT.
> libspashscreen also had JNIEXPORT (actually a pure 
> _declspec(dllexport)) but no JNICALL, which I added as
> a part of converting to JNIEXPORT. The same goes for libmlib_image .
>
> jdk.sctp/libsctp: handleSocketError is now exported on linux and 
> solaris due to JNIEXPORT in libnio.
>
> java.instrument:/libinstrument: Agent_OnUnload is now also exported on 
> linux and solaris platforms due to JNIEXPORT.
> JLI_ManifestIterate is now also exported on Windows, due to added 
> JNIEXPORT in libjli.
>
> jdk.management/libmanagement_ext: 
> Java_com_sun_management_internal_Flag_setDoubleValue is now also 
> exported on linux and solaris platforms due to JNIEXPORT.
>
> /Magnus
>
>


From Alan.Bateman at oracle.com  Fri Mar 23 14:45:09 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 23 Mar 2018 14:45:09 +0000
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
Message-ID: <16419c9d-df6a-c6cb-8357-470643d99cb3@oracle.com>

On 23/03/2018 13:56, Magnus Ihse Bursie wrote:
> With modern compilers, we can use compiler directives (such as 
> _attribute__((visibility("default"))), or __declspec(dllexport)) to 
> control symbol visibility, directly in the source code. This has 
> historically not been present on all compilers, so we had to resort to 
> using mapfiles (also known as linker scripts).
>
> This is no longer the case. Now all compilers we use support symbol 
> visibility directives, in one form or another. We should start using 
> this. Since this has been the only way to control symbol visibility on 
> Windows, for most of the shared code, we already have proper JNIEXPORT 
> decorations in place.
>
> If we fix the remaining platform-specific files to have proper 
> JNIEXPORT tagging, then we can finally get rid of mapfiles.
This seems like a great cleanup as the mapfile have always been a pain 
to maintain. Also shines a light on some technical debt too.

handleSocketError in libnio is a surprise, this should not be exported 
and should not have been in the map file.? I suspect the issue is that 
jdk.sctp is missing a function prototype from its header file (it has 
its own handleSocketError in SctpNet.c).

NET_Wait in libnet is another one, I can't tell why this was listed in 
the map file.

I'm also surprised with java.dll exporting handleRead, winHandleRead, 
and handleLSeek. I didn't see them mentioned in your mail so I'm curious 
what might be using those.

-Alan

From magnus.ihse.bursie at oracle.com  Fri Mar 23 15:15:35 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 23 Mar 2018 16:15:35 +0100
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <16419c9d-df6a-c6cb-8357-470643d99cb3@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <16419c9d-df6a-c6cb-8357-470643d99cb3@oracle.com>
Message-ID: <F0FD6CB0-8E66-485F-B0C1-1B34B4ED39C4@oracle.com>


> 23 mars 2018 kl. 15:45 skrev Alan Bateman <Alan.Bateman at oracle.com>:
> 
>> On 23/03/2018 13:56, Magnus Ihse Bursie wrote:
>> With modern compilers, we can use compiler directives (such as _attribute__((visibility("default"))), or __declspec(dllexport)) to control symbol visibility, directly in the source code. This has historically not been present on all compilers, so we had to resort to using mapfiles (also known as linker scripts).
>> 
>> This is no longer the case. Now all compilers we use support symbol visibility directives, in one form or another. We should start using this. Since this has been the only way to control symbol visibility on Windows, for most of the shared code, we already have proper JNIEXPORT decorations in place.
>> 
>> If we fix the remaining platform-specific files to have proper JNIEXPORT tagging, then we can finally get rid of mapfiles.
> This seems like a great cleanup as the mapfile have always been a pain to maintain. Also shines a light on some technical debt too.

Very much so, yes. I've found a lot of dubious exports, everything from global variables (yuck!) to functions that does not seem to be used anymore, to lots of strange exports. 

> handleSocketError in libnio is a surprise, this should not be exported and should not have been in the map file.  I suspect the issue is that jdk.sctp is missing a function prototype from its header file (it has its own handleSocketError in SctpNet.c).

That might be so, yes. 

> NET_Wait in libnet is another one, I can't tell why this was listed in the map file.

Neither can I. :-) Once again, my goal with this patch was to keep the produced binaries as similar to before with the mapfiles. I'll be happy to file follow-up bugs listing all suspicious symbol handling I've encountered, but I'd rather not change anything about that in this patch. 

> I'm also surprised with java.dll exporting handleRead, winHandleRead, and handleLSeek. I didn't see them mentioned in your mail so I'm curious what might be using those.

They were previously exported using -export: on the command line for the Microsoft linker. This was the case for a couple other libraries as well. Yeah, I forgot to write about that, sorry. :( Been a lot to keep track of, and it went away when I cleaned up my notes. 

Can I consider this a review?

/Magnus

> 
> -Alan


From Alan.Bateman at oracle.com  Fri Mar 23 16:04:12 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 23 Mar 2018 16:04:12 +0000
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <F0FD6CB0-8E66-485F-B0C1-1B34B4ED39C4@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <16419c9d-df6a-c6cb-8357-470643d99cb3@oracle.com>
 <F0FD6CB0-8E66-485F-B0C1-1B34B4ED39C4@oracle.com>
Message-ID: <810a6225-15af-6858-8bea-2c3122ac1c5d@oracle.com>

On 23/03/2018 15:15, Magnus Ihse Bursie wrote:
> :
> Very much so, yes. I've found a lot of dubious exports, everything from global variables (yuck!) to functions that does not seem to be used anymore, to lots of strange exports.
The changes looks good to me and I think we should follow this up with a 
few JIRA issues (as you suggested) for the symbols that don't make sense 
to export.

-Alan

From mandy.chung at oracle.com  Fri Mar 23 16:05:23 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 23 Mar 2018 09:05:23 -0700
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com>
Message-ID: <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com>

This is a very good change and no more mapfile to maintain!!

Please do file JBS issues for the component teams to clean up their 
exports.

Mandy

On 3/23/18 7:30 AM, Erik Joelsson wrote:
> I have looked at the build changes and they look good.
>
> Will you file followups for each component team to look over their 
> exported symbols, at least for the libraries with 
> $(EXPORT_ALL_SYMBOLS)? It sure looks like there is some technical debt 
> laying around here.
>
> /Erik
>
>
> On 2018-03-23 06:56, Magnus Ihse Bursie wrote:
>> With modern compilers, we can use compiler directives (such as 
>> _attribute__((visibility("default"))), or __declspec(dllexport)) to 
>> control symbol visibility, directly in the source code. This has 
>> historically not been present on all compilers, so we had to resort 
>> to using mapfiles (also known as linker scripts).
>>
>> This is no longer the case. Now all compilers we use support symbol 
>> visibility directives, in one form or another. We should start using 
>> this. Since this has been the only way to control symbol visibility 
>> on Windows, for most of the shared code, we already have proper 
>> JNIEXPORT decorations in place.
>>
>> If we fix the remaining platform-specific files to have proper 
>> JNIEXPORT tagging, then we can finally get rid of mapfiles.
>>
>> This fix removed mapfiles for all JDK libraries. It does not touch 
>> hotspot libraries nor JDK executables; they will have to wait for a 
>> future fix -- this was complex enough. This change will not have any 
>> impact on macosx, since we do not use mapfiles there, but instead 
>> export all symbols. (This is not a good idea, but I'll address that 
>> separately.) This change will also have a minimal impact on Windows. 
>> The only reason Windows is impacted at all, is that some changes 
>> needed by Solaris and Linux were simpler to fix for all platforms.
>>
>> I have strived for this change to have no impact on the actual 
>> generated code. Unfortunately, this was not possible to fully 
>> achieve. I do not believe that these changes will have any actual 
>> impact on the product, though. I will present the differences more in 
>> detail further down. Those who are not interested can probably skip 
>> that.
>>
>> The patch has passed tier1 testing and is currently running tier2 and 
>> tier3. Since the running code is more or less (see caveat below) 
>> unmodified, I don't expect any testing issues.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01
>>
>> Details on changes:
>> Most of the source code changes are (unsurprisingly) in java.base and 
>> java.desktop. Remaining changes are in jdk.crypto.ucrypto, 
>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent.
>>
>> Source code changes does almost to 100% consists in decorating an 
>> exported function with JNIEXPORT. I have also followed the 
>> long-standing convention of adding JNICALL. This is a no-op on 
>> non-Windows platforms, so for most of the changes this is purely 
>> cosmetic (and possibly adding in robustness, should the function ever 
>> be used on Windows in the future). I have also followed the stylistic 
>> convention of putting "JNIEXPORT <return type> JNICALL" on a separate 
>> line. For some functions, however, this might cause a change in 
>> calling convention on Windows. Since this can not apply to exported 
>> functions on Windows (otherwise they would already have had 
>> JNIEXPORT), I do not think this matters anything.
>>
>> A few libraries did not have a mapfile, on Linux and/or Solaris. This 
>> actually meant that all symbols were exported. It is highly unclear 
>> if this was known and intended by the original make rule writer. I 
>> have emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these 
>> libraries. Hopefully, we can remove this flag and fix proper exported 
>> symbols in the future.
>>
>> I have run the complete build using COMPARE_BUILD, and made a 
>> thourough analysis of the differences for Linux and Solaris. All 
>> native libraries have symbol differences, but most of them are 
>> trivial and/or harmless. As a result, most libraries have disasm 
>> differences as well, but these too seem trivial and harmless. The 
>> differences in symbols that are common to all libraries include:
>> ?* Internal symbols such as __bss_start, _edata, _end and _fini are 
>> now global. (They are imported as such from the compiler 
>> libraries/archives, and we have no linker script to override this 
>> behavior).
>> ?* The versioning tag SUNWprivate_1.1 is not included, and thus 
>> neither the .gnu.version_d symbol.
>> ?* There are a few differences in the symbol and/or mangling of some 
>> local functions. I'm not sure what's causing this,
>> but it's unlikely to have any effect on the product.
>>
>> Another common source for change in symbols is due to previous 
>> platform differences. For instance, if we had "JNIEXPORT int JNICALL 
>> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was 
>> exported on Windows but not on Linux and Solaris. (Presumable since 
>> it was not needed there, even though it was compiled for those 
>> platforms as well.) Now, with the mapfiles gone, do_foo() will be 
>> exported on all platforms. And contrary, functions that are compiled 
>> on all platforms, and were exported in mapfiles, but now have gotten 
>> an JNIEXPORT decoration, will now be visible even on Windows. (This 
>> accounts for half of the noticed symbol differences on Windows.) I 
>> could have made the JNIEXPORT conditional on OS, but I didn't think 
>> the mess in source code were worth the keeping of binary confidence 
>> with the old build.
>>
>> A third common source for change in symbols is due to exported 
>> functions "leaking" across library borders. For instance, some 
>> functions in java.desktop is compiled in both libawt_xawt and 
>> libawt_headless, but they were previously only included in the 
>> mapfile for one of these libraries. Now, since the visibility is 
>> determined by the source code itself, it gets exported in both 
>> libraries. A variant of this is when a library depends on another JDK 
>> library, and includes the header file from that other library, which 
>> in turn declares a function as JNIEXPORT. This will cause the 
>> including library to also export the function. This accounts for the 
>> other half of the changes on Windows. A typical example of this is 
>> that multiple libraries now re-export hotspot symbols from libjvm.so, 
>> like jio_fprintf. (I have not listed the libjvm re-exports below.)
>>
>> Note that? Java_java_io_FileOutputStream_close0 in 
>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer 
>> exported,
>> and can probably be removed.
>>
>> Here is a detailed table showing and accounting for all the remaining 
>> differences found on Linux and Solaris:
>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 
>> is now also exported on unix platforms due to JNIEXPORT.
>>
>> java.base/jspawnlauncher: On solaris, we also include 
>> libjava/childproc.o, which
>> now exports less functions than it used to (it used to export all 
>> functions, now it is compiled with visibility=hidden).
>>
>> java.base/java(w).exe: Is now also exporting the following symbols 
>> due to added JNIEXPORT in libjli on Windows:
>> (Yes, executables can export symbols on Windows. Confusing, I know.)
>> ?JLI_AddArgsFromEnvVar
>> ?JLI_CmdToArgs
>> ?JLI_GetAppArgIndex
>> ?JLI_GetStdArgc
>> ?JLI_GetStdArgs
>> ?JLI_InitArgProcessing
>> ?JLI_Launch
>> ?JLI_List_add
>> ?JLI_List_new
>> ?JLI_ManifestIterate
>> ?JLI_MemAlloc
>> ?JLI_MemFree
>> ?JLI_PreprocessArg
>> ?JLI_ReportErrorMessage
>> ?JLI_ReportErrorMessageSys
>> ?JLI_ReportExceptionDescription
>> ?JLI_ReportMessage
>> ?JLI_SetTraceLauncher
>> ?JLI_StringDup
>>
>> java.desktop:/libawt_xawt: The following symbols are now also 
>> exported on linux and solaris due to JNIEXPORT:
>> ?awt_DrawingSurface_FreeDrawingSurfaceInfo
>> ?awt_DrawingSurface_GetDrawingSurfaceInfo
>> ?awt_DrawingSurface_Lock
>> ?awt_DrawingSurface_Unlock
>> ?awt_GetColor
>>
>> The following symbols are now also exported on linux and solaris due 
>> to JNIEXPORT (they were previously
>> ?exported only in libawt):
>> ?Java_sun_awt_DebugSettings_setCTracingOn__Z
>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2
>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I
>> ?Java_sun_awt_X11GraphicsConfig_getNumColors
>>
>> java.desktop:/libawt_headless: The following symbols are now also 
>> exported due to JNIEXPORT (they were previously
>> ?exported only in libawt_xawt and/or libawt):
>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo
>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities
>> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask
>> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable
>> ?X11SurfaceData_GetOps
>>
>> java.desktop/libawt: The following symbols are now also exported on 
>> Windows, due to added
>> JNIEXPORT:
>> ?SurfaceData_InitOps
>> ?mul8table
>> ?div8table
>> ?doDrawPath
>> ?doFillPath
>> ?g_CMpDataID
>> ?initInverseGrayLut
>> ?make_dither_arrays
>> ?make_uns_ordered_dither_array
>> ?path2DFloatCoordsID
>> ?path2DNumTypesID
>> ?path2DTypesID
>> ?path2DWindingRuleID
>> ?sg2dStrokeHintID
>> ?std_img_oda_blue
>> ?std_img_oda_green
>> ?std_img_oda_red
>> ?std_odas_computed
>> ?sunHints_INTVAL_STROKE_PURE
>>
>> java.desktop/libawt on solaris:
>> A number of "#pragma weak" directives was previously overridden by 
>> the mapfile.
>> Now these directives are respected, so these symbols are now weak 
>> instead of local:
>> ?ByteGrayToIntArgbPreConvert_F
>> ?ByteGrayToIntArgbPreScaleConvert_F
>> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F
>> ?IntArgbToIntRgbXorBlit_F
>> ?IntBgrToIntBgrAlphaMaskBlit_F
>>
>> java.desktop/libawt on solaris: These are now also exported due to 
>> JNIEXPORT in libmlib_image.
>> ?j2d_mlib_ImageCreate
>> ?j2d_mlib_ImageCreateStruct
>> ?j2d_mlib_ImageDelete
>>
>> java.desktop/libawt on solaris: This is now also exported due to 
>> JNIEXPORT:
>> ?GrPrim_CompGetXorColor
>> ?SurfaceData_GetOpsNoSetup
>> ?SurfaceData_IntersectBoundsXYWH
>> ?SurfaceData_SetOps
>> ?Transform_GetInfo
>> ?Transform_transform
>>
>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and 
>> solaris due to JNIEXPORT.
>> libspashscreen also had JNIEXPORT (actually a pure 
>> _declspec(dllexport)) but no JNICALL, which I added as
>> a part of converting to JNIEXPORT. The same goes for libmlib_image .
>>
>> jdk.sctp/libsctp: handleSocketError is now exported on linux and 
>> solaris due to JNIEXPORT in libnio.
>>
>> java.instrument:/libinstrument: Agent_OnUnload is now also exported 
>> on linux and solaris platforms due to JNIEXPORT.
>> JLI_ManifestIterate is now also exported on Windows, due to added 
>> JNIEXPORT in libjli.
>>
>> jdk.management/libmanagement_ext: 
>> Java_com_sun_management_internal_Flag_setDoubleValue is now also 
>> exported on linux and solaris platforms due to JNIEXPORT.
>>
>> /Magnus
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180323/212825d9/attachment-0001.html>

From volker.simonis at gmail.com  Fri Mar 23 17:24:24 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 23 Mar 2018 18:24:24 +0100
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com>
 <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com>
Message-ID: <CA+3eh10JirUDKXXUD6dd7=fFK9X_4iSNVpb4jHpvfi6CBaLFAQ@mail.gmail.com>

Hi Magnus,

thanks for addressing this long standing issue! I haven't looked at
the changes, but just want to share some general and historical notes:

- Compiling with "-fvisibility=hidden" which hides all symbols expect
the ones explicitly exported with
"__attribute__((visibility("default")))" has been requested by SAP
back in 2007 even before we had OpenJDK (see "Use -fvisibility=hidden
for gcc compiles" https://bugs.openjdk.java.net/browse/JDK-6588413)
and finally pushed into the OpenJKD around 2010.
- "-fvisibility=hidden" gave us performance improvements of about 5%
(JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and 0,5%
(JVM98) on Linux/PPC64 because the compiler could use faster calls for
non exported symbols. This improvement was only very small on x86
tough.
- "-fvisibility=hidden"/"__attribute__((visibility("default")))"
applies BEFORE using the map files in the linking step (i.e. hidden
symbols can't be exported any more even if mentioned in the map file)
- because of the performance improvements we got by using
"-fvisibility=hidden" it was worth while using it even though we had
the mapfiles at the end of the process.

Then we had several mail threads (which you probably remember because
you were involved :) where we discussed to either remove the map files
completely or instead generate them automatically during the build:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/thread.html#12412
http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/thread.html#12628

The main arguments against removing the map files at that time were:

1. the danger to re-export all symbols of statically linked libraries
(notably libstdc++ at that time)
2. loosing exports of compiler generated symbols like vtables which
are required by the Serviceability Agent

Point 1 is not a problem today, because I don't think we do any static
linking any more. If we still do it under some circumstances, this
problem should be re-evaluated.

Point 2 is only relevant for HotSpot. But because of "8034065: GCC 4.3
and later doesn't export vtable symbols any more which seem to be
needed by SA" (https://bugs.openjdk.java.net/browse/JDK-8034065),
exporting such symbols trough a map files doesn't work any more
anyway. So this isn't a problem either.

So to cut a long story short - I think the time is ripe to get rid of
the map files. Thumbs up from me (meant as moral support, not as a
concrete review :)

Regards,
Volker

On Fri, Mar 23, 2018 at 5:05 PM, mandy chung <mandy.chung at oracle.com> wrote:
> This is a very good change and no more mapfile to maintain!!
>
> Please do file JBS issues for the component teams to clean up their exports.
>
> Mandy
>
>
> On 3/23/18 7:30 AM, Erik Joelsson wrote:
>>
>> I have looked at the build changes and they look good.
>>
>> Will you file followups for each component team to look over their
>> exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)? It
>> sure looks like there is some technical debt laying around here.
>>
>> /Erik
>>
>>
>> On 2018-03-23 06:56, Magnus Ihse Bursie wrote:
>>>
>>> With modern compilers, we can use compiler directives (such as
>>> _attribute__((visibility("default"))), or __declspec(dllexport)) to control
>>> symbol visibility, directly in the source code. This has historically not
>>> been present on all compilers, so we had to resort to using mapfiles (also
>>> known as linker scripts).
>>>
>>> This is no longer the case. Now all compilers we use support symbol
>>> visibility directives, in one form or another. We should start using this.
>>> Since this has been the only way to control symbol visibility on Windows,
>>> for most of the shared code, we already have proper JNIEXPORT decorations in
>>> place.
>>>
>>> If we fix the remaining platform-specific files to have proper JNIEXPORT
>>> tagging, then we can finally get rid of mapfiles.
>>>
>>> This fix removed mapfiles for all JDK libraries. It does not touch
>>> hotspot libraries nor JDK executables; they will have to wait for a future
>>> fix -- this was complex enough. This change will not have any impact on
>>> macosx, since we do not use mapfiles there, but instead export all symbols.
>>> (This is not a good idea, but I'll address that separately.) This change
>>> will also have a minimal impact on Windows. The only reason Windows is
>>> impacted at all, is that some changes needed by Solaris and Linux were
>>> simpler to fix for all platforms.
>>>
>>> I have strived for this change to have no impact on the actual generated
>>> code. Unfortunately, this was not possible to fully achieve. I do not
>>> believe that these changes will have any actual impact on the product,
>>> though. I will present the differences more in detail further down. Those
>>> who are not interested can probably skip that.
>>>
>>> The patch has passed tier1 testing and is currently running tier2 and
>>> tier3. Since the running code is more or less (see caveat below) unmodified,
>>> I don't expect any testing issues.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01
>>>
>>> Details on changes:
>>> Most of the source code changes are (unsurprisingly) in java.base and
>>> java.desktop. Remaining changes are in jdk.crypto.ucrypto,
>>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent.
>>>
>>> Source code changes does almost to 100% consists in decorating an
>>> exported function with JNIEXPORT. I have also followed the long-standing
>>> convention of adding JNICALL. This is a no-op on non-Windows platforms, so
>>> for most of the changes this is purely cosmetic (and possibly adding in
>>> robustness, should the function ever be used on Windows in the future). I
>>> have also followed the stylistic convention of putting "JNIEXPORT <return
>>> type> JNICALL" on a separate line. For some functions, however, this might
>>> cause a change in calling convention on Windows. Since this can not apply to
>>> exported functions on Windows (otherwise they would already have had
>>> JNIEXPORT), I do not think this matters anything.
>>>
>>> A few libraries did not have a mapfile, on Linux and/or Solaris. This
>>> actually meant that all symbols were exported. It is highly unclear if this
>>> was known and intended by the original make rule writer. I have emulated
>>> this by adding the flag $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully,
>>> we can remove this flag and fix proper exported symbols in the future.
>>>
>>> I have run the complete build using COMPARE_BUILD, and made a thourough
>>> analysis of the differences for Linux and Solaris. All native libraries have
>>> symbol differences, but most of them are trivial and/or harmless. As a
>>> result, most libraries have disasm differences as well, but these too seem
>>> trivial and harmless. The differences in symbols that are common to all
>>> libraries include:
>>>  * Internal symbols such as __bss_start, _edata, _end and _fini are now
>>> global. (They are imported as such from the compiler libraries/archives, and
>>> we have no linker script to override this behavior).
>>>  * The versioning tag SUNWprivate_1.1 is not included, and thus neither
>>> the .gnu.version_d symbol.
>>>  * There are a few differences in the symbol and/or mangling of some
>>> local functions. I'm not sure what's causing this,
>>> but it's unlikely to have any effect on the product.
>>>
>>> Another common source for change in symbols is due to previous platform
>>> differences. For instance, if we had "JNIEXPORT int JNICALL do_foo() { ...
>>> }", but do_foo was not in the mapfile, the symbol was exported on Windows
>>> but not on Linux and Solaris. (Presumable since it was not needed there,
>>> even though it was compiled for those platforms as well.) Now, with the
>>> mapfiles gone, do_foo() will be exported on all platforms. And contrary,
>>> functions that are compiled on all platforms, and were exported in mapfiles,
>>> but now have gotten an JNIEXPORT decoration, will now be visible even on
>>> Windows. (This accounts for half of the noticed symbol differences on
>>> Windows.) I could have made the JNIEXPORT conditional on OS, but I didn't
>>> think the mess in source code were worth the keeping of binary confidence
>>> with the old build.
>>>
>>> A third common source for change in symbols is due to exported functions
>>> "leaking" across library borders. For instance, some functions in
>>> java.desktop is compiled in both libawt_xawt and libawt_headless, but they
>>> were previously only included in the mapfile for one of these libraries.
>>> Now, since the visibility is determined by the source code itself, it gets
>>> exported in both libraries. A variant of this is when a library depends on
>>> another JDK library, and includes the header file from that other library,
>>> which in turn declares a function as JNIEXPORT. This will cause the
>>> including library to also export the function. This accounts for the other
>>> half of the changes on Windows. A typical example of this is that multiple
>>> libraries now re-export hotspot symbols from libjvm.so, like jio_fprintf. (I
>>> have not listed the libjvm re-exports below.)
>>>
>>> Note that  Java_java_io_FileOutputStream_close0 in
>>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer exported,
>>> and can probably be removed.
>>>
>>> Here is a detailed table showing and accounting for all the remaining
>>> differences found on Linux and Solaris:
>>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is
>>> now also exported on unix platforms due to JNIEXPORT.
>>>
>>> java.base/jspawnlauncher: On solaris, we also include
>>> libjava/childproc.o, which
>>> now exports less functions than it used to (it used to export all
>>> functions, now it is compiled with visibility=hidden).
>>>
>>> java.base/java(w).exe: Is now also exporting the following symbols due to
>>> added JNIEXPORT in libjli on Windows:
>>> (Yes, executables can export symbols on Windows. Confusing, I know.)
>>>  JLI_AddArgsFromEnvVar
>>>  JLI_CmdToArgs
>>>  JLI_GetAppArgIndex
>>>  JLI_GetStdArgc
>>>  JLI_GetStdArgs
>>>  JLI_InitArgProcessing
>>>  JLI_Launch
>>>  JLI_List_add
>>>  JLI_List_new
>>>  JLI_ManifestIterate
>>>  JLI_MemAlloc
>>>  JLI_MemFree
>>>  JLI_PreprocessArg
>>>  JLI_ReportErrorMessage
>>>  JLI_ReportErrorMessageSys
>>>  JLI_ReportExceptionDescription
>>>  JLI_ReportMessage
>>>  JLI_SetTraceLauncher
>>>  JLI_StringDup
>>>
>>> java.desktop:/libawt_xawt: The following symbols are now also exported on
>>> linux and solaris due to JNIEXPORT:
>>>  awt_DrawingSurface_FreeDrawingSurfaceInfo
>>>  awt_DrawingSurface_GetDrawingSurfaceInfo
>>>  awt_DrawingSurface_Lock
>>>  awt_DrawingSurface_Unlock
>>>  awt_GetColor
>>>
>>> The following symbols are now also exported on linux and solaris due to
>>> JNIEXPORT (they were previously
>>>  exported only in libawt):
>>>  Java_sun_awt_DebugSettings_setCTracingOn__Z
>>>  Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2
>>>  Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I
>>>  Java_sun_awt_X11GraphicsConfig_getNumColors
>>>
>>> java.desktop:/libawt_headless: The following symbols are now also
>>> exported due to JNIEXPORT (they were previously
>>>  exported only in libawt_xawt and/or libawt):
>>>  Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo
>>>  Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities
>>>  Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask
>>>  Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable
>>>  X11SurfaceData_GetOps
>>>
>>> java.desktop/libawt: The following symbols are now also exported on
>>> Windows, due to added
>>> JNIEXPORT:
>>>  SurfaceData_InitOps
>>>  mul8table
>>>  div8table
>>>  doDrawPath
>>>  doFillPath
>>>  g_CMpDataID
>>>  initInverseGrayLut
>>>  make_dither_arrays
>>>  make_uns_ordered_dither_array
>>>  path2DFloatCoordsID
>>>  path2DNumTypesID
>>>  path2DTypesID
>>>  path2DWindingRuleID
>>>  sg2dStrokeHintID
>>>  std_img_oda_blue
>>>  std_img_oda_green
>>>  std_img_oda_red
>>>  std_odas_computed
>>>  sunHints_INTVAL_STROKE_PURE
>>>
>>> java.desktop/libawt on solaris:
>>> A number of "#pragma weak" directives was previously overridden by the
>>> mapfile.
>>> Now these directives are respected, so these symbols are now weak instead
>>> of local:
>>>  ByteGrayToIntArgbPreConvert_F
>>>  ByteGrayToIntArgbPreScaleConvert_F
>>>  IntArgbBmToFourByteAbgrPreScaleXparOver_F
>>>  IntArgbToIntRgbXorBlit_F
>>>  IntBgrToIntBgrAlphaMaskBlit_F
>>>
>>> java.desktop/libawt on solaris: These are now also exported due to
>>> JNIEXPORT in libmlib_image.
>>>  j2d_mlib_ImageCreate
>>>  j2d_mlib_ImageCreateStruct
>>>  j2d_mlib_ImageDelete
>>>
>>> java.desktop/libawt on solaris: This is now also exported due to
>>> JNIEXPORT:
>>>  GrPrim_CompGetXorColor
>>>  SurfaceData_GetOpsNoSetup
>>>  SurfaceData_IntersectBoundsXYWH
>>>  SurfaceData_SetOps
>>>  Transform_GetInfo
>>>  Transform_transform
>>>
>>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and
>>> solaris due to JNIEXPORT.
>>> libspashscreen also had JNIEXPORT (actually a pure _declspec(dllexport))
>>> but no JNICALL, which I added as
>>> a part of converting to JNIEXPORT. The same goes for libmlib_image .
>>>
>>> jdk.sctp/libsctp: handleSocketError is now exported on linux and solaris
>>> due to JNIEXPORT in libnio.
>>>
>>> java.instrument:/libinstrument: Agent_OnUnload is now also exported on
>>> linux and solaris platforms due to JNIEXPORT.
>>> JLI_ManifestIterate is now also exported on Windows, due to added
>>> JNIEXPORT in libjli.
>>>
>>> jdk.management/libmanagement_ext:
>>> Java_com_sun_management_internal_Flag_setDoubleValue is now also exported on
>>> linux and solaris platforms due to JNIEXPORT.
>>>
>>> /Magnus
>>>
>>>
>>
>

From philip.race at oracle.com  Fri Mar 23 17:33:55 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 23 Mar 2018 10:33:55 -0700
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
Message-ID: <359e997c-6f49-218b-a1e6-81888135242b@oracle.com>

There are a lot of changes in the desktop libraries.
Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those since
only tier3 has any UI tests and it barely uses anything that's touched here.
So since testing seems to be wise, then I think you should do a
jtreg desktop group run on Linux & Windows.
You can probably skip Mac since it is unaffected and I think Linux will 
cover Solaris here.
You should also do some headless testing.

It could take some time to review this properly and decide what changes 
are OK,
what changes are something we should clean up later, and what changes 
are something
that ought to be addressed now ..

I think I'd be mainly concerned that something fails due to a missing 
symbol, or
that for newly exported symbols if we ended up with duplicate symbols as 
a result.

The results of a test run will add confidence here.

BTW I don't think you are right that
java.desktop:/libawt_headless: The following symbols are now also 
exported due to JNIEXPORT (they were previously
..
  X11SurfaceData_GetOps

It looks to me like it was previously exported.


-phil.



On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote:
> With modern compilers, we can use compiler directives (such as 
> _attribute__((visibility("default"))), or __declspec(dllexport)) to 
> control symbol visibility, directly in the source code. This has 
> historically not been present on all compilers, so we had to resort to 
> using mapfiles (also known as linker scripts).
>
> This is no longer the case. Now all compilers we use support symbol 
> visibility directives, in one form or another. We should start using 
> this. Since this has been the only way to control symbol visibility on 
> Windows, for most of the shared code, we already have proper JNIEXPORT 
> decorations in place.
>
> If we fix the remaining platform-specific files to have proper 
> JNIEXPORT tagging, then we can finally get rid of mapfiles.
>
> This fix removed mapfiles for all JDK libraries. It does not touch 
> hotspot libraries nor JDK executables; they will have to wait for a 
> future fix -- this was complex enough. This change will not have any 
> impact on macosx, since we do not use mapfiles there, but instead 
> export all symbols. (This is not a good idea, but I'll address that 
> separately.) This change will also have a minimal impact on Windows. 
> The only reason Windows is impacted at all, is that some changes 
> needed by Solaris and Linux were simpler to fix for all platforms.
>
> I have strived for this change to have no impact on the actual 
> generated code. Unfortunately, this was not possible to fully achieve. 
> I do not believe that these changes will have any actual impact on the 
> product, though. I will present the differences more in detail further 
> down. Those who are not interested can probably skip that.
>
> The patch has passed tier1 testing and is currently running tier2 and 
> tier3. Since the running code is more or less (see caveat below) 
> unmodified, I don't expect any testing issues.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01
>
> Details on changes:
> Most of the source code changes are (unsurprisingly) in java.base and 
> java.desktop. Remaining changes are in jdk.crypto.ucrypto, 
> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent.
>
> Source code changes does almost to 100% consists in decorating an 
> exported function with JNIEXPORT. I have also followed the 
> long-standing convention of adding JNICALL. This is a no-op on 
> non-Windows platforms, so for most of the changes this is purely 
> cosmetic (and possibly adding in robustness, should the function ever 
> be used on Windows in the future). I have also followed the stylistic 
> convention of putting "JNIEXPORT <return type> JNICALL" on a separate 
> line. For some functions, however, this might cause a change in 
> calling convention on Windows. Since this can not apply to exported 
> functions on Windows (otherwise they would already have had 
> JNIEXPORT), I do not think this matters anything.
>
> A few libraries did not have a mapfile, on Linux and/or Solaris. This 
> actually meant that all symbols were exported. It is highly unclear if 
> this was known and intended by the original make rule writer. I have 
> emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these 
> libraries. Hopefully, we can remove this flag and fix proper exported 
> symbols in the future.
>
> I have run the complete build using COMPARE_BUILD, and made a 
> thourough analysis of the differences for Linux and Solaris. All 
> native libraries have symbol differences, but most of them are trivial 
> and/or harmless. As a result, most libraries have disasm differences 
> as well, but these too seem trivial and harmless. The differences in 
> symbols that are common to all libraries include:
>  * Internal symbols such as __bss_start, _edata, _end and _fini are 
> now global. (They are imported as such from the compiler 
> libraries/archives, and we have no linker script to override this 
> behavior).
>  * The versioning tag SUNWprivate_1.1 is not included, and thus 
> neither the .gnu.version_d symbol.
>  * There are a few differences in the symbol and/or mangling of some 
> local functions. I'm not sure what's causing this,
> but it's unlikely to have any effect on the product.
>
> Another common source for change in symbols is due to previous 
> platform differences. For instance, if we had "JNIEXPORT int JNICALL 
> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was 
> exported on Windows but not on Linux and Solaris. (Presumable since it 
> was not needed there, even though it was compiled for those platforms 
> as well.) Now, with the mapfiles gone, do_foo() will be exported on 
> all platforms. And contrary, functions that are compiled on all 
> platforms, and were exported in mapfiles, but now have gotten an 
> JNIEXPORT decoration, will now be visible even on Windows. (This 
> accounts for half of the noticed symbol differences on Windows.) I 
> could have made the JNIEXPORT conditional on OS, but I didn't think 
> the mess in source code were worth the keeping of binary confidence 
> with the old build.
>
> A third common source for change in symbols is due to exported 
> functions "leaking" across library borders. For instance, some 
> functions in java.desktop is compiled in both libawt_xawt and 
> libawt_headless, but they were previously only included in the mapfile 
> for one of these libraries. Now, since the visibility is determined by 
> the source code itself, it gets exported in both libraries. A variant 
> of this is when a library depends on another JDK library, and includes 
> the header file from that other library, which in turn declares a 
> function as JNIEXPORT. This will cause the including library to also 
> export the function. This accounts for the other half of the changes 
> on Windows. A typical example of this is that multiple libraries now 
> re-export hotspot symbols from libjvm.so, like jio_fprintf. (I have 
> not listed the libjvm re-exports below.)
>
> Note that  Java_java_io_FileOutputStream_close0 in 
> java.base/unix/native/libjava/FileOutputStream_md.c is no longer 
> exported,
> and can probably be removed.
>
> Here is a detailed table showing and accounting for all the remaining 
> differences found on Linux and Solaris:
> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is 
> now also exported on unix platforms due to JNIEXPORT.
>
> java.base/jspawnlauncher: On solaris, we also include 
> libjava/childproc.o, which
> now exports less functions than it used to (it used to export all 
> functions, now it is compiled with visibility=hidden).
>
> java.base/java(w).exe: Is now also exporting the following symbols due 
> to added JNIEXPORT in libjli on Windows:
> (Yes, executables can export symbols on Windows. Confusing, I know.)
>  JLI_AddArgsFromEnvVar
>  JLI_CmdToArgs
>  JLI_GetAppArgIndex
>  JLI_GetStdArgc
>  JLI_GetStdArgs
>  JLI_InitArgProcessing
>  JLI_Launch
>  JLI_List_add
>  JLI_List_new
>  JLI_ManifestIterate
>  JLI_MemAlloc
>  JLI_MemFree
>  JLI_PreprocessArg
>  JLI_ReportErrorMessage
>  JLI_ReportErrorMessageSys
>  JLI_ReportExceptionDescription
>  JLI_ReportMessage
>  JLI_SetTraceLauncher
>  JLI_StringDup
>
> java.desktop:/libawt_xawt: The following symbols are now also exported 
> on linux and solaris due to JNIEXPORT:
>  awt_DrawingSurface_FreeDrawingSurfaceInfo
>  awt_DrawingSurface_GetDrawingSurfaceInfo
>  awt_DrawingSurface_Lock
>  awt_DrawingSurface_Unlock
>  awt_GetColor
>
> The following symbols are now also exported on linux and solaris due 
> to JNIEXPORT (they were previously
>  exported only in libawt):
>  Java_sun_awt_DebugSettings_setCTracingOn__Z
>  Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2
>  Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I
>  Java_sun_awt_X11GraphicsConfig_getNumColors
>
> java.desktop:/libawt_headless: The following symbols are now also 
> exported due to JNIEXPORT (they were previously
>  exported only in libawt_xawt and/or libawt):
>  Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo
>  Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities
>  Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask
>  Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable
>  X11SurfaceData_GetOps
>
> java.desktop/libawt: The following symbols are now also exported on 
> Windows, due to added
> JNIEXPORT:
>  SurfaceData_InitOps
>  mul8table
>  div8table
>  doDrawPath
>  doFillPath
>  g_CMpDataID
>  initInverseGrayLut
>  make_dither_arrays
>  make_uns_ordered_dither_array
>  path2DFloatCoordsID
>  path2DNumTypesID
>  path2DTypesID
>  path2DWindingRuleID
>  sg2dStrokeHintID
>  std_img_oda_blue
>  std_img_oda_green
>  std_img_oda_red
>  std_odas_computed
>  sunHints_INTVAL_STROKE_PURE
>
> java.desktop/libawt on solaris:
> A number of "#pragma weak" directives was previously overridden by the 
> mapfile.
> Now these directives are respected, so these symbols are now weak 
> instead of local:
>  ByteGrayToIntArgbPreConvert_F
>  ByteGrayToIntArgbPreScaleConvert_F
>  IntArgbBmToFourByteAbgrPreScaleXparOver_F
>  IntArgbToIntRgbXorBlit_F
>  IntBgrToIntBgrAlphaMaskBlit_F
>
> java.desktop/libawt on solaris: These are now also exported due to 
> JNIEXPORT in libmlib_image.
>  j2d_mlib_ImageCreate
>  j2d_mlib_ImageCreateStruct
>  j2d_mlib_ImageDelete
>
> java.desktop/libawt on solaris: This is now also exported due to 
> JNIEXPORT:
>  GrPrim_CompGetXorColor
>  SurfaceData_GetOpsNoSetup
>  SurfaceData_IntersectBoundsXYWH
>  SurfaceData_SetOps
>  Transform_GetInfo
>  Transform_transform
>
> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and 
> solaris due to JNIEXPORT.
> libspashscreen also had JNIEXPORT (actually a pure 
> _declspec(dllexport)) but no JNICALL, which I added as
> a part of converting to JNIEXPORT. The same goes for libmlib_image .
>
> jdk.sctp/libsctp: handleSocketError is now exported on linux and 
> solaris due to JNIEXPORT in libnio.
>
> java.instrument:/libinstrument: Agent_OnUnload is now also exported on 
> linux and solaris platforms due to JNIEXPORT.
> JLI_ManifestIterate is now also exported on Windows, due to added 
> JNIEXPORT in libjli.
>
> jdk.management/libmanagement_ext: 
> Java_com_sun_management_internal_Flag_setDoubleValue is now also 
> exported on linux and solaris platforms due to JNIEXPORT.
>
> /Magnus
>
>


From philip.race at oracle.com  Fri Mar 23 18:01:34 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 23 Mar 2018 11:01:34 -0700
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <359e997c-6f49-218b-a1e6-81888135242b@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <359e997c-6f49-218b-a1e6-81888135242b@oracle.com>
Message-ID: <96a6b8d6-d979-9cc9-6d51-7c6f0926bf97@oracle.com>


http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h.udiff.html

The variable definitions here are now misaligned.

..and added 2d-dev since many of these native changes are in 2d.

-phil.

On 03/23/2018 10:33 AM, Phil Race wrote:
> There are a lot of changes in the desktop libraries.
> Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those 
> since
> only tier3 has any UI tests and it barely uses anything that's touched 
> here.
> So since testing seems to be wise, then I think you should do a
> jtreg desktop group run on Linux & Windows.
> You can probably skip Mac since it is unaffected and I think Linux 
> will cover Solaris here.
> You should also do some headless testing.
>
> It could take some time to review this properly and decide what 
> changes are OK,
> what changes are something we should clean up later, and what changes 
> are something
> that ought to be addressed now ..
>
> I think I'd be mainly concerned that something fails due to a missing 
> symbol, or
> that for newly exported symbols if we ended up with duplicate symbols 
> as a result.
>
> The results of a test run will add confidence here.
>
> BTW I don't think you are right that
> java.desktop:/libawt_headless: The following symbols are now also 
> exported due to JNIEXPORT (they were previously
> ..
>  X11SurfaceData_GetOps
>
> It looks to me like it was previously exported.
>
>
> -phil.
>
>
>
> On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote:
>> With modern compilers, we can use compiler directives (such as 
>> _attribute__((visibility("default"))), or __declspec(dllexport)) to 
>> control symbol visibility, directly in the source code. This has 
>> historically not been present on all compilers, so we had to resort 
>> to using mapfiles (also known as linker scripts).
>>
>> This is no longer the case. Now all compilers we use support symbol 
>> visibility directives, in one form or another. We should start using 
>> this. Since this has been the only way to control symbol visibility 
>> on Windows, for most of the shared code, we already have proper 
>> JNIEXPORT decorations in place.
>>
>> If we fix the remaining platform-specific files to have proper 
>> JNIEXPORT tagging, then we can finally get rid of mapfiles.
>>
>> This fix removed mapfiles for all JDK libraries. It does not touch 
>> hotspot libraries nor JDK executables; they will have to wait for a 
>> future fix -- this was complex enough. This change will not have any 
>> impact on macosx, since we do not use mapfiles there, but instead 
>> export all symbols. (This is not a good idea, but I'll address that 
>> separately.) This change will also have a minimal impact on Windows. 
>> The only reason Windows is impacted at all, is that some changes 
>> needed by Solaris and Linux were simpler to fix for all platforms.
>>
>> I have strived for this change to have no impact on the actual 
>> generated code. Unfortunately, this was not possible to fully 
>> achieve. I do not believe that these changes will have any actual 
>> impact on the product, though. I will present the differences more in 
>> detail further down. Those who are not interested can probably skip 
>> that.
>>
>> The patch has passed tier1 testing and is currently running tier2 and 
>> tier3. Since the running code is more or less (see caveat below) 
>> unmodified, I don't expect any testing issues.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01
>>
>> Details on changes:
>> Most of the source code changes are (unsurprisingly) in java.base and 
>> java.desktop. Remaining changes are in jdk.crypto.ucrypto, 
>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent.
>>
>> Source code changes does almost to 100% consists in decorating an 
>> exported function with JNIEXPORT. I have also followed the 
>> long-standing convention of adding JNICALL. This is a no-op on 
>> non-Windows platforms, so for most of the changes this is purely 
>> cosmetic (and possibly adding in robustness, should the function ever 
>> be used on Windows in the future). I have also followed the stylistic 
>> convention of putting "JNIEXPORT <return type> JNICALL" on a separate 
>> line. For some functions, however, this might cause a change in 
>> calling convention on Windows. Since this can not apply to exported 
>> functions on Windows (otherwise they would already have had 
>> JNIEXPORT), I do not think this matters anything.
>>
>> A few libraries did not have a mapfile, on Linux and/or Solaris. This 
>> actually meant that all symbols were exported. It is highly unclear 
>> if this was known and intended by the original make rule writer. I 
>> have emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these 
>> libraries. Hopefully, we can remove this flag and fix proper exported 
>> symbols in the future.
>>
>> I have run the complete build using COMPARE_BUILD, and made a 
>> thourough analysis of the differences for Linux and Solaris. All 
>> native libraries have symbol differences, but most of them are 
>> trivial and/or harmless. As a result, most libraries have disasm 
>> differences as well, but these too seem trivial and harmless. The 
>> differences in symbols that are common to all libraries include:
>>  * Internal symbols such as __bss_start, _edata, _end and _fini are 
>> now global. (They are imported as such from the compiler 
>> libraries/archives, and we have no linker script to override this 
>> behavior).
>>  * The versioning tag SUNWprivate_1.1 is not included, and thus 
>> neither the .gnu.version_d symbol.
>>  * There are a few differences in the symbol and/or mangling of some 
>> local functions. I'm not sure what's causing this,
>> but it's unlikely to have any effect on the product.
>>
>> Another common source for change in symbols is due to previous 
>> platform differences. For instance, if we had "JNIEXPORT int JNICALL 
>> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was 
>> exported on Windows but not on Linux and Solaris. (Presumable since 
>> it was not needed there, even though it was compiled for those 
>> platforms as well.) Now, with the mapfiles gone, do_foo() will be 
>> exported on all platforms. And contrary, functions that are compiled 
>> on all platforms, and were exported in mapfiles, but now have gotten 
>> an JNIEXPORT decoration, will now be visible even on Windows. (This 
>> accounts for half of the noticed symbol differences on Windows.) I 
>> could have made the JNIEXPORT conditional on OS, but I didn't think 
>> the mess in source code were worth the keeping of binary confidence 
>> with the old build.
>>
>> A third common source for change in symbols is due to exported 
>> functions "leaking" across library borders. For instance, some 
>> functions in java.desktop is compiled in both libawt_xawt and 
>> libawt_headless, but they were previously only included in the 
>> mapfile for one of these libraries. Now, since the visibility is 
>> determined by the source code itself, it gets exported in both 
>> libraries. A variant of this is when a library depends on another JDK 
>> library, and includes the header file from that other library, which 
>> in turn declares a function as JNIEXPORT. This will cause the 
>> including library to also export the function. This accounts for the 
>> other half of the changes on Windows. A typical example of this is 
>> that multiple libraries now re-export hotspot symbols from libjvm.so, 
>> like jio_fprintf. (I have not listed the libjvm re-exports below.)
>>
>> Note that  Java_java_io_FileOutputStream_close0 in 
>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer 
>> exported,
>> and can probably be removed.
>>
>> Here is a detailed table showing and accounting for all the remaining 
>> differences found on Linux and Solaris:
>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 
>> is now also exported on unix platforms due to JNIEXPORT.
>>
>> java.base/jspawnlauncher: On solaris, we also include 
>> libjava/childproc.o, which
>> now exports less functions than it used to (it used to export all 
>> functions, now it is compiled with visibility=hidden).
>>
>> java.base/java(w).exe: Is now also exporting the following symbols 
>> due to added JNIEXPORT in libjli on Windows:
>> (Yes, executables can export symbols on Windows. Confusing, I know.)
>>  JLI_AddArgsFromEnvVar
>>  JLI_CmdToArgs
>>  JLI_GetAppArgIndex
>>  JLI_GetStdArgc
>>  JLI_GetStdArgs
>>  JLI_InitArgProcessing
>>  JLI_Launch
>>  JLI_List_add
>>  JLI_List_new
>>  JLI_ManifestIterate
>>  JLI_MemAlloc
>>  JLI_MemFree
>>  JLI_PreprocessArg
>>  JLI_ReportErrorMessage
>>  JLI_ReportErrorMessageSys
>>  JLI_ReportExceptionDescription
>>  JLI_ReportMessage
>>  JLI_SetTraceLauncher
>>  JLI_StringDup
>>
>> java.desktop:/libawt_xawt: The following symbols are now also 
>> exported on linux and solaris due to JNIEXPORT:
>>  awt_DrawingSurface_FreeDrawingSurfaceInfo
>>  awt_DrawingSurface_GetDrawingSurfaceInfo
>>  awt_DrawingSurface_Lock
>>  awt_DrawingSurface_Unlock
>>  awt_GetColor
>>
>> The following symbols are now also exported on linux and solaris due 
>> to JNIEXPORT (they were previously
>>  exported only in libawt):
>>  Java_sun_awt_DebugSettings_setCTracingOn__Z
>>  Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2
>>  Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I
>>  Java_sun_awt_X11GraphicsConfig_getNumColors
>>
>> java.desktop:/libawt_headless: The following symbols are now also 
>> exported due to JNIEXPORT (they were previously
>>  exported only in libawt_xawt and/or libawt):
>>  Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo
>>  Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities
>>  Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask
>>  Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable
>>  X11SurfaceData_GetOps
>>
>> java.desktop/libawt: The following symbols are now also exported on 
>> Windows, due to added
>> JNIEXPORT:
>>  SurfaceData_InitOps
>>  mul8table
>>  div8table
>>  doDrawPath
>>  doFillPath
>>  g_CMpDataID
>>  initInverseGrayLut
>>  make_dither_arrays
>>  make_uns_ordered_dither_array
>>  path2DFloatCoordsID
>>  path2DNumTypesID
>>  path2DTypesID
>>  path2DWindingRuleID
>>  sg2dStrokeHintID
>>  std_img_oda_blue
>>  std_img_oda_green
>>  std_img_oda_red
>>  std_odas_computed
>>  sunHints_INTVAL_STROKE_PURE
>>
>> java.desktop/libawt on solaris:
>> A number of "#pragma weak" directives was previously overridden by 
>> the mapfile.
>> Now these directives are respected, so these symbols are now weak 
>> instead of local:
>>  ByteGrayToIntArgbPreConvert_F
>>  ByteGrayToIntArgbPreScaleConvert_F
>>  IntArgbBmToFourByteAbgrPreScaleXparOver_F
>>  IntArgbToIntRgbXorBlit_F
>>  IntBgrToIntBgrAlphaMaskBlit_F
>>
>> java.desktop/libawt on solaris: These are now also exported due to 
>> JNIEXPORT in libmlib_image.
>>  j2d_mlib_ImageCreate
>>  j2d_mlib_ImageCreateStruct
>>  j2d_mlib_ImageDelete
>>
>> java.desktop/libawt on solaris: This is now also exported due to 
>> JNIEXPORT:
>>  GrPrim_CompGetXorColor
>>  SurfaceData_GetOpsNoSetup
>>  SurfaceData_IntersectBoundsXYWH
>>  SurfaceData_SetOps
>>  Transform_GetInfo
>>  Transform_transform
>>
>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and 
>> solaris due to JNIEXPORT.
>> libspashscreen also had JNIEXPORT (actually a pure 
>> _declspec(dllexport)) but no JNICALL, which I added as
>> a part of converting to JNIEXPORT. The same goes for libmlib_image .
>>
>> jdk.sctp/libsctp: handleSocketError is now exported on linux and 
>> solaris due to JNIEXPORT in libnio.
>>
>> java.instrument:/libinstrument: Agent_OnUnload is now also exported 
>> on linux and solaris platforms due to JNIEXPORT.
>> JLI_ManifestIterate is now also exported on Windows, due to added 
>> JNIEXPORT in libjli.
>>
>> jdk.management/libmanagement_ext: 
>> Java_com_sun_management_internal_Flag_setDoubleValue is now also 
>> exported on linux and solaris platforms due to JNIEXPORT.
>>
>> /Magnus
>>
>>
>


From magnus.ihse.bursie at oracle.com  Fri Mar 23 20:36:29 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 23 Mar 2018 21:36:29 +0100
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <96a6b8d6-d979-9cc9-6d51-7c6f0926bf97@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <359e997c-6f49-218b-a1e6-81888135242b@oracle.com>
 <96a6b8d6-d979-9cc9-6d51-7c6f0926bf97@oracle.com>
Message-ID: <2db2ec37-b561-3f93-623b-14ddbc615381@oracle.com>


On 2018-03-23 19:01, Phil Race wrote:
>
> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h.udiff.html 
>
>
> The variable definitions here are now misaligned.
No, they are not. That's just an artifact of webrev, which filters out 
whitespace changes in the diff view. :-( To see the proper changes, 
including whitespace, you need to download the patch file.

I've gone to great pains to mimick the existing style in the source 
codes I've made changes to.

/Magnus

>
> ..and added 2d-dev since many of these native changes are in 2d.
>
> -phil.
>
> On 03/23/2018 10:33 AM, Phil Race wrote:
>> There are a lot of changes in the desktop libraries.
>> Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those 
>> since
>> only tier3 has any UI tests and it barely uses anything that's 
>> touched here.
>> So since testing seems to be wise, then I think you should do a
>> jtreg desktop group run on Linux & Windows.
>> You can probably skip Mac since it is unaffected and I think Linux 
>> will cover Solaris here.
>> You should also do some headless testing.
>>
>> It could take some time to review this properly and decide what 
>> changes are OK,
>> what changes are something we should clean up later, and what changes 
>> are something
>> that ought to be addressed now ..
>>
>> I think I'd be mainly concerned that something fails due to a missing 
>> symbol, or
>> that for newly exported symbols if we ended up with duplicate symbols 
>> as a result.
>>
>> The results of a test run will add confidence here.
>>
>> BTW I don't think you are right that
>> java.desktop:/libawt_headless: The following symbols are now also 
>> exported due to JNIEXPORT (they were previously
>> ..
>> ?X11SurfaceData_GetOps
>>
>> It looks to me like it was previously exported.
>>
>>
>> -phil.
>>
>>
>>
>> On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote:
>>> With modern compilers, we can use compiler directives (such as 
>>> _attribute__((visibility("default"))), or __declspec(dllexport)) to 
>>> control symbol visibility, directly in the source code. This has 
>>> historically not been present on all compilers, so we had to resort 
>>> to using mapfiles (also known as linker scripts).
>>>
>>> This is no longer the case. Now all compilers we use support symbol 
>>> visibility directives, in one form or another. We should start using 
>>> this. Since this has been the only way to control symbol visibility 
>>> on Windows, for most of the shared code, we already have proper 
>>> JNIEXPORT decorations in place.
>>>
>>> If we fix the remaining platform-specific files to have proper 
>>> JNIEXPORT tagging, then we can finally get rid of mapfiles.
>>>
>>> This fix removed mapfiles for all JDK libraries. It does not touch 
>>> hotspot libraries nor JDK executables; they will have to wait for a 
>>> future fix -- this was complex enough. This change will not have any 
>>> impact on macosx, since we do not use mapfiles there, but instead 
>>> export all symbols. (This is not a good idea, but I'll address that 
>>> separately.) This change will also have a minimal impact on Windows. 
>>> The only reason Windows is impacted at all, is that some changes 
>>> needed by Solaris and Linux were simpler to fix for all platforms.
>>>
>>> I have strived for this change to have no impact on the actual 
>>> generated code. Unfortunately, this was not possible to fully 
>>> achieve. I do not believe that these changes will have any actual 
>>> impact on the product, though. I will present the differences more 
>>> in detail further down. Those who are not interested can probably 
>>> skip that.
>>>
>>> The patch has passed tier1 testing and is currently running tier2 
>>> and tier3. Since the running code is more or less (see caveat below) 
>>> unmodified, I don't expect any testing issues.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01
>>>
>>> Details on changes:
>>> Most of the source code changes are (unsurprisingly) in java.base 
>>> and java.desktop. Remaining changes are in jdk.crypto.ucrypto, 
>>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent.
>>>
>>> Source code changes does almost to 100% consists in decorating an 
>>> exported function with JNIEXPORT. I have also followed the 
>>> long-standing convention of adding JNICALL. This is a no-op on 
>>> non-Windows platforms, so for most of the changes this is purely 
>>> cosmetic (and possibly adding in robustness, should the function 
>>> ever be used on Windows in the future). I have also followed the 
>>> stylistic convention of putting "JNIEXPORT <return type> JNICALL" on 
>>> a separate line. For some functions, however, this might cause a 
>>> change in calling convention on Windows. Since this can not apply to 
>>> exported functions on Windows (otherwise they would already have had 
>>> JNIEXPORT), I do not think this matters anything.
>>>
>>> A few libraries did not have a mapfile, on Linux and/or Solaris. 
>>> This actually meant that all symbols were exported. It is highly 
>>> unclear if this was known and intended by the original make rule 
>>> writer. I have emulated this by adding the flag 
>>> $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully, we can remove 
>>> this flag and fix proper exported symbols in the future.
>>>
>>> I have run the complete build using COMPARE_BUILD, and made a 
>>> thourough analysis of the differences for Linux and Solaris. All 
>>> native libraries have symbol differences, but most of them are 
>>> trivial and/or harmless. As a result, most libraries have disasm 
>>> differences as well, but these too seem trivial and harmless. The 
>>> differences in symbols that are common to all libraries include:
>>> ?* Internal symbols such as __bss_start, _edata, _end and _fini are 
>>> now global. (They are imported as such from the compiler 
>>> libraries/archives, and we have no linker script to override this 
>>> behavior).
>>> ?* The versioning tag SUNWprivate_1.1 is not included, and thus 
>>> neither the .gnu.version_d symbol.
>>> ?* There are a few differences in the symbol and/or mangling of some 
>>> local functions. I'm not sure what's causing this,
>>> but it's unlikely to have any effect on the product.
>>>
>>> Another common source for change in symbols is due to previous 
>>> platform differences. For instance, if we had "JNIEXPORT int JNICALL 
>>> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was 
>>> exported on Windows but not on Linux and Solaris. (Presumable since 
>>> it was not needed there, even though it was compiled for those 
>>> platforms as well.) Now, with the mapfiles gone, do_foo() will be 
>>> exported on all platforms. And contrary, functions that are compiled 
>>> on all platforms, and were exported in mapfiles, but now have gotten 
>>> an JNIEXPORT decoration, will now be visible even on Windows. (This 
>>> accounts for half of the noticed symbol differences on Windows.) I 
>>> could have made the JNIEXPORT conditional on OS, but I didn't think 
>>> the mess in source code were worth the keeping of binary confidence 
>>> with the old build.
>>>
>>> A third common source for change in symbols is due to exported 
>>> functions "leaking" across library borders. For instance, some 
>>> functions in java.desktop is compiled in both libawt_xawt and 
>>> libawt_headless, but they were previously only included in the 
>>> mapfile for one of these libraries. Now, since the visibility is 
>>> determined by the source code itself, it gets exported in both 
>>> libraries. A variant of this is when a library depends on another 
>>> JDK library, and includes the header file from that other library, 
>>> which in turn declares a function as JNIEXPORT. This will cause the 
>>> including library to also export the function. This accounts for the 
>>> other half of the changes on Windows. A typical example of this is 
>>> that multiple libraries now re-export hotspot symbols from 
>>> libjvm.so, like jio_fprintf. (I have not listed the libjvm 
>>> re-exports below.)
>>>
>>> Note that? Java_java_io_FileOutputStream_close0 in 
>>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer 
>>> exported,
>>> and can probably be removed.
>>>
>>> Here is a detailed table showing and accounting for all the 
>>> remaining differences found on Linux and Solaris:
>>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 
>>> is now also exported on unix platforms due to JNIEXPORT.
>>>
>>> java.base/jspawnlauncher: On solaris, we also include 
>>> libjava/childproc.o, which
>>> now exports less functions than it used to (it used to export all 
>>> functions, now it is compiled with visibility=hidden).
>>>
>>> java.base/java(w).exe: Is now also exporting the following symbols 
>>> due to added JNIEXPORT in libjli on Windows:
>>> (Yes, executables can export symbols on Windows. Confusing, I know.)
>>> ?JLI_AddArgsFromEnvVar
>>> ?JLI_CmdToArgs
>>> ?JLI_GetAppArgIndex
>>> ?JLI_GetStdArgc
>>> ?JLI_GetStdArgs
>>> ?JLI_InitArgProcessing
>>> ?JLI_Launch
>>> ?JLI_List_add
>>> ?JLI_List_new
>>> ?JLI_ManifestIterate
>>> ?JLI_MemAlloc
>>> ?JLI_MemFree
>>> ?JLI_PreprocessArg
>>> ?JLI_ReportErrorMessage
>>> ?JLI_ReportErrorMessageSys
>>> ?JLI_ReportExceptionDescription
>>> ?JLI_ReportMessage
>>> ?JLI_SetTraceLauncher
>>> ?JLI_StringDup
>>>
>>> java.desktop:/libawt_xawt: The following symbols are now also 
>>> exported on linux and solaris due to JNIEXPORT:
>>> ?awt_DrawingSurface_FreeDrawingSurfaceInfo
>>> ?awt_DrawingSurface_GetDrawingSurfaceInfo
>>> ?awt_DrawingSurface_Lock
>>> ?awt_DrawingSurface_Unlock
>>> ?awt_GetColor
>>>
>>> The following symbols are now also exported on linux and solaris due 
>>> to JNIEXPORT (they were previously
>>> ?exported only in libawt):
>>> ?Java_sun_awt_DebugSettings_setCTracingOn__Z
>>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2
>>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I
>>> ?Java_sun_awt_X11GraphicsConfig_getNumColors
>>>
>>> java.desktop:/libawt_headless: The following symbols are now also 
>>> exported due to JNIEXPORT (they were previously
>>> ?exported only in libawt_xawt and/or libawt):
>>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo
>>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities
>>> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask
>>> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable
>>> ?X11SurfaceData_GetOps
>>>
>>> java.desktop/libawt: The following symbols are now also exported on 
>>> Windows, due to added
>>> JNIEXPORT:
>>> ?SurfaceData_InitOps
>>> ?mul8table
>>> ?div8table
>>> ?doDrawPath
>>> ?doFillPath
>>> ?g_CMpDataID
>>> ?initInverseGrayLut
>>> ?make_dither_arrays
>>> ?make_uns_ordered_dither_array
>>> ?path2DFloatCoordsID
>>> ?path2DNumTypesID
>>> ?path2DTypesID
>>> ?path2DWindingRuleID
>>> ?sg2dStrokeHintID
>>> ?std_img_oda_blue
>>> ?std_img_oda_green
>>> ?std_img_oda_red
>>> ?std_odas_computed
>>> ?sunHints_INTVAL_STROKE_PURE
>>>
>>> java.desktop/libawt on solaris:
>>> A number of "#pragma weak" directives was previously overridden by 
>>> the mapfile.
>>> Now these directives are respected, so these symbols are now weak 
>>> instead of local:
>>> ?ByteGrayToIntArgbPreConvert_F
>>> ?ByteGrayToIntArgbPreScaleConvert_F
>>> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F
>>> ?IntArgbToIntRgbXorBlit_F
>>> ?IntBgrToIntBgrAlphaMaskBlit_F
>>>
>>> java.desktop/libawt on solaris: These are now also exported due to 
>>> JNIEXPORT in libmlib_image.
>>> ?j2d_mlib_ImageCreate
>>> ?j2d_mlib_ImageCreateStruct
>>> ?j2d_mlib_ImageDelete
>>>
>>> java.desktop/libawt on solaris: This is now also exported due to 
>>> JNIEXPORT:
>>> ?GrPrim_CompGetXorColor
>>> ?SurfaceData_GetOpsNoSetup
>>> ?SurfaceData_IntersectBoundsXYWH
>>> ?SurfaceData_SetOps
>>> ?Transform_GetInfo
>>> ?Transform_transform
>>>
>>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux 
>>> and solaris due to JNIEXPORT.
>>> libspashscreen also had JNIEXPORT (actually a pure 
>>> _declspec(dllexport)) but no JNICALL, which I added as
>>> a part of converting to JNIEXPORT. The same goes for libmlib_image .
>>>
>>> jdk.sctp/libsctp: handleSocketError is now exported on linux and 
>>> solaris due to JNIEXPORT in libnio.
>>>
>>> java.instrument:/libinstrument: Agent_OnUnload is now also exported 
>>> on linux and solaris platforms due to JNIEXPORT.
>>> JLI_ManifestIterate is now also exported on Windows, due to added 
>>> JNIEXPORT in libjli.
>>>
>>> jdk.management/libmanagement_ext: 
>>> Java_com_sun_management_internal_Flag_setDoubleValue is now also 
>>> exported on linux and solaris platforms due to JNIEXPORT.
>>>
>>> /Magnus
>>>
>>>
>>
>


From magnus.ihse.bursie at oracle.com  Fri Mar 23 21:08:35 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 23 Mar 2018 22:08:35 +0100
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <359e997c-6f49-218b-a1e6-81888135242b@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <359e997c-6f49-218b-a1e6-81888135242b@oracle.com>
Message-ID: <e0849fd7-2dd9-5048-53b4-17508eec5cc4@oracle.com>

On 2018-03-23 18:33, Phil Race wrote:
> There are a lot of changes in the desktop libraries.
Well, yes and no. While there are multiple touched files, the resulting 
native shared libraries that are built have very minimal changes in 
them. (That's the view point from the build guy, you know :))

> Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those 
> since
> only tier3 has any UI tests and it barely uses anything that's touched 
> here.
> So since testing seems to be wise, then I think you should do a
> jtreg desktop group run on Linux & Windows.
There is next to *no* difference for java.desktop on Windows. The only, 
very subtle, difference, is that awt.dll now exports 18 more functions 
(totalling 800, instead of 782). I can't even begin to imagine how 
anything could fail due to this additional exporting. Not even the 
disassembly of the machine code of awt.dll is different from before, not 
a single byte. So I don't buy it that I need to do extensive client 
testing on Windows.

> You can probably skip Mac since it is unaffected and I think Linux 
> will cover Solaris here.
> You should also do some headless testing.
I agree that it seems prudent to do some Linux/Solaris testing, since 
changes there are more wide spread. Could you please point me to some 
guidance on how to run these tests? (You can do it off list)
> It could take some time to review this properly and decide what 
> changes are OK,
> what changes are something we should clean up later, and what changes 
> are something
> that ought to be addressed now ..
As I said, I am going to file follow-up bugs for suspicious handling of 
exported symbols. These follow-up bugs will be separated per component 
team, unlike this fix, which by necessity addresses all JDK libraries at 
once. So you will get plenty of time to consider ways of cleaning up any 
exports handling that you do not like. It would be a pity if this entire 
checkin was delayed since the client team could not accept the changes 
needed in client libraries. :-(

And frankly, I believe the java.desktop libs needs some serious 
refactoring to get to grip with the exported symbols situation. The 
major cause of problems is, I believe, rooted in a non-optimal split of 
functionality between libawt, libawt_xawt and libawt_headless. This is 
not likely something that can be addressed in this change.

> I think I'd be mainly concerned that something fails due to a missing 
> symbol, or
> that for newly exported symbols if we ended up with duplicate symbols 
> as a result.

Once again, I've run the COMPARE_BUILD script on this patch. Let me 
explain a bit more in detail what it does, since that might be known 
only to us in the build team. This script analyses the build result, the 
jmods, the lib*.so files, etc. The basic idea here is that a change in 
the build system, which does not produce a change in the build result, 
is "transparent" to the product. There is e.g. no reason to run any 
further testing, since we're in effect testing the same bits. For many 
changes in the build system, we hold this as the gold standard.

For this particular change, to achieve this kind of fidelity would have 
come with a too high price in code complexity, so I have allowed certain 
small deviations. These are really minimal, and should in most cases be 
undetectable by the product. The changes in Linux and Solaris that have 
occured, is those that I listed in my review mail. Basically, for some 
libraries, additional symbols are exported. I could fix this, but only 
at the expense of more complex code. While it's a good thing to minimize 
the functions exported, a handful extra symbols is not a disaster. (We 
have more important issues to address in our native libraries.)

For the AWT libraries, most of the duplicates are coming from the source 
code that are shared between libraries, in 
java.desktop/share/native/common. This means that the same function is 
compiled into -- and now also exported from -- multiple libraries. This 
is not a big deal. Even if we were to link with two libraries defining 
the same symbol, the dynamic linker will arbitrarily chose one of them, 
but since they are identical, it does not matter. (It's another thing if 
they implement different functions, as you noted yourself in the bugs 
about linking with awt_xawt vs doing a runtime linking to awt_headless).

Also, I guarantee you that in no way are there missing symbols in the 
refactored build. I've checked, double-checked and triple-checked that.

> The results of a test run will add confidence here.
>
> BTW I don't think you are right that
> java.desktop:/libawt_headless: The following symbols are now also 
> exported due to JNIEXPORT (they were previously
> ..
> ?X11SurfaceData_GetOps
>
> It looks to me like it was previously exported.
You are correct, it was previously exported in libawt_headless. I meant 
that it is now also exported for libawt_xawt due to the JNIEXPORT. Sorry 
for mixing this up.

/Magnus

>
>
> -phil.
>
>
>
> On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote:
>> With modern compilers, we can use compiler directives (such as 
>> _attribute__((visibility("default"))), or __declspec(dllexport)) to 
>> control symbol visibility, directly in the source code. This has 
>> historically not been present on all compilers, so we had to resort 
>> to using mapfiles (also known as linker scripts).
>>
>> This is no longer the case. Now all compilers we use support symbol 
>> visibility directives, in one form or another. We should start using 
>> this. Since this has been the only way to control symbol visibility 
>> on Windows, for most of the shared code, we already have proper 
>> JNIEXPORT decorations in place.
>>
>> If we fix the remaining platform-specific files to have proper 
>> JNIEXPORT tagging, then we can finally get rid of mapfiles.
>>
>> This fix removed mapfiles for all JDK libraries. It does not touch 
>> hotspot libraries nor JDK executables; they will have to wait for a 
>> future fix -- this was complex enough. This change will not have any 
>> impact on macosx, since we do not use mapfiles there, but instead 
>> export all symbols. (This is not a good idea, but I'll address that 
>> separately.) This change will also have a minimal impact on Windows. 
>> The only reason Windows is impacted at all, is that some changes 
>> needed by Solaris and Linux were simpler to fix for all platforms.
>>
>> I have strived for this change to have no impact on the actual 
>> generated code. Unfortunately, this was not possible to fully 
>> achieve. I do not believe that these changes will have any actual 
>> impact on the product, though. I will present the differences more in 
>> detail further down. Those who are not interested can probably skip 
>> that.
>>
>> The patch has passed tier1 testing and is currently running tier2 and 
>> tier3. Since the running code is more or less (see caveat below) 
>> unmodified, I don't expect any testing issues.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01
>>
>> Details on changes:
>> Most of the source code changes are (unsurprisingly) in java.base and 
>> java.desktop. Remaining changes are in jdk.crypto.ucrypto, 
>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent.
>>
>> Source code changes does almost to 100% consists in decorating an 
>> exported function with JNIEXPORT. I have also followed the 
>> long-standing convention of adding JNICALL. This is a no-op on 
>> non-Windows platforms, so for most of the changes this is purely 
>> cosmetic (and possibly adding in robustness, should the function ever 
>> be used on Windows in the future). I have also followed the stylistic 
>> convention of putting "JNIEXPORT <return type> JNICALL" on a separate 
>> line. For some functions, however, this might cause a change in 
>> calling convention on Windows. Since this can not apply to exported 
>> functions on Windows (otherwise they would already have had 
>> JNIEXPORT), I do not think this matters anything.
>>
>> A few libraries did not have a mapfile, on Linux and/or Solaris. This 
>> actually meant that all symbols were exported. It is highly unclear 
>> if this was known and intended by the original make rule writer. I 
>> have emulated this by adding the flag $(EXPORT_ALL_SYMBOLS) to these 
>> libraries. Hopefully, we can remove this flag and fix proper exported 
>> symbols in the future.
>>
>> I have run the complete build using COMPARE_BUILD, and made a 
>> thourough analysis of the differences for Linux and Solaris. All 
>> native libraries have symbol differences, but most of them are 
>> trivial and/or harmless. As a result, most libraries have disasm 
>> differences as well, but these too seem trivial and harmless. The 
>> differences in symbols that are common to all libraries include:
>> ?* Internal symbols such as __bss_start, _edata, _end and _fini are 
>> now global. (They are imported as such from the compiler 
>> libraries/archives, and we have no linker script to override this 
>> behavior).
>> ?* The versioning tag SUNWprivate_1.1 is not included, and thus 
>> neither the .gnu.version_d symbol.
>> ?* There are a few differences in the symbol and/or mangling of some 
>> local functions. I'm not sure what's causing this,
>> but it's unlikely to have any effect on the product.
>>
>> Another common source for change in symbols is due to previous 
>> platform differences. For instance, if we had "JNIEXPORT int JNICALL 
>> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was 
>> exported on Windows but not on Linux and Solaris. (Presumable since 
>> it was not needed there, even though it was compiled for those 
>> platforms as well.) Now, with the mapfiles gone, do_foo() will be 
>> exported on all platforms. And contrary, functions that are compiled 
>> on all platforms, and were exported in mapfiles, but now have gotten 
>> an JNIEXPORT decoration, will now be visible even on Windows. (This 
>> accounts for half of the noticed symbol differences on Windows.) I 
>> could have made the JNIEXPORT conditional on OS, but I didn't think 
>> the mess in source code were worth the keeping of binary confidence 
>> with the old build.
>>
>> A third common source for change in symbols is due to exported 
>> functions "leaking" across library borders. For instance, some 
>> functions in java.desktop is compiled in both libawt_xawt and 
>> libawt_headless, but they were previously only included in the 
>> mapfile for one of these libraries. Now, since the visibility is 
>> determined by the source code itself, it gets exported in both 
>> libraries. A variant of this is when a library depends on another JDK 
>> library, and includes the header file from that other library, which 
>> in turn declares a function as JNIEXPORT. This will cause the 
>> including library to also export the function. This accounts for the 
>> other half of the changes on Windows. A typical example of this is 
>> that multiple libraries now re-export hotspot symbols from libjvm.so, 
>> like jio_fprintf. (I have not listed the libjvm re-exports below.)
>>
>> Note that? Java_java_io_FileOutputStream_close0 in 
>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer 
>> exported,
>> and can probably be removed.
>>
>> Here is a detailed table showing and accounting for all the remaining 
>> differences found on Linux and Solaris:
>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 
>> is now also exported on unix platforms due to JNIEXPORT.
>>
>> java.base/jspawnlauncher: On solaris, we also include 
>> libjava/childproc.o, which
>> now exports less functions than it used to (it used to export all 
>> functions, now it is compiled with visibility=hidden).
>>
>> java.base/java(w).exe: Is now also exporting the following symbols 
>> due to added JNIEXPORT in libjli on Windows:
>> (Yes, executables can export symbols on Windows. Confusing, I know.)
>> ?JLI_AddArgsFromEnvVar
>> ?JLI_CmdToArgs
>> ?JLI_GetAppArgIndex
>> ?JLI_GetStdArgc
>> ?JLI_GetStdArgs
>> ?JLI_InitArgProcessing
>> ?JLI_Launch
>> ?JLI_List_add
>> ?JLI_List_new
>> ?JLI_ManifestIterate
>> ?JLI_MemAlloc
>> ?JLI_MemFree
>> ?JLI_PreprocessArg
>> ?JLI_ReportErrorMessage
>> ?JLI_ReportErrorMessageSys
>> ?JLI_ReportExceptionDescription
>> ?JLI_ReportMessage
>> ?JLI_SetTraceLauncher
>> ?JLI_StringDup
>>
>> java.desktop:/libawt_xawt: The following symbols are now also 
>> exported on linux and solaris due to JNIEXPORT:
>> ?awt_DrawingSurface_FreeDrawingSurfaceInfo
>> ?awt_DrawingSurface_GetDrawingSurfaceInfo
>> ?awt_DrawingSurface_Lock
>> ?awt_DrawingSurface_Unlock
>> ?awt_GetColor
>>
>> The following symbols are now also exported on linux and solaris due 
>> to JNIEXPORT (they were previously
>> ?exported only in libawt):
>> ?Java_sun_awt_DebugSettings_setCTracingOn__Z
>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2
>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I
>> ?Java_sun_awt_X11GraphicsConfig_getNumColors
>>
>> java.desktop:/libawt_headless: The following symbols are now also 
>> exported due to JNIEXPORT (they were previously
>> ?exported only in libawt_xawt and/or libawt):
>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo
>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities
>> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask
>> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable
>> ?X11SurfaceData_GetOps
>>
>> java.desktop/libawt: The following symbols are now also exported on 
>> Windows, due to added
>> JNIEXPORT:
>> ?SurfaceData_InitOps
>> ?mul8table
>> ?div8table
>> ?doDrawPath
>> ?doFillPath
>> ?g_CMpDataID
>> ?initInverseGrayLut
>> ?make_dither_arrays
>> ?make_uns_ordered_dither_array
>> ?path2DFloatCoordsID
>> ?path2DNumTypesID
>> ?path2DTypesID
>> ?path2DWindingRuleID
>> ?sg2dStrokeHintID
>> ?std_img_oda_blue
>> ?std_img_oda_green
>> ?std_img_oda_red
>> ?std_odas_computed
>> ?sunHints_INTVAL_STROKE_PURE
>>
>> java.desktop/libawt on solaris:
>> A number of "#pragma weak" directives was previously overridden by 
>> the mapfile.
>> Now these directives are respected, so these symbols are now weak 
>> instead of local:
>> ?ByteGrayToIntArgbPreConvert_F
>> ?ByteGrayToIntArgbPreScaleConvert_F
>> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F
>> ?IntArgbToIntRgbXorBlit_F
>> ?IntBgrToIntBgrAlphaMaskBlit_F
>>
>> java.desktop/libawt on solaris: These are now also exported due to 
>> JNIEXPORT in libmlib_image.
>> ?j2d_mlib_ImageCreate
>> ?j2d_mlib_ImageCreateStruct
>> ?j2d_mlib_ImageDelete
>>
>> java.desktop/libawt on solaris: This is now also exported due to 
>> JNIEXPORT:
>> ?GrPrim_CompGetXorColor
>> ?SurfaceData_GetOpsNoSetup
>> ?SurfaceData_IntersectBoundsXYWH
>> ?SurfaceData_SetOps
>> ?Transform_GetInfo
>> ?Transform_transform
>>
>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and 
>> solaris due to JNIEXPORT.
>> libspashscreen also had JNIEXPORT (actually a pure 
>> _declspec(dllexport)) but no JNICALL, which I added as
>> a part of converting to JNIEXPORT. The same goes for libmlib_image .
>>
>> jdk.sctp/libsctp: handleSocketError is now exported on linux and 
>> solaris due to JNIEXPORT in libnio.
>>
>> java.instrument:/libinstrument: Agent_OnUnload is now also exported 
>> on linux and solaris platforms due to JNIEXPORT.
>> JLI_ManifestIterate is now also exported on Windows, due to added 
>> JNIEXPORT in libjli.
>>
>> jdk.management/libmanagement_ext: 
>> Java_com_sun_management_internal_Flag_setDoubleValue is now also 
>> exported on linux and solaris platforms due to JNIEXPORT.
>>
>> /Magnus
>>
>>
>


From magnus.ihse.bursie at oracle.com  Fri Mar 23 21:31:36 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 23 Mar 2018 22:31:36 +0100
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <CA+3eh10JirUDKXXUD6dd7=fFK9X_4iSNVpb4jHpvfi6CBaLFAQ@mail.gmail.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com>
 <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com>
 <CA+3eh10JirUDKXXUD6dd7=fFK9X_4iSNVpb4jHpvfi6CBaLFAQ@mail.gmail.com>
Message-ID: <278836b5-b49b-2409-f1b5-e05fdc0d2b30@oracle.com>

On 2018-03-23 18:24, Volker Simonis wrote:
> Hi Magnus,
>
> thanks for addressing this long standing issue! I haven't looked at
> the changes, but just want to share some general and historical notes:
>
> - Compiling with "-fvisibility=hidden" which hides all symbols expect
> the ones explicitly exported with
> "__attribute__((visibility("default")))" has been requested by SAP
> back in 2007 even before we had OpenJDK (see "Use -fvisibility=hidden
> for gcc compiles" https://bugs.openjdk.java.net/browse/JDK-6588413)
> and finally pushed into the OpenJKD around 2010.
> - "-fvisibility=hidden" gave us performance improvements of about 5%
> (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and 0,5%
> (JVM98) on Linux/PPC64 because the compiler could use faster calls for
> non exported symbols. This improvement was only very small on x86
> tough.
That's a nice side effect! Although my main purpose here is 
maintainability, gaining performance is nothing I say no to. :)
> - "-fvisibility=hidden"/"__attribute__((visibility("default")))"
> applies BEFORE using the map files in the linking step (i.e. hidden
> symbols can't be exported any more even if mentioned in the map file)
> - because of the performance improvements we got by using
> "-fvisibility=hidden" it was worth while using it even though we had
> the mapfiles at the end of the process.
>
> Then we had several mail threads (which you probably remember because
> you were involved :) where we discussed to either remove the map files
> completely or instead generate them automatically during the build:
>
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/thread.html#12412
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/thread.html#12628
>
> The main arguments against removing the map files at that time were:
>
> 1. the danger to re-export all symbols of statically linked libraries
> (notably libstdc++ at that time)
> 2. loosing exports of compiler generated symbols like vtables which
> are required by the Serviceability Agent
>
> Point 1 is not a problem today, because I don't think we do any static
> linking any more. If we still do it under some circumstances, this
> problem should be re-evaluated.
Well, we do static linking with libstdc++ on linux, in certain 
circumstances. See "--with-stdc++lib=<static>,<dynamic>,<default>". 
Fortunately, this is not a problem. The linker can be told not to 
include symbols from statically linked libraries, which is exactly what 
I do with LDFLAGS_JDKLIB += -Wl,--exclude-libs,ALL.

The corresponding feature does not exist for the solstudio linker, but 
fortunately we do not use statically linked libraries there.

> Point 2 is only relevant for HotSpot. But because of "8034065: GCC 4.3
> and later doesn't export vtable symbols any more which seem to be
> needed by SA" (https://bugs.openjdk.java.net/browse/JDK-8034065),
> exporting such symbols trough a map files doesn't work any more
> anyway. So this isn't a problem either.
In any case, that's a question for another day. :) There were reasons I 
left Hotspot out of this fix, and the question about the SA agent is one 
of them. :) As you say, I think they do not apply anymore, but I'll 
return to consider Hotspot later on.

> So to cut a long story short - I think the time is ripe to get rid of
> the map files. Thumbs up from me (meant as moral support, not as a
> concrete review :)
Thanks for the kind words!

/Magnus

>
> Regards,
> Volker
>
> On Fri, Mar 23, 2018 at 5:05 PM, mandy chung <mandy.chung at oracle.com> wrote:
>> This is a very good change and no more mapfile to maintain!!
>>
>> Please do file JBS issues for the component teams to clean up their exports.
>>
>> Mandy
>>
>>
>> On 3/23/18 7:30 AM, Erik Joelsson wrote:
>>> I have looked at the build changes and they look good.
>>>
>>> Will you file followups for each component team to look over their
>>> exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)? It
>>> sure looks like there is some technical debt laying around here.
>>>
>>> /Erik
>>>
>>>
>>> On 2018-03-23 06:56, Magnus Ihse Bursie wrote:
>>>> With modern compilers, we can use compiler directives (such as
>>>> _attribute__((visibility("default"))), or __declspec(dllexport)) to control
>>>> symbol visibility, directly in the source code. This has historically not
>>>> been present on all compilers, so we had to resort to using mapfiles (also
>>>> known as linker scripts).
>>>>
>>>> This is no longer the case. Now all compilers we use support symbol
>>>> visibility directives, in one form or another. We should start using this.
>>>> Since this has been the only way to control symbol visibility on Windows,
>>>> for most of the shared code, we already have proper JNIEXPORT decorations in
>>>> place.
>>>>
>>>> If we fix the remaining platform-specific files to have proper JNIEXPORT
>>>> tagging, then we can finally get rid of mapfiles.
>>>>
>>>> This fix removed mapfiles for all JDK libraries. It does not touch
>>>> hotspot libraries nor JDK executables; they will have to wait for a future
>>>> fix -- this was complex enough. This change will not have any impact on
>>>> macosx, since we do not use mapfiles there, but instead export all symbols.
>>>> (This is not a good idea, but I'll address that separately.) This change
>>>> will also have a minimal impact on Windows. The only reason Windows is
>>>> impacted at all, is that some changes needed by Solaris and Linux were
>>>> simpler to fix for all platforms.
>>>>
>>>> I have strived for this change to have no impact on the actual generated
>>>> code. Unfortunately, this was not possible to fully achieve. I do not
>>>> believe that these changes will have any actual impact on the product,
>>>> though. I will present the differences more in detail further down. Those
>>>> who are not interested can probably skip that.
>>>>
>>>> The patch has passed tier1 testing and is currently running tier2 and
>>>> tier3. Since the running code is more or less (see caveat below) unmodified,
>>>> I don't expect any testing issues.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178
>>>> WebRev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01
>>>>
>>>> Details on changes:
>>>> Most of the source code changes are (unsurprisingly) in java.base and
>>>> java.desktop. Remaining changes are in jdk.crypto.ucrypto,
>>>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent.
>>>>
>>>> Source code changes does almost to 100% consists in decorating an
>>>> exported function with JNIEXPORT. I have also followed the long-standing
>>>> convention of adding JNICALL. This is a no-op on non-Windows platforms, so
>>>> for most of the changes this is purely cosmetic (and possibly adding in
>>>> robustness, should the function ever be used on Windows in the future). I
>>>> have also followed the stylistic convention of putting "JNIEXPORT <return
>>>> type> JNICALL" on a separate line. For some functions, however, this might
>>>> cause a change in calling convention on Windows. Since this can not apply to
>>>> exported functions on Windows (otherwise they would already have had
>>>> JNIEXPORT), I do not think this matters anything.
>>>>
>>>> A few libraries did not have a mapfile, on Linux and/or Solaris. This
>>>> actually meant that all symbols were exported. It is highly unclear if this
>>>> was known and intended by the original make rule writer. I have emulated
>>>> this by adding the flag $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully,
>>>> we can remove this flag and fix proper exported symbols in the future.
>>>>
>>>> I have run the complete build using COMPARE_BUILD, and made a thourough
>>>> analysis of the differences for Linux and Solaris. All native libraries have
>>>> symbol differences, but most of them are trivial and/or harmless. As a
>>>> result, most libraries have disasm differences as well, but these too seem
>>>> trivial and harmless. The differences in symbols that are common to all
>>>> libraries include:
>>>>   * Internal symbols such as __bss_start, _edata, _end and _fini are now
>>>> global. (They are imported as such from the compiler libraries/archives, and
>>>> we have no linker script to override this behavior).
>>>>   * The versioning tag SUNWprivate_1.1 is not included, and thus neither
>>>> the .gnu.version_d symbol.
>>>>   * There are a few differences in the symbol and/or mangling of some
>>>> local functions. I'm not sure what's causing this,
>>>> but it's unlikely to have any effect on the product.
>>>>
>>>> Another common source for change in symbols is due to previous platform
>>>> differences. For instance, if we had "JNIEXPORT int JNICALL do_foo() { ...
>>>> }", but do_foo was not in the mapfile, the symbol was exported on Windows
>>>> but not on Linux and Solaris. (Presumable since it was not needed there,
>>>> even though it was compiled for those platforms as well.) Now, with the
>>>> mapfiles gone, do_foo() will be exported on all platforms. And contrary,
>>>> functions that are compiled on all platforms, and were exported in mapfiles,
>>>> but now have gotten an JNIEXPORT decoration, will now be visible even on
>>>> Windows. (This accounts for half of the noticed symbol differences on
>>>> Windows.) I could have made the JNIEXPORT conditional on OS, but I didn't
>>>> think the mess in source code were worth the keeping of binary confidence
>>>> with the old build.
>>>>
>>>> A third common source for change in symbols is due to exported functions
>>>> "leaking" across library borders. For instance, some functions in
>>>> java.desktop is compiled in both libawt_xawt and libawt_headless, but they
>>>> were previously only included in the mapfile for one of these libraries.
>>>> Now, since the visibility is determined by the source code itself, it gets
>>>> exported in both libraries. A variant of this is when a library depends on
>>>> another JDK library, and includes the header file from that other library,
>>>> which in turn declares a function as JNIEXPORT. This will cause the
>>>> including library to also export the function. This accounts for the other
>>>> half of the changes on Windows. A typical example of this is that multiple
>>>> libraries now re-export hotspot symbols from libjvm.so, like jio_fprintf. (I
>>>> have not listed the libjvm re-exports below.)
>>>>
>>>> Note that  Java_java_io_FileOutputStream_close0 in
>>>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer exported,
>>>> and can probably be removed.
>>>>
>>>> Here is a detailed table showing and accounting for all the remaining
>>>> differences found on Linux and Solaris:
>>>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 is
>>>> now also exported on unix platforms due to JNIEXPORT.
>>>>
>>>> java.base/jspawnlauncher: On solaris, we also include
>>>> libjava/childproc.o, which
>>>> now exports less functions than it used to (it used to export all
>>>> functions, now it is compiled with visibility=hidden).
>>>>
>>>> java.base/java(w).exe: Is now also exporting the following symbols due to
>>>> added JNIEXPORT in libjli on Windows:
>>>> (Yes, executables can export symbols on Windows. Confusing, I know.)
>>>>   JLI_AddArgsFromEnvVar
>>>>   JLI_CmdToArgs
>>>>   JLI_GetAppArgIndex
>>>>   JLI_GetStdArgc
>>>>   JLI_GetStdArgs
>>>>   JLI_InitArgProcessing
>>>>   JLI_Launch
>>>>   JLI_List_add
>>>>   JLI_List_new
>>>>   JLI_ManifestIterate
>>>>   JLI_MemAlloc
>>>>   JLI_MemFree
>>>>   JLI_PreprocessArg
>>>>   JLI_ReportErrorMessage
>>>>   JLI_ReportErrorMessageSys
>>>>   JLI_ReportExceptionDescription
>>>>   JLI_ReportMessage
>>>>   JLI_SetTraceLauncher
>>>>   JLI_StringDup
>>>>
>>>> java.desktop:/libawt_xawt: The following symbols are now also exported on
>>>> linux and solaris due to JNIEXPORT:
>>>>   awt_DrawingSurface_FreeDrawingSurfaceInfo
>>>>   awt_DrawingSurface_GetDrawingSurfaceInfo
>>>>   awt_DrawingSurface_Lock
>>>>   awt_DrawingSurface_Unlock
>>>>   awt_GetColor
>>>>
>>>> The following symbols are now also exported on linux and solaris due to
>>>> JNIEXPORT (they were previously
>>>>   exported only in libawt):
>>>>   Java_sun_awt_DebugSettings_setCTracingOn__Z
>>>>   Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2
>>>>   Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I
>>>>   Java_sun_awt_X11GraphicsConfig_getNumColors
>>>>
>>>> java.desktop:/libawt_headless: The following symbols are now also
>>>> exported due to JNIEXPORT (they were previously
>>>>   exported only in libawt_xawt and/or libawt):
>>>>   Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo
>>>>   Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities
>>>>   Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask
>>>>   Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable
>>>>   X11SurfaceData_GetOps
>>>>
>>>> java.desktop/libawt: The following symbols are now also exported on
>>>> Windows, due to added
>>>> JNIEXPORT:
>>>>   SurfaceData_InitOps
>>>>   mul8table
>>>>   div8table
>>>>   doDrawPath
>>>>   doFillPath
>>>>   g_CMpDataID
>>>>   initInverseGrayLut
>>>>   make_dither_arrays
>>>>   make_uns_ordered_dither_array
>>>>   path2DFloatCoordsID
>>>>   path2DNumTypesID
>>>>   path2DTypesID
>>>>   path2DWindingRuleID
>>>>   sg2dStrokeHintID
>>>>   std_img_oda_blue
>>>>   std_img_oda_green
>>>>   std_img_oda_red
>>>>   std_odas_computed
>>>>   sunHints_INTVAL_STROKE_PURE
>>>>
>>>> java.desktop/libawt on solaris:
>>>> A number of "#pragma weak" directives was previously overridden by the
>>>> mapfile.
>>>> Now these directives are respected, so these symbols are now weak instead
>>>> of local:
>>>>   ByteGrayToIntArgbPreConvert_F
>>>>   ByteGrayToIntArgbPreScaleConvert_F
>>>>   IntArgbBmToFourByteAbgrPreScaleXparOver_F
>>>>   IntArgbToIntRgbXorBlit_F
>>>>   IntBgrToIntBgrAlphaMaskBlit_F
>>>>
>>>> java.desktop/libawt on solaris: These are now also exported due to
>>>> JNIEXPORT in libmlib_image.
>>>>   j2d_mlib_ImageCreate
>>>>   j2d_mlib_ImageCreateStruct
>>>>   j2d_mlib_ImageDelete
>>>>
>>>> java.desktop/libawt on solaris: This is now also exported due to
>>>> JNIEXPORT:
>>>>   GrPrim_CompGetXorColor
>>>>   SurfaceData_GetOpsNoSetup
>>>>   SurfaceData_IntersectBoundsXYWH
>>>>   SurfaceData_SetOps
>>>>   Transform_GetInfo
>>>>   Transform_transform
>>>>
>>>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux and
>>>> solaris due to JNIEXPORT.
>>>> libspashscreen also had JNIEXPORT (actually a pure _declspec(dllexport))
>>>> but no JNICALL, which I added as
>>>> a part of converting to JNIEXPORT. The same goes for libmlib_image .
>>>>
>>>> jdk.sctp/libsctp: handleSocketError is now exported on linux and solaris
>>>> due to JNIEXPORT in libnio.
>>>>
>>>> java.instrument:/libinstrument: Agent_OnUnload is now also exported on
>>>> linux and solaris platforms due to JNIEXPORT.
>>>> JLI_ManifestIterate is now also exported on Windows, due to added
>>>> JNIEXPORT in libjli.
>>>>
>>>> jdk.management/libmanagement_ext:
>>>> Java_com_sun_management_internal_Flag_setDoubleValue is now also exported on
>>>> linux and solaris platforms due to JNIEXPORT.
>>>>
>>>> /Magnus
>>>>
>>>>


From magnus.ihse.bursie at oracle.com  Fri Mar 23 22:03:59 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 23 Mar 2018 23:03:59 +0100
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com>
 <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com>
Message-ID: <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com>


On 2018-03-23 17:05, mandy chung wrote:
> This is a very good change and no more mapfile to maintain!!
Thank you!

>
> Please do file JBS issues for the component teams to clean up their 
> exports.
I have now filed:

https://bugs.openjdk.java.net/browse/JDK-8200191 -- for java.base
https://bugs.openjdk.java.net/browse/JDK-8200192 -- for java.desktop
https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth

/Magnus

>
> Mandy
>
> On 3/23/18 7:30 AM, Erik Joelsson wrote:
>> I have looked at the build changes and they look good.
>>
>> Will you file followups for each component team to look over their 
>> exported symbols, at least for the libraries with 
>> $(EXPORT_ALL_SYMBOLS)? It sure looks like there is some technical 
>> debt laying around here.
>>
>> /Erik
>>
>>
>> On 2018-03-23 06:56, Magnus Ihse Bursie wrote:
>>> With modern compilers, we can use compiler directives (such as 
>>> _attribute__((visibility("default"))), or __declspec(dllexport)) to 
>>> control symbol visibility, directly in the source code. This has 
>>> historically not been present on all compilers, so we had to resort 
>>> to using mapfiles (also known as linker scripts).
>>>
>>> This is no longer the case. Now all compilers we use support symbol 
>>> visibility directives, in one form or another. We should start using 
>>> this. Since this has been the only way to control symbol visibility 
>>> on Windows, for most of the shared code, we already have proper 
>>> JNIEXPORT decorations in place.
>>>
>>> If we fix the remaining platform-specific files to have proper 
>>> JNIEXPORT tagging, then we can finally get rid of mapfiles.
>>>
>>> This fix removed mapfiles for all JDK libraries. It does not touch 
>>> hotspot libraries nor JDK executables; they will have to wait for a 
>>> future fix -- this was complex enough. This change will not have any 
>>> impact on macosx, since we do not use mapfiles there, but instead 
>>> export all symbols. (This is not a good idea, but I'll address that 
>>> separately.) This change will also have a minimal impact on Windows. 
>>> The only reason Windows is impacted at all, is that some changes 
>>> needed by Solaris and Linux were simpler to fix for all platforms.
>>>
>>> I have strived for this change to have no impact on the actual 
>>> generated code. Unfortunately, this was not possible to fully 
>>> achieve. I do not believe that these changes will have any actual 
>>> impact on the product, though. I will present the differences more 
>>> in detail further down. Those who are not interested can probably 
>>> skip that.
>>>
>>> The patch has passed tier1 testing and is currently running tier2 
>>> and tier3. Since the running code is more or less (see caveat below) 
>>> unmodified, I don't expect any testing issues.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200178
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01
>>>
>>> Details on changes:
>>> Most of the source code changes are (unsurprisingly) in java.base 
>>> and java.desktop. Remaining changes are in jdk.crypto.ucrypto, 
>>> jdk.hotspot.agent, jdk.jdi and jdk.jdwp.agent.
>>>
>>> Source code changes does almost to 100% consists in decorating an 
>>> exported function with JNIEXPORT. I have also followed the 
>>> long-standing convention of adding JNICALL. This is a no-op on 
>>> non-Windows platforms, so for most of the changes this is purely 
>>> cosmetic (and possibly adding in robustness, should the function 
>>> ever be used on Windows in the future). I have also followed the 
>>> stylistic convention of putting "JNIEXPORT <return type> JNICALL" on 
>>> a separate line. For some functions, however, this might cause a 
>>> change in calling convention on Windows. Since this can not apply to 
>>> exported functions on Windows (otherwise they would already have had 
>>> JNIEXPORT), I do not think this matters anything.
>>>
>>> A few libraries did not have a mapfile, on Linux and/or Solaris. 
>>> This actually meant that all symbols were exported. It is highly 
>>> unclear if this was known and intended by the original make rule 
>>> writer. I have emulated this by adding the flag 
>>> $(EXPORT_ALL_SYMBOLS) to these libraries. Hopefully, we can remove 
>>> this flag and fix proper exported symbols in the future.
>>>
>>> I have run the complete build using COMPARE_BUILD, and made a 
>>> thourough analysis of the differences for Linux and Solaris. All 
>>> native libraries have symbol differences, but most of them are 
>>> trivial and/or harmless. As a result, most libraries have disasm 
>>> differences as well, but these too seem trivial and harmless. The 
>>> differences in symbols that are common to all libraries include:
>>> ?* Internal symbols such as __bss_start, _edata, _end and _fini are 
>>> now global. (They are imported as such from the compiler 
>>> libraries/archives, and we have no linker script to override this 
>>> behavior).
>>> ?* The versioning tag SUNWprivate_1.1 is not included, and thus 
>>> neither the .gnu.version_d symbol.
>>> ?* There are a few differences in the symbol and/or mangling of some 
>>> local functions. I'm not sure what's causing this,
>>> but it's unlikely to have any effect on the product.
>>>
>>> Another common source for change in symbols is due to previous 
>>> platform differences. For instance, if we had "JNIEXPORT int JNICALL 
>>> do_foo() { ... }", but do_foo was not in the mapfile, the symbol was 
>>> exported on Windows but not on Linux and Solaris. (Presumable since 
>>> it was not needed there, even though it was compiled for those 
>>> platforms as well.) Now, with the mapfiles gone, do_foo() will be 
>>> exported on all platforms. And contrary, functions that are compiled 
>>> on all platforms, and were exported in mapfiles, but now have gotten 
>>> an JNIEXPORT decoration, will now be visible even on Windows. (This 
>>> accounts for half of the noticed symbol differences on Windows.) I 
>>> could have made the JNIEXPORT conditional on OS, but I didn't think 
>>> the mess in source code were worth the keeping of binary confidence 
>>> with the old build.
>>>
>>> A third common source for change in symbols is due to exported 
>>> functions "leaking" across library borders. For instance, some 
>>> functions in java.desktop is compiled in both libawt_xawt and 
>>> libawt_headless, but they were previously only included in the 
>>> mapfile for one of these libraries. Now, since the visibility is 
>>> determined by the source code itself, it gets exported in both 
>>> libraries. A variant of this is when a library depends on another 
>>> JDK library, and includes the header file from that other library, 
>>> which in turn declares a function as JNIEXPORT. This will cause the 
>>> including library to also export the function. This accounts for the 
>>> other half of the changes on Windows. A typical example of this is 
>>> that multiple libraries now re-export hotspot symbols from 
>>> libjvm.so, like jio_fprintf. (I have not listed the libjvm 
>>> re-exports below.)
>>>
>>> Note that? Java_java_io_FileOutputStream_close0 in 
>>> java.base/unix/native/libjava/FileOutputStream_md.c is no longer 
>>> exported,
>>> and can probably be removed.
>>>
>>> Here is a detailed table showing and accounting for all the 
>>> remaining differences found on Linux and Solaris:
>>> java.base/unix/native/libjava: Java_java_io_FileOutputStream_close0 
>>> is now also exported on unix platforms due to JNIEXPORT.
>>>
>>> java.base/jspawnlauncher: On solaris, we also include 
>>> libjava/childproc.o, which
>>> now exports less functions than it used to (it used to export all 
>>> functions, now it is compiled with visibility=hidden).
>>>
>>> java.base/java(w).exe: Is now also exporting the following symbols 
>>> due to added JNIEXPORT in libjli on Windows:
>>> (Yes, executables can export symbols on Windows. Confusing, I know.)
>>> ?JLI_AddArgsFromEnvVar
>>> ?JLI_CmdToArgs
>>> ?JLI_GetAppArgIndex
>>> ?JLI_GetStdArgc
>>> ?JLI_GetStdArgs
>>> ?JLI_InitArgProcessing
>>> ?JLI_Launch
>>> ?JLI_List_add
>>> ?JLI_List_new
>>> ?JLI_ManifestIterate
>>> ?JLI_MemAlloc
>>> ?JLI_MemFree
>>> ?JLI_PreprocessArg
>>> ?JLI_ReportErrorMessage
>>> ?JLI_ReportErrorMessageSys
>>> ?JLI_ReportExceptionDescription
>>> ?JLI_ReportMessage
>>> ?JLI_SetTraceLauncher
>>> ?JLI_StringDup
>>>
>>> java.desktop:/libawt_xawt: The following symbols are now also 
>>> exported on linux and solaris due to JNIEXPORT:
>>> ?awt_DrawingSurface_FreeDrawingSurfaceInfo
>>> ?awt_DrawingSurface_GetDrawingSurfaceInfo
>>> ?awt_DrawingSurface_Lock
>>> ?awt_DrawingSurface_Unlock
>>> ?awt_GetColor
>>>
>>> The following symbols are now also exported on linux and solaris due 
>>> to JNIEXPORT (they were previously
>>> ?exported only in libawt):
>>> ?Java_sun_awt_DebugSettings_setCTracingOn__Z
>>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2
>>> ?Java_sun_awt_DebugSettings_setCTracingOn__ZLjava_lang_String_2I
>>> ?Java_sun_awt_X11GraphicsConfig_getNumColors
>>>
>>> java.desktop:/libawt_headless: The following symbols are now also 
>>> exported due to JNIEXPORT (they were previously
>>> ?exported only in libawt_xawt and/or libawt):
>>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getGLXConfigInfo
>>> ?Java_sun_java2d_opengl_GLXGraphicsConfig_getOGLCapabilities
>>> ?Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask
>>> ?Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable
>>> ?X11SurfaceData_GetOps
>>>
>>> java.desktop/libawt: The following symbols are now also exported on 
>>> Windows, due to added
>>> JNIEXPORT:
>>> ?SurfaceData_InitOps
>>> ?mul8table
>>> ?div8table
>>> ?doDrawPath
>>> ?doFillPath
>>> ?g_CMpDataID
>>> ?initInverseGrayLut
>>> ?make_dither_arrays
>>> ?make_uns_ordered_dither_array
>>> ?path2DFloatCoordsID
>>> ?path2DNumTypesID
>>> ?path2DTypesID
>>> ?path2DWindingRuleID
>>> ?sg2dStrokeHintID
>>> ?std_img_oda_blue
>>> ?std_img_oda_green
>>> ?std_img_oda_red
>>> ?std_odas_computed
>>> ?sunHints_INTVAL_STROKE_PURE
>>>
>>> java.desktop/libawt on solaris:
>>> A number of "#pragma weak" directives was previously overridden by 
>>> the mapfile.
>>> Now these directives are respected, so these symbols are now weak 
>>> instead of local:
>>> ?ByteGrayToIntArgbPreConvert_F
>>> ?ByteGrayToIntArgbPreScaleConvert_F
>>> ?IntArgbBmToFourByteAbgrPreScaleXparOver_F
>>> ?IntArgbToIntRgbXorBlit_F
>>> ?IntBgrToIntBgrAlphaMaskBlit_F
>>>
>>> java.desktop/libawt on solaris: These are now also exported due to 
>>> JNIEXPORT in libmlib_image.
>>> ?j2d_mlib_ImageCreate
>>> ?j2d_mlib_ImageCreateStruct
>>> ?j2d_mlib_ImageDelete
>>>
>>> java.desktop/libawt on solaris: This is now also exported due to 
>>> JNIEXPORT:
>>> ?GrPrim_CompGetXorColor
>>> ?SurfaceData_GetOpsNoSetup
>>> ?SurfaceData_IntersectBoundsXYWH
>>> ?SurfaceData_SetOps
>>> ?Transform_GetInfo
>>> ?Transform_transform
>>>
>>> java.desktop/libsplashscreen: JNI_OnLoad is now exported on linux 
>>> and solaris due to JNIEXPORT.
>>> libspashscreen also had JNIEXPORT (actually a pure 
>>> _declspec(dllexport)) but no JNICALL, which I added as
>>> a part of converting to JNIEXPORT. The same goes for libmlib_image .
>>>
>>> jdk.sctp/libsctp: handleSocketError is now exported on linux and 
>>> solaris due to JNIEXPORT in libnio.
>>>
>>> java.instrument:/libinstrument: Agent_OnUnload is now also exported 
>>> on linux and solaris platforms due to JNIEXPORT.
>>> JLI_ManifestIterate is now also exported on Windows, due to added 
>>> JNIEXPORT in libjli.
>>>
>>> jdk.management/libmanagement_ext: 
>>> Java_com_sun_management_internal_Flag_setDoubleValue is now also 
>>> exported on linux and solaris platforms due to JNIEXPORT.
>>>
>>> /Magnus
>>>
>>>
>>
>


From Sergey.Bylokhov at oracle.com  Sat Mar 24 00:20:20 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Mar 2018 17:20:20 -0700
Subject: <AWT Dev> [11] Review Request: 8200149 The
 "com.sun.awt.AWTUtilities" class can be dropped
Message-ID: <c93d8966-db92-3eee-fa0f-51e9d9b4e14c@oracle.com>

Hello.
Please review fix for jdk11.

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

The client code has a "com.sun.awt.AWTUtilities" class which at some 
point in the past, JDK 6u10, was used as a kind of "public" API. 
Currently all its functionality is already provided by the public API, 
so this class can be removed.

In jdk10 this class was marked as "forRemoval = true" (see JDK-8187253) 
and can be removed in 11.


-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Mon Mar 26 05:53:38 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Sun, 25 Mar 2018 22:53:38 -0700 (PDT)
Subject: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able
 to use extended key code characters as ? ? ?.
In-Reply-To: <c19f0059-3abd-810f-7d61-e64976585a1d@oracle.com>
References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default>
 <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default>
 <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com>
 <992a8202-6ac9-4c16-9fe5-c316e314bed5@default>
 <cd2f4c15-5ec0-a90b-c9d7-93152b6ead5e@oracle.com>
 <814c85c6-0d8d-468c-a2af-fefa79e59ef7@default>
 <c2325614-283e-48e0-acef-09df6c9f42b8@default>
 <66fcf064-b200-4d6d-ac06-b78517074f00@default>
 <9fd92bf5-113c-782c-92e9-7b061ace2a6c@oracle.com>
 <27586cbb-be2c-4941-ade4-8493b501542b@default>
 <410e40d6-e7d7-4b2d-8647-2dbeb8b82c18@default>
 <4f0dbe63-e640-8183-b136-08da1af3c5cf@oracle.com>
 <948a2586-88e3-47cf-bf0f-84995eac96da@default>
 <80c936e4-fd72-437b-970a-4a71117e24f9@default>
 <c19f0059-3abd-810f-7d61-e64976585a1d@oracle.com>
Message-ID: <636d9ff1-b9ef-4a9e-9a65-b0892e9bfa6b@default>

Hi, Please review the updated Webrev containing the requested changes:

http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.05/

I believe this change implements a new feature of Unicode key input and the corresponding key event generation without affecting the existing ascii key input and key event generations. Hence the regression should be less with this change.

Some notes with respect to implementation:
   1. On linux platform, native api's present only for the extended ascii support and hence no idea of Unicode input in this platform.
   2. On mac platform, I have used the below native api's to implement the Unicode input to a component and key event trigger from the component to the respective key listener.
	https://developer.apple.com/documentation/coregraphics/1456120-cgeventkeyboardgetunicodestring
	https://developer.apple.com/documentation/coregraphics/1456028-cgeventkeyboardsetunicodestring?language=objc
	(Set and get Unicode key is supported via the core graphics event(CGEvent) which is part of the NSEvent structure which is the base structure for event implementation on mac)
   3. On windows platform, I have used the below native api's to perform this job:
	https://msdn.microsoft.com/en-us/library/windows/desktop/ms646310(v=vs.85).aspx
	(SendInput api supports the Unicode input via the flag KEYEVENTF_UNICODE)
	https://msdn.microsoft.com/en-us/library/windows/desktop/ms646271(v=vs.85).aspx
	(Upon VK_PACKET, Get and decode the message via GetMessage() and TranslateMessage(). This produces a WM_CHAR message containing the respective Unicode key)

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Monday, November 27, 2017 11:43 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky <semyon.sadetsky at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

Hi, Shashi.
>> Also we should check what events are come to the application when 
>> this new API will be used. For example if 'm' will be pressed what 
>> notifications will be posted to the 
>> application?(keyTyped/keyPressed/keyReleased)

The test is still manual, I suggest to change it to automated and validate the behavior of "keyTyped/keyPressed/keyReleased". I suggest to implement it first and check that it works as expected on macOS and windows. After that we can take a look to the linux platform(For example I think KeyEvent.getExtendedKeyCodeForChar() should work on linux, and we can check can it be used in the proposed fix or not)

On 20/11/2017 21:03, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, Please find the code updates that you asked for. As discussed I have raised an exception for the linux platform as there is no equivalent functions being implemented yet.
> 
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.04/
> 
> shashi
> 
> -----Original Message-----
> From: Shashidhara Veerabhadraiah
> Sent: Thursday, November 16, 2017 12:36 PM
> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; Semyon Sadetsky 
> <semyon.sadetsky at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.
> 
> Hi Sergey, Below are my replies:
> 
> shashi
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, November 14, 2017 3:32 AM
> To: Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky 
> <semyon.sadetsky at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.
> 
> Hi, Shashi.
>    115     @Override
>    116     public void keyReleaseUnicode( int key ) {
>    117         // No special functions that implements a unicode key press
>    118         // and release in linux platform. Hence falls back to the
>    119         // default ASCII key press/release functions.
>    120         keyReleaseImpl(key);
>    121     }
> 
> We should do something in this part of the fix, because we cannot use unicode point as a keyCode. It will produce incorrect result.
> [Shashi] As discussed in the meeting, will add a unsupported exception in the following Webrev.
> 
> Also we should check what events are come to the application when this 
> new API will be used. For example if 'm' will be pressed what 
> notifications will be posted to the
> application?(keyTyped/keyPressed/keyReleased)
> [Shashi] It sends out the keyPressed/keyReleased events(WM_KEYUP/WM_KEYDOWN) events. The current code takes into account of the Unicode chars and uses the Unicode functions like ::ToUnicodeEx() to scan the characters.
> 
> On 05/11/2017 21:04, Shashidhara Veerabhadraiah wrote:
>> Hi Sergey, Please find the updated Webrev addressing your comments/requirements.
>>
>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.03/
>>
>> Thanks and regards,
>> Shashi
>>
>> -----Original Message-----
>> From: Shashidhara Veerabhadraiah
>> Sent: Friday, October 27, 2017 6:44 PM
>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com>; awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.
>>
>> Hi Sergey, below are my replies:
>>
>> Thanks and regards,
>> shashi
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Friday, October 27, 2017 11:47 AM
>> To: Shashidhara Veerabhadraiah
>> <shashidhara.veerabhadraiah at oracle.com>; Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com>; awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.
>>
>> Hi, Shashi.
>>     - Do we need to check passed unicode code-point in Robot.java using checkKeycodeArgument(key);?
>> [Shashi] I think yes. If the key value is zero I believe we don't need to process further.
>>     - Can you please clarify how it will work on linux where we will use code-point as a keycode?
>> [Shashi] There is no update being done to the linux source code as I could not find native call which can interpret the Unicode. Hence it will behave same as the original keypress() and keyrelease().
>>     - It would be good if the names of the parameters will be unified/corrected, for example:
>> private native void keyEventUnicode(int javaKeyCode, boolean keydown); "javaKeyCode" - Is it a java key code or a Unicode code-point?
>> [Shashi] Sure will update in the coming pass.
>>
>> Why the test is manual? Isn't an application should  recognize this new functionality automatically? Additionally it would be good to test all key related listeners(keyTyped/keyPressed/keyReleased).
>> [Shashi] We need to be sure that the Unicode key indeed displayed as the standard Unicode. There is no other way to confirm that it is indeed been the same standard Unicode that's been displayed.
>>
>> Debug code in awt_Robot.cpp
>> if(isUnicode) {printf("In unicode func:%d", jkey); [Shashi] Sure will update in the coming pass.
>>
>>
>> Also I would like to propose an idea for discussion: probably it would be better to create only one Robot#type(codePoint) method? What do you think?
>> [Shashi] It can be done but the only problem is that it is kinda different from the keypress() and keyRelease() functions. If that's fine then it can be done. Please confirm based on that I will produce a new Webrev based on that.
>>
>> On 26/10/2017 21:39, Shashidhara Veerabhadraiah wrote:
>>> Hi Sergey\Semyon, Please do the review for the below bug.
>>>
>>> Thanks and regards,
>>>
>>> Shashi
>>>
>>> *From:* Shashidhara Veerabhadraiah
>>> *Sent:* Thursday, September 21, 2017 2:14 PM
>>> *To:* Sergey Bylokhov <sergey.bylokhov at oracle.com>; Semyon Sadetsky 
>>> <semyon.sadetsky at oracle.com>; awt-dev at openjdk.java.net
>>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress 
>>> should be able to use extended key code characters as ? ? ?.
>>>
>>> Hi All, Please find the updated webrev containing a new test that is 
>>> added to test out the software changes that were made under this 
>>> enhancement.
>>>
>>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.02/
>>>
>>> Thanks and regards,
>>>
>>> Shashi
>>>
>>> *From:* Shashidhara Veerabhadraiah
>>> *Sent:* Thursday, September 21, 2017 11:37 AM
>>> *To:* Sergey Bylokhov <sergey.bylokhov at oracle.com 
>>> <mailto:sergey.bylokhov at oracle.com>>; Semyon Sadetsky 
>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>>;
>>> awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress 
>>> should be able to use extended key code characters as ? ? ?.
>>>
>>> Hi Sergey, I was able to input the surrogate pairs and got the 
>>> required output as shown below:
>>>
>>> Below is the output after we input the surrogate pairs:
>>>
>>> Thanks and regards,
>>>
>>> Shashi
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Thursday, September 14, 2017 11:33 PM
>>> To: Shashidhara Veerabhadraiah 
>>> <shashidhara.veerabhadraiah at oracle.com
>>> <mailto:shashidhara.veerabhadraiah at oracle.com>>; Semyon Sadetsky 
>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>>;
>>> awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>>> Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress should 
>>> be able to use extended key code characters as ? ? ?.
>>>
>>> The java uses UTF16, I guess this new api should use it also, and we 
>>> should check that the surrogate pairs will be supported.
>>>
>>> On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote:
>>>
>>>    > Hi Sergey, Yes it represents the Unicode code point. The 
>>> encoding is same as the window characteristic which is UTF 8 as implemented in Java.
>>>
>>>    >
>>>
>>>    > Thanks and regards,
>>>
>>>    > Shashi
>>>
>>>    >
>>>
>>>    > -----Original Message-----
>>>
>>>    > From: Sergey Bylokhov
>>>
>>>    > Sent: Wednesday, September 13, 2017 5:22 AM
>>>
>>>    > To: Shashidhara Veerabhadraiah
>>>
>>>    > <shashidhara.veerabhadraiah at oracle.com
>>> <mailto:shashidhara.veerabhadraiah at oracle.com>>; Semyon Sadetsky
>>>
>>>    > <semyon.sadetsky at oracle.com 
>>> <mailto:semyon.sadetsky at oracle.com>>;
>>> awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>>>
>>>    > Subject: Re: <AWT Dev> [10] JDK-8148344: Java robot keypress 
>>> should be able to use extended key code characters as ? ? ?.
>>>
>>>    >
>>>
>>>    > Hi, Shashi.
>>>
>>>    > One initial question:
>>>
>>>    > What is an int parameter of these methods means, is it a 
>>> "Unicode code point"? What encoding utf8/utf16 should be used?
>>>
>>>    >
>>>
>>>    > On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote:
>>>
>>>    >> Hi, I have updated the Webrev to accommodate the comments and 
>>> here is
>>>
>>>    >> the new Webrev:
>>>
>>>    >>
>>>
>>>    >> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/
>>>
>>>    >>
>>>
>>>    >> I have separated the /_Unicode_/ keys input via java robot as 
>>> a new
>>>
>>>    >> set of /_public_/ api?s (this is in similar fashion as how the
>>>
>>>    >> platform offers the Unicode keys input into the system) and 
>>> this has
>>>
>>>    >> been tested on all the platforms using the test file similar 
>>> to the
>>>
>>>    >> attached file in the bug. A more proper test file would be put 
>>> for
>>>
>>>    >> review in the subsequent reviews.
>>>
>>>    >>
>>>
>>>    >> Thanks and regards,
>>>
>>>    >>
>>>
>>>    >> Shashi
>>>
>>>    >>
>>>
>>>    >> *From:* Sergey Bylokhov
>>>
>>>    >> *Sent:* Wednesday, August 30, 2017 2:33 AM
>>>
>>>    >> *To:* Shashidhara Veerabhadraiah
>>>
>>>    >> <shashidhara.veerabhadraiah at oracle.com
>>> <mailto:shashidhara.veerabhadraiah at oracle.com>>
>>>
>>>    >> *Cc:* awt-dev at openjdk.java.net 
>>> <mailto:awt-dev at openjdk.java.net>
>>>
>>>    >> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot keypress 
>>> should
>>>
>>>    >> be able to use extended key code characters as ? ? ?.
>>>
>>>    >>
>>>
>>>    >> Hi, Shashi.
>>>
>>>    >>
>>>
>>>    >> This is part of this fix, to figure out how it will work for 
>>> external
>>>
>>>    >> applications. As you said this functionally can be useful for 
>>> an
>>>
>>>    >> onscreen keyboards, which virtually can have any possible 
>>> keys, but
>>>
>>>    >> we should check how the applications will react on such keys:
>>>
>>>    >>?? ?- Will the application get some kind of keyPress/Release?
>>>
>>>    >>?? ?- Will the application get some keyCode for such event?
>>>
>>>    >>?? ?- Is it possible to get autorepeat for such keys?(between
>>>
>>>    >> press/release)
>>>
>>>    >>
>>>
>>>    >> Depending from the answers above we can enhance existed robot 
>>> API or
>>>
>>>    >> provide a new one:
>>>
>>>    >> like Robot.keyType(char)/etc
>>>
>>>    >>
>>>
>>>    >> ----- shashidhara.veerabhadraiah at oracle.com
>>> <mailto:shashidhara.veerabhadraiah at oracle.com>
>>>
>>>    >> <mailto:shashidhara.veerabhadraiah at oracle.com> wrote:
>>>
>>>    >>>
>>>
>>>    >>
>>>
>>>    >>>
>>>
>>>    >>
>>>
>>>    >>>
>>>
>>>    >>
>>>
>>>    >> Hi Sergey, I was only able to add short cut keys in the 
>>> Microsoft
>>>
>>>    >> word but not as a system wide short cut key. There was no 
>>> mechanism
>>>
>>>    >> that I could find to add a short cut key for a Unicode char!!
>>> Can you
>>>
>>>    >> please tell me the steps to do the same if you are aware of?
>>>
>>>    >>
>>>
>>>    >> Thanks and regards,
>>>
>>>    >>
>>>
>>>    >> shashi
>>>
>>>    >>
>>>
>>>    >>>
>>>
>>>    >>
>>>
>>>    >> *From:*Sergey Bylokhov
>>>
>>>    >>> *Sent:* Tuesday, August 22, 2017 8:34 PM
>>>
>>>    >>> *To:* Shashidhara Veerabhadraiah
>>>
>>>    >>> <shashidhara.veerabhadraiah at oracle.com
>>>
>>>    >> <mailto:shashidhara.veerabhadraiah at oracle.com>>
>>>
>>>    >>> *Cc:* awt-dev at openjdk.java.net 
>>> <mailto:awt-dev at openjdk.java.net> <mailto:awt-dev at openjdk.java.net>
>>>
>>>    >>> *Subject:* Re: <AWT Dev> [10] JDK-8148344: Java robot 
>>> keypress
>>>
>>>    >>> should be
>>>
>>>    >> able to use extended key code characters as ? ? ?.
>>>
>>>    >>
>>>
>>>    >> Hi, Shashi.
>>>
>>>    >>> Can you check how this Robot API will work when the 
>>> application will have a shortcut for such key? Will such shortcuts 
>>> will work after this fix?
>>>
>>>    >>>
>>>
>>>    >>> ----- shashidhara.veerabhadraiah at oracle.com
>>> <mailto:shashidhara.veerabhadraiah at oracle.com>
>>>
>>>    >> <mailto:shashidhara.veerabhadraiah at oracle.com> wrote:
>>>
>>>    >>>>
>>>
>>>    >>
>>>
>>>    >>>
>>>
>>>    >>
>>>
>>>    >>>
>>>
>>>    >>
>>>
>>>    >> Hi All, Please review fix for the /_enhancement_/ wherein the 
>>> robot
>>>
>>>    >> key press of non-ascii were interpreted as question marks.
>>>
>>>    >>
>>>
>>>    >> Issue: The robot key press events was handling only the ascii 
>>> inputs
>>>
>>>    >> and ignored the other Unicode inputs. Either it was throwing 
>>> illegal
>>>
>>>    >> argument exception in windows or does nothing on the mac for 
>>> those
>>>
>>>    >> Unicode inputs.
>>>
>>>    >>
>>>
>>>    >> Solution and fix: The platform specific api?s was unable 
>>> handle the
>>>
>>>    >> non-ascii inputs. I have modified the api?s to accept the 
>>> non-ascii
>>>
>>>    >> inputs and correspondingly send the message to the window to 
>>> print
>>>
>>>    >> the non-ascii characters as well. Below is the picture of how 
>>> the
>>>
>>>    >> non-ascii inputs are considered and printed onto the window.
>>>
>>>    >>
>>>
>>>    >> The solution spans across windows and mac platform and still 
>>> in
>>>
>>>    >> search of a solution for the Linux platform. The solution 
>>> implements
>>>
>>>    >> key scanning only upon existing valid ascii key was /_not_/ 
>>> found and
>>>
>>>    >> assumes it as Unicode key and sends the event to event queue 
>>> to be
>>>
>>>    >> processed as Unicode keys. Different formats are being used by
>>>
>>>    >> different platform implementation of Unicode. For ex., per the 
>>> below
>>>
>>>    >> Unicode list, in the case of windows and mac, the key input 
>>> can take
>>>
>>>    >> decimal values whereas on Linux it can only take the Code values.
>>>
>>>    >>
>>>
>>>    >> On Linux, I was able to get the KeySym of Unicode keys but was 
>>> unable
>>>
>>>    >> to fake the key event as there was no mechanism available for 
>>> the
>>>
>>>    >> same(which sends the key event to window). Please let me know 
>>> if
>>>
>>>    >> there is any such mechanism available to simulate Unicode key 
>>> events
>>>
>>>    >> on Linux platform. Hence I think to raise a bug for the Linux
>>>
>>>    >> platform and close this JDK-8148344 bug.
>>>
>>>    >>
>>>
>>>    >> Enhancement id: 
>>> https://bugs.openjdk.java.net/browse/JDK-8148344
>>>
>>>    >>
>>>
>>>    >> Webrev:
>>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/
>>>
>>>    >>
>>>
>>>    >> Thanks and regards,
>>>
>>>    >>
>>>
>>>    >> Shashi
>>>
>>>    >>
>>>
>>>    >
>>>
>>>    >
>>>
>>>    > --
>>>
>>>    > Best regards, Sergey.
>>>
>>>    >
>>>
>>> --
>>>
>>> Best regards, Sergey.
>>>
>>
>>
>> --
>> Best regards, Sergey.
>>
> 
> 
> --
> Best regards, Sergey.
> 


--
Best regards, Sergey.

From ryan at intelitmedia.com  Sat Mar 24 17:57:28 2018
From: ryan at intelitmedia.com (Ryan Smith)
Date: Sat, 24 Mar 2018 17:57:28 GMT
Subject: <AWT Dev> Xamarin App Development
Message-ID: <20180324160509-1.1.5.bwx.0.5b8mpawy5a@openemm.net>

Hi,

We are an India based Mobile app Development firm with over 7 years of
experience.
We can design and develop Mobile app to help you deliver more value to
customers in your specific industry.

We are focused in three mobile application Platforms:


?	iPhone / iPad application development
?	Android application development
?	Windows Mobile (WM) application development

Our mobile application services include:


?	Business software and solutions for iPhone, iPad, Android, and WM
?	Productivity apps, utilities and solutions
?	Mobile client software
?	Porting web applications to mobile apps in different platforms

If you are interested in our service, please reply with your contact
details or Skype Id for further communication.

I am looking forward to hear from you soon. Thanks in advance for your
consideration.

Warm Regards,
Ryan Smith
Business Development Executive
iMark Digital Agency Pvt. Ltd.
Hand Phone: +1 818 824 6002
Skype Id: "imark.infotech"
Global Offices: San Francisco | Los Angeles | Australia | India
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180324/ec2876b7/attachment.html>

From philip.race at oracle.com  Mon Mar 26 21:32:04 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 26 Mar 2018 14:32:04 -0700
Subject: <AWT Dev> [11] Review Request: 8200149 The
 "com.sun.awt.AWTUtilities" class can be dropped
In-Reply-To: <c93d8966-db92-3eee-fa0f-51e9d9b4e14c@oracle.com>
References: <c93d8966-db92-3eee-fa0f-51e9d9b4e14c@oracle.com>
Message-ID: <5AB966D4.90701@oracle.com>

+1 .. assuming there are no explicit tests we still have that use these 
classes ..

-phil.


On 3/23/18, 5:20 PM, Sergey Bylokhov wrote:
> Hello.
> Please review fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200149
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8200149/webrev.00
> CSR: https://bugs.openjdk.java.net/browse/JDK-8200190
>
> The client code has a "com.sun.awt.AWTUtilities" class which at some 
> point in the past, JDK 6u10, was used as a kind of "public" API. 
> Currently all its functionality is already provided by the public API, 
> so this class can be removed.
>
> In jdk10 this class was marked as "forRemoval = true" (see 
> JDK-8187253) and can be removed in 11.
>
>

From philip.race at oracle.com  Tue Mar 27 00:50:13 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 26 Mar 2018 17:50:13 -0700
Subject: <AWT Dev> [11] Review Request: 8198335
 java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java
 fails in headless mode
In-Reply-To: <125498b3-9658-4912-6e9c-b44b021206e4@oracle.com>
References: <125498b3-9658-4912-6e9c-b44b021206e4@oracle.com>
Message-ID: <5AB99545.3000106@oracle.com>

I presume the headful keyword means thie can't be run in our nightly 
tests ..and
isn't supposed to be run in headless mode, so I am a bit puzzled by the 
change.
I also don't understand why it would be "random".

   * @key headful
   * @summary Tests that no exception is thrown when display mode is changed
   *          externally
   * @compile UninitializedDisplayModeChangeTest.java DisplayModeChanger.java
   * @run main/othervm UninitializedDisplayModeChangeTest
+ * @run main/othervm -Djava.awt.headless=true UninitializedDisplayModeChangeTest
   */

-phil.

On 3/20/18, 11:48 AM, Sergey Bylokhov wrote:
> Hello.
> Please review fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198335
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8198335/webrev.01
>
> This bug cause the random failures of our headless tests. The reason 
> is that we try to notify the 
> GraphicsEnvironment(HeadlessGraphicsEnvironment), which does not 
> implement DisplayChangedListener, about display change.
>
> It is possible to skip this notification for headlesGE only, but I 
> think that it is better to make instanceof before cast to 
> DisplayChangedListener, usually we use this pattern in other places.
>
> PS. Note that WToolkit.paletteChanged and WToolkit.displayChanged use 
> different threads for notifications, I have created a bug to 
> investigate this: https://bugs.openjdk.java.net/browse/JDK-8199881
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180326/e9efb7a3/attachment.html>

From Sergey.Bylokhov at oracle.com  Tue Mar 27 02:02:05 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 26 Mar 2018 19:02:05 -0700
Subject: <AWT Dev> [11] Review Request: 8198335
 java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java
 fails in headless mode
In-Reply-To: <5AB99545.3000106@oracle.com>
References: <125498b3-9658-4912-6e9c-b44b021206e4@oracle.com>
 <5AB99545.3000106@oracle.com>
Message-ID: <7adcfab6-ef88-52e8-fd7e-b15b1128df41@oracle.com>

On 26/03/2018 17:50, Philip Race wrote:
> I presume the headful keyword means thie can't be run in our nightly 
> tests ..and
> isn't supposed to be run in headless mode, so I am a bit puzzled by the 
> change.
> I also don't understand why it would be "random".

An updated test just emulates the problem, it run the first instance 
using "-Djava.awt.headless" and then unconditionally tries to change the 
system display mode, this causes an exception in the headless instance.

> This bug cause the random failures of our headless tests
Here I have referenced any other tests in nightly, which fails if we get 
such notifications from the OS.

> 
>    * @key headful
>    * @summary Tests that no exception is thrown when display mode is changed
>    *          externally
>    * @compile UninitializedDisplayModeChangeTest.java DisplayModeChanger.java
>    * @run main/othervm UninitializedDisplayModeChangeTest
> + * @run main/othervm -Djava.awt.headless=true 
> UninitializedDisplayModeChangeTest
>    */
> 
> -phil.
> 
> On 3/20/18, 11:48 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review fix for jdk11.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198335
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8198335/webrev.01
>>
>> This bug cause the random failures of our headless tests. The reason 
>> is that we try to notify the 
>> GraphicsEnvironment(HeadlessGraphicsEnvironment), which does not 
>> implement DisplayChangedListener, about display change.
>>
>> It is possible to skip this notification for headlesGE only, but I 
>> think that it is better to make instanceof before cast to 
>> DisplayChangedListener, usually we use this pattern in other places.
>>
>> PS. Note that WToolkit.paletteChanged and WToolkit.displayChanged use 
>> different threads for notifications, I have created a bug to 
>> investigate this: https://bugs.openjdk.java.net/browse/JDK-8199881
>>
>>


-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Mar 27 17:34:59 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 27 Mar 2018 10:34:59 -0700
Subject: <AWT Dev> RFR: 8200313 :
	java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails
Message-ID: <b56ece53-c7b2-8f6f-de66-71e8a3ebb91b@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8200313
Webrev: http://cr.openjdk.java.net/~prr/8200313/

This test should have been updated when I switched the default
but it was overlooked.

-phil.

From weijun.wang at oracle.com  Tue Mar 27 23:52:40 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 28 Mar 2018 07:52:40 +0800
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com>
 <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com>
 <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com>
Message-ID: <F15F777F-D671-4938-9467-3324BD040E31@oracle.com>



> On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth

There is only one function to export and it already has JNIEXPORT, so you can just remove the new $(LIBJAAS_CFLAGS) [1].

Are you going to update your webrev?

Thanks
Max

[1] http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/make/lib/Lib-jdk.security.auth.gmk.sdiff.html

From krishna.addepalli at oracle.com  Wed Mar 28 06:36:57 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 27 Mar 2018 23:36:57 -0700 (PDT)
Subject: <AWT Dev> RFR: 8200313 :
 java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails
In-Reply-To: <b56ece53-c7b2-8f6f-de66-71e8a3ebb91b@oracle.com>
References: <b56ece53-c7b2-8f6f-de66-71e8a3ebb91b@oracle.com>
Message-ID: <1c3e6aec-22a4-4041-b561-0b3f70b6d829@default>

Hi Phil,

The changes look fine. However, since you are already making changes to the test, could you also clean up the imports?

Thanks,
Krishna

-----Original Message-----
From: Phil Race 
Sent: Tuesday, March 27, 2018 11:05 PM
To: awt-dev at openjdk.java.net
Subject: <AWT Dev> RFR: 8200313 : java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails

Bug: https://bugs.openjdk.java.net/browse/JDK-8200313
Webrev: http://cr.openjdk.java.net/~prr/8200313/

This test should have been updated when I switched the default but it was overlooked.

-phil.

From shashidhara.veerabhadraiah at oracle.com  Wed Mar 28 09:29:02 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Wed, 28 Mar 2018 02:29:02 -0700 (PDT)
Subject: <AWT Dev> [11] JDK-8181910: [macos] Support dark title bars on macOS
Message-ID: <da79d2ca-1ba2-48eb-91bb-5353f87b8af7@default>

Hi All, Please review an enhancement for the below bug:

 

Enhancement: https://bugs.openjdk.java.net/browse/JDK-8181910

 

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8181910/webrev.00/

 

This utilizes the NSAppearance to set the appearance theme to dark or light.

 

Thanks and regards,

Shashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180328/bd21c156/attachment.html>

From magnus.ihse.bursie at oracle.com  Wed Mar 28 10:31:49 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 28 Mar 2018 12:31:49 +0200
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <F15F777F-D671-4938-9467-3324BD040E31@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com>
 <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com>
 <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com>
 <F15F777F-D671-4938-9467-3324BD040E31@oracle.com>
Message-ID: <3fce1a22-39e4-b8ba-0713-03cd013a6709@oracle.com>

On 2018-03-28 01:52, Weijun Wang wrote:
>
>> On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth
> There is only one function to export and it already has JNIEXPORT, so you can just remove the new $(LIBJAAS_CFLAGS) [1].
Ok, thanks Max!
> Are you going to update your webrev?
Here is a new webrev. It includes your recommended change in 
Lib-jdk.security.auth.gmk.

It is also updated to keep track of changes in shared native libraries 
that has happend in the mainline since my first webrev. Most notably is 
the addition of libjsig. For now, I have just added the JNIEXPORT 
markers for the platforms that need it. Hopefully we can unify libjsig 
across all platforms, but that seems to be more complicated than I 
thought, so that'll have to wait.

I have also recieved word from Phil Race that there were no testing 
issues for client, so he's happy as well.

Updated webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.03

/Magnus

>
> Thanks
> Max
>
> [1] http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/make/lib/Lib-jdk.security.auth.gmk.sdiff.html


From erik.joelsson at oracle.com  Wed Mar 28 20:17:39 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 28 Mar 2018 13:17:39 -0700
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <3fce1a22-39e4-b8ba-0713-03cd013a6709@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <86488d2c-61e3-e489-d9fc-976178c35775@oracle.com>
 <2329dea1-a75e-bb70-95a6-242a93006c6d@oracle.com>
 <32db4add-8a59-03db-0074-e7df0aed14b8@oracle.com>
 <F15F777F-D671-4938-9467-3324BD040E31@oracle.com>
 <3fce1a22-39e4-b8ba-0713-03cd013a6709@oracle.com>
Message-ID: <a487aeb1-e77a-2785-0f44-f0d1b7c9db5f@oracle.com>

Build changes still look good to me.

/Erik


On 2018-03-28 03:31, Magnus Ihse Bursie wrote:
> On 2018-03-28 01:52, Weijun Wang wrote:
>>
>>> On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie 
>>> <magnus.ihse.bursie at oracle.com> wrote:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8200193 -- for 
>>> jdk.security.auth
>> There is only one function to export and it already has JNIEXPORT, so 
>> you can just remove the new $(LIBJAAS_CFLAGS) [1].
> Ok, thanks Max!
>> Are you going to update your webrev?
> Here is a new webrev. It includes your recommended change in 
> Lib-jdk.security.auth.gmk.
>
> It is also updated to keep track of changes in shared native libraries 
> that has happend in the mainline since my first webrev. Most notably 
> is the addition of libjsig. For now, I have just added the JNIEXPORT 
> markers for the platforms that need it. Hopefully we can unify libjsig 
> across all platforms, but that seems to be more complicated than I 
> thought, so that'll have to wait.
>
> I have also recieved word from Phil Race that there were no testing 
> issues for client, so he's happy as well.
>
> Updated webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.03
>
> /Magnus
>
>>
>> Thanks
>> Max
>>
>> [1] 
>> http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/make/lib/Lib-jdk.security.auth.gmk.sdiff.html
>


From martinrb at google.com  Wed Mar 28 21:53:10 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 28 Mar 2018 14:53:10 -0700
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
Message-ID: <CA+kOe09d+oua_9zBrSu8Du48kiY+ZzMT=ytW5iEopwB28pNv0w@mail.gmail.com>

I can't find any documentation for what JNIEXPORT and friends actually do.
People including myself have been cargo-culting JNIEXPORT and JNICALL for
decades.
Why aren't they in the JNI spec?

---

It's fishy that the attribute externally_visible (which seems very
interesting!) is ARM specific.

  #ifdef ARM
    #define JNIEXPORT
 __attribute__((externally_visible,visibility("default")))
    #define JNIIMPORT
 __attribute__((externally_visible,visibility("default")))
  #else
    #define JNIEXPORT     __attribute__((visibility("default")))
    #define JNIIMPORT     __attribute__((visibility("default")))
  #endif
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180328/2f38583c/attachment.html>

From philip.race at oracle.com  Wed Mar 28 22:03:04 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 28 Mar 2018 15:03:04 -0700
Subject: <AWT Dev> RFR: 8200313 :
 java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails
In-Reply-To: <1c3e6aec-22a4-4041-b561-0b3f70b6d829@default>
References: <b56ece53-c7b2-8f6f-de66-71e8a3ebb91b@oracle.com>
 <1c3e6aec-22a4-4041-b561-0b3f70b6d829@default>
Message-ID: <30b1c212-4bcc-c062-3f0f-3c32daebb338@oracle.com>

Updated webrev : http://cr.openjdk.java.net/~prr/8200313.1/

-phil.

On 03/27/2018 11:36 PM, Krishna Addepalli wrote:
> Hi Phil,
>
> The changes look fine. However, since you are already making changes to the test, could you also clean up the imports?
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Phil Race
> Sent: Tuesday, March 27, 2018 11:05 PM
> To: awt-dev at openjdk.java.net
> Subject: <AWT Dev> RFR: 8200313 : java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200313
> Webrev: http://cr.openjdk.java.net/~prr/8200313/
>
> This test should have been updated when I switched the default but it was overlooked.
>
> -phil.


From magnus.ihse.bursie at oracle.com  Wed Mar 28 22:14:13 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 29 Mar 2018 00:14:13 +0200
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <CA+kOe09d+oua_9zBrSu8Du48kiY+ZzMT=ytW5iEopwB28pNv0w@mail.gmail.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <CA+kOe09d+oua_9zBrSu8Du48kiY+ZzMT=ytW5iEopwB28pNv0w@mail.gmail.com>
Message-ID: <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com>

On 2018-03-28 23:53, Martin Buchholz wrote:
> I can't find any documentation for what JNIEXPORT and friends actually do.
> People including myself have been cargo-culting JNIEXPORT and JNICALL 
> for decades.
> Why aren't they in the JNI spec?
That surprises me. I'm quite certain that javah (or rather, java -h 
nowadays) generate header files with JNIEXPORT and JNICALL.

As you can see in the jni.h and jni_md.h files, JNIEXPORT equals 
__attribute__((visibility("default"))) for compilers that support it 
(gcc and friends), and __declspec(dllexport) for Windows. This means, 
that the symbol should be exported. (And it's ignored if you use 
mapfiles aka linker scripts.)

As for JNICALL, it's empty on most compilers, but evaluates to __stdcall 
on Windows. This defines the calling convention to use. This is required 
for JNI calls from Java. (Ask the JVM team why.) While it's not 
technically required for calling from one dll to another, it's good 
practice to use it all time to be consistent. In any way, it doesn't 
hurt us.

>
> ---
>
> It's fishy that the attribute externally_visible (which seems very 
> interesting!) is ARM specific.
>
> ? #ifdef ARM
> ? ? #define JNIEXPORT 
> ?__attribute__((externally_visible,visibility("default")))
> ? ? #define JNIIMPORT 
> ?__attribute__((externally_visible,visibility("default")))

Yeah, this is broken on so many levels. :-(

The ARM here goes back to the old Oracle proprietary arm32 port. This 
used lto, link time optimization, to get an absolutely minimal runtime, 
at expense of a extremely long built time. (I think linking libjvm took 
like 20 minutes.) But when using lto, you also need to decorate your 
functions with the externally_visible attribute. So this was added to 
get hotspot to export the proper symbols (since they, too, used the 
jni.h file).

So, in short, we should:
1) have used a special, local jni.h file for the proprietary arm port, 
and/or
2) added the externally_visible attribute not based on platform, but on 
the existence of lto.

At this point in time, we're not building the old 32-bit arm port, and I 
doubt anyone does. And even if so, we could probably remove the lto 
part, and thus remove this from jni_md.h. If you want, please file a bug.

/Magnus

> ? #else
> ? ? #define JNIEXPORT ?__attribute__((visibility("default")))
> ? ? #define JNIIMPORT ?__attribute__((visibility("default")))
> ? #endif
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180329/bf7e3456/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Thu Mar 29 00:53:15 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 28 Mar 2018 17:53:15 -0700
Subject: <AWT Dev> RFR: 8200313 :
 java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails
In-Reply-To: <30b1c212-4bcc-c062-3f0f-3c32daebb338@oracle.com>
References: <b56ece53-c7b2-8f6f-de66-71e8a3ebb91b@oracle.com>
 <1c3e6aec-22a4-4041-b561-0b3f70b6d829@default>
 <30b1c212-4bcc-c062-3f0f-3c32daebb338@oracle.com>
Message-ID: <1b21add0-3b83-1837-3a56-19e3fba97dc5@oracle.com>

+1

On 28/03/2018 15:03, Phil Race wrote:
> Updated webrev : http://cr.openjdk.java.net/~prr/8200313.1/
> 
> -phil.
> 
> On 03/27/2018 11:36 PM, Krishna Addepalli wrote:
>> Hi Phil,
>>
>> The changes look fine. However, since you are already making changes 
>> to the test, could you also clean up the imports?
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Phil Race
>> Sent: Tuesday, March 27, 2018 11:05 PM
>> To: awt-dev at openjdk.java.net
>> Subject: <AWT Dev> RFR: 8200313 : 
>> java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200313
>> Webrev: http://cr.openjdk.java.net/~prr/8200313/
>>
>> This test should have been updated when I switched the default but it 
>> was overlooked.
>>
>> -phil.
> 


-- 
Best regards, Sergey.

From krishna.addepalli at oracle.com  Thu Mar 29 01:06:06 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 28 Mar 2018 18:06:06 -0700 (PDT)
Subject: <AWT Dev> RFR: 8200313 :
 java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails
In-Reply-To: <1b21add0-3b83-1837-3a56-19e3fba97dc5@oracle.com>
References: <b56ece53-c7b2-8f6f-de66-71e8a3ebb91b@oracle.com>
 <1c3e6aec-22a4-4041-b561-0b3f70b6d829@default>
 <30b1c212-4bcc-c062-3f0f-3c32daebb338@oracle.com>
 <1b21add0-3b83-1837-3a56-19e3fba97dc5@oracle.com>
Message-ID: <c925c0da-6174-4a90-bd41-7bdd1050da89@default>

+1

-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, March 29, 2018 6:23 AM
To: Phil Race <philip.race at oracle.com>; Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> RFR: 8200313 : java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails

+1

On 28/03/2018 15:03, Phil Race wrote:
> Updated webrev : http://cr.openjdk.java.net/~prr/8200313.1/
> 
> -phil.
> 
> On 03/27/2018 11:36 PM, Krishna Addepalli wrote:
>> Hi Phil,
>>
>> The changes look fine. However, since you are already making changes 
>> to the test, could you also clean up the imports?
>>
>> Thanks,
>> Krishna
>>
>> -----Original Message-----
>> From: Phil Race
>> Sent: Tuesday, March 27, 2018 11:05 PM
>> To: awt-dev at openjdk.java.net
>> Subject: <AWT Dev> RFR: 8200313 : 
>> java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200313
>> Webrev: http://cr.openjdk.java.net/~prr/8200313/
>>
>> This test should have been updated when I switched the default but it 
>> was overlooked.
>>
>> -phil.
> 


--
Best regards, Sergey.

From martinrb at google.com  Thu Mar 29 06:16:18 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 28 Mar 2018 23:16:18 -0700
Subject: <AWT Dev> RFR: JDK-8200178 Remove mapfiles for JDK native
	libraries
In-Reply-To: <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <CA+kOe09d+oua_9zBrSu8Du48kiY+ZzMT=ytW5iEopwB28pNv0w@mail.gmail.com>
 <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com>
Message-ID: <CA+kOe08bkip2eGy8rn8viwtQ3eDP8GQYqRUBnsN02WWV6MqwcA@mail.gmail.com>

On Wed, Mar 28, 2018 at 3:14 PM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2018-03-28 23:53, Martin Buchholz wrote:
>
> I can't find any documentation for what JNIEXPORT and friends actually do.
> People including myself have been cargo-culting JNIEXPORT and JNICALL for
> decades.
> Why aren't they in the JNI spec?
>
> That surprises me. I'm quite certain that javah (or rather, java -h
> nowadays) generate header files with JNIEXPORT and JNICALL.
>
> As you can see in the jni.h and jni_md.h files, JNIEXPORT equals
> __attribute__((visibility("default"))) for compilers that support it (gcc
> and friends), and __declspec(dllexport) for Windows. This means, that the
> symbol should be exported. (And it's ignored if you use mapfiles aka linker
> scripts.)
>
> As for JNICALL, it's empty on most compilers, but evaluates to __stdcall
> on Windows. This defines the calling convention to use. This is required
> for JNI calls from Java. (Ask the JVM team why.) While it's not technically
> required for calling from one dll to another, it's good practice to use it
> all time to be consistent. In any way, it doesn't hurt us.
>

Sure, I can see how JNIEXPORT and JNICALL are implemented, but what do they
*mean?*

For example, one might expect from the JNI prefix that these macros are
exclusively for use by JNI linking, i.e. unsupported except in the output
of javac -h.  But of course in practice they are used with arbitrary
symbols to communicate between components of user native code, not just to
communicate with the JVM.  Is that a bug?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180328/8c8264bc/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Mar 29 14:15:48 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 29 Mar 2018 07:15:48 -0700
Subject: <AWT Dev> [11] JDK-8181910: [macos] Support dark title bars on
 macOS
In-Reply-To: <da79d2ca-1ba2-48eb-91bb-5353f87b8af7@default>
References: <da79d2ca-1ba2-48eb-91bb-5353f87b8af7@default>
Message-ID: <a674059d-3121-9140-1ddc-c13b3865f599@oracle.com>

Unfortunately we cannot accept the patch which were suggested in the 
description of the bug. Initially it was implemented in JetBrains JRE. 
We can accept it if someone from the JetBrains will contribute it.

Maybe Denis who is author of the fix can help?

On 28/03/2018 02:29, Shashidhara Veerabhadraiah wrote:
> Hi All, Please review an enhancement for the below bug:
> 
> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8181910
> 
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8181910/webrev.00/
> 
> This utilizes the NSAppearance to set the appearance theme to dark or light.
> 
> Thanks and regards,
> 
> Shashi
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Thu Mar 29 19:42:05 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 29 Mar 2018 12:42:05 -0700
Subject: <AWT Dev> [11] Review Request: 8198335
 java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java
 fails in headless mode
In-Reply-To: <7adcfab6-ef88-52e8-fd7e-b15b1128df41@oracle.com>
References: <125498b3-9658-4912-6e9c-b44b021206e4@oracle.com>
 <5AB99545.3000106@oracle.com>
 <7adcfab6-ef88-52e8-fd7e-b15b1128df41@oracle.com>
Message-ID: <688b2963-75b6-20eb-f18c-649d50e526ac@oracle.com>

So once it was explained to me that this headless VM exec's
another headful VM instance it started to make sense ..

+1

-phil.

On 03/26/2018 07:02 PM, Sergey Bylokhov wrote:
> On 26/03/2018 17:50, Philip Race wrote:
>> I presume the headful keyword means thie can't be run in our nightly 
>> tests ..and
>> isn't supposed to be run in headless mode, so I am a bit puzzled by 
>> the change.
>> I also don't understand why it would be "random".
>
> An updated test just emulates the problem, it run the first instance 
> using "-Djava.awt.headless" and then unconditionally tries to change 
> the system display mode, this causes an exception in the headless 
> instance.
>
>> This bug cause the random failures of our headless tests
> Here I have referenced any other tests in nightly, which fails if we 
> get such notifications from the OS.
>
>>
>>    * @key headful
>>    * @summary Tests that no exception is thrown when display mode is 
>> changed
>>    *          externally
>>    * @compile UninitializedDisplayModeChangeTest.java 
>> DisplayModeChanger.java
>>    * @run main/othervm UninitializedDisplayModeChangeTest
>> + * @run main/othervm -Djava.awt.headless=true 
>> UninitializedDisplayModeChangeTest
>>    */
>>
>> -phil.
>>
>> On 3/20/18, 11:48 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review fix for jdk11.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198335
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8198335/webrev.01
>>>
>>> This bug cause the random failures of our headless tests. The reason 
>>> is that we try to notify the 
>>> GraphicsEnvironment(HeadlessGraphicsEnvironment), which does not 
>>> implement DisplayChangedListener, about display change.
>>>
>>> It is possible to skip this notification for headlesGE only, but I 
>>> think that it is better to make instanceof before cast to 
>>> DisplayChangedListener, usually we use this pattern in other places.
>>>
>>> PS. Note that WToolkit.paletteChanged and WToolkit.displayChanged 
>>> use different threads for notifications, I have created a bug to 
>>> investigate this: https://bugs.openjdk.java.net/browse/JDK-8199881
>>>
>>>
>
>


From shashidhara.veerabhadraiah at oracle.com  Fri Mar 30 05:32:14 2018
From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com)
Date: Fri, 30 Mar 2018 11:02:14 +0530
Subject: <AWT Dev> [11] JDK-8181910: [macos] Support dark title bars on
 macOS
In-Reply-To: <a674059d-3121-9140-1ddc-c13b3865f599@oracle.com>
References: <da79d2ca-1ba2-48eb-91bb-5353f87b8af7@default>
 <a674059d-3121-9140-1ddc-c13b3865f599@oracle.com>
Message-ID: <9e2fcb3c-425e-6ad7-7778-5a297902df64@oracle.com>

Sure. I did had a confusion to put for review though but did not know 
what to do and felt not to keep waiting. Thanks for the direction Sergey.

Thanks and regards,
Shashi


On 29/03/18 7:45 PM, Sergey Bylokhov wrote:
> Unfortunately we cannot accept the patch which were suggested in the 
> description of the bug. Initially it was implemented in JetBrains JRE. 
> We can accept it if someone from the JetBrains will contribute it.
>
> Maybe Denis who is author of the fix can help?
>
> On 28/03/2018 02:29, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review an enhancement for the below bug:
>>
>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8181910
>>
>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8181910/webrev.00/
>>
>> This utilizes the NSAppearance to set the appearance theme to dark or 
>> light.
>>
>> Thanks and regards,
>>
>> Shashi
>>
>
>


From dipak.kumar at oracle.com  Fri Mar 30 05:54:14 2018
From: dipak.kumar at oracle.com (Dipak Kumar)
Date: Thu, 29 Mar 2018 22:54:14 -0700 (PDT)
Subject: <AWT Dev> [8u-backport] Review request for 8195738 : scroll
 poistion in ScrollPane is reset after calling validate()
In-Reply-To: <7f697864-ce44-4693-9a17-99f01fc659e6@default>
References: <10404fdb-0444-4d15-8d09-e7f499cbcb5a@default>
 <CANmuJ8tWznJW+RrNWQWJP79e4b0-bhFdVVdrOsnoOQAsavR+ng@mail.gmail.com>
 <035c1dd3-f03a-46d5-88ed-fc7235a1ce76@default>
 <CANmuJ8tCsuOuXObMO0ZfVYBtBoKbScVzoyTZg-dRUFSJVx4B9Q@mail.gmail.com>
 <e665fe01-00fd-5533-3182-fa1c2636310f@oracle.com>
 <7f697864-ce44-4693-9a17-99f01fc659e6@default>
Message-ID: <6109d9f5-c51e-42f9-a7d0-93fceb011054@default>

Requesting to review the changes mentioned in the trailing mail. 

It's a backport from Jdk-11 to Jdk-8. Backport is almost clean and there is one line difference in the test file compare to Jdk-11.

?

Awaiting response.

?

Thanks,

Dipak

?

From: Dipak Kumar 
Sent: 23 March 2018 12:43
To: awt-dev at openjdk.java.net
Subject: RE: <AWT Dev> [8u-backport] Review request for 8195738 : scroll poistion in ScrollPane is reset after calling validate()

?

Just a gentle reminder. Requesting again to review the changes.

?

Thanks,

Dipak

?

From: Shashidhara Veerabhadraiah 
Sent: 20 March 2018 09:26
To: Patrick Chen <HYPERLINK "mailto:chen.j.patrick at gmail.com"chen.j.patrick at gmail.com>; Dipak Kumar <HYPERLINK "mailto:dipak.kumar at oracle.com"dipak.kumar at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [8u-backport] Review request for 8195738 : scroll poistion in ScrollPane is reset after calling validate()

?

Hi Patrick, For the case of scroll bar policy as SCROLLBARS_NEVER, we used to call SetScrollInfo() with nMin and nMax as zero which used to reset the already set value for the scroll bars. There is a better way to resolve this by calling ShowScrollBar() and maintain the set size of the scroll bar without resetting it.

Since the code that does this job is present in cpp files which calls the native api's, they need to be updated to accommodate this fix which fixes the JBS bug.

Hope this answers your question and do have a good day.

Thanks and regards,
Shashi

?

On 19/03/18 2:05 PM, Patrick Chen wrote:

Hi,

I am not to understand why ScrollPane.cpp was changed ? 

And why cpp files? 

Cheers

?

2018-03-19 6:25 GMT+01:00 Dipak Kumar <HYPERLINK "mailto:dipak.kumar at oracle.com"dipak.kumar at oracle.com>:

Hi Patrick,

?

File ?awt_ScrollPane.cpp? has already been reviewed as part of JDK 11. The only difference between JDK 11 changeset and JDK 8 backport is the test file (ScrollPaneValidateTest.java), not awt_ScrollPane.cpp.

I had mentioned that in my previous mail.

?

If at all there is any concern related awt_ScrollPane.cpp file then I think that should be dealt after filing another issue.

?

Moreover I didn't really get your question. Out of two nested if blocks, one has been removed and yes, variables are being used and their declarations are still intact.

?

Please let me know if you need any more info.

?

Thanks,

Dipak

?

From: Patrick Chen [mailto:HYPERLINK "mailto:chen.j.patrick at gmail.com"chen.j.patrick at gmail.com] 
Sent: 14 March 2018 18:21
To: Dipak Kumar <HYPERLINK "mailto:dipak.kumar at oracle.com"dipak.kumar at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [8u-backport] Review request for 8195738 : scroll poistion in ScrollPane is reset after calling validate()

?

Hi, 

Why in src/windows/native/sun/windows/awt_ScrollPane.cpp did you delete? the main condition?

Means : the two variables are used isn't it ?

?

Cheers,

Pc 

?

2018-03-14 11:02 GMT+01:00 Dipak Kumar <HYPERLINK "mailto:dipak.kumar at oracle.com"dipak.kumar at oracle.com>:

Hi All,

?

Please review the below patch (for 8u-backport) - 

?

Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Edkumar/8195738/webrev.00/"http://cr.openjdk.java.net/~dkumar/8195738/webrev.00/ ?

JBS : https://bugs.openjdk.java.net/browse/JDK-8195738 ?

JDK 11 changeset - http://hg.openjdk.java.net/jdk/client/rev/96bebffe0be1 

?

Patch pushed for JDK 11 applies cleanly to JDK 8 after adjusting file path except 'headful' keyword has been removed from the test as this is not defined for 8.

Related Jtreg tests have been run against the proposed patch and results are fine.

?

Thanks,

Dipak

?

?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180329/9302444a/attachment-0001.html>

From krishna.addepalli at oracle.com  Fri Mar 30 18:09:32 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 30 Mar 2018 11:09:32 -0700 (PDT)
Subject: <AWT Dev> [11]JDK-8200525: test
 java/awt/event/SequencedEvent/SequencedEventTest.java fails to compile
Message-ID: <43f5e555-240f-4eae-a525-f69bd02755f1@default>

Hi All,

 

Please review a trivial compilation fix for the bug: https://bugs.openjdk.java.net/browse/JDK-8200525

Webrev: http://cr.openjdk.java.net/~kaddepalli/8200525/webrev00/

 

The problem was, the test case uses some of the internal classes, which were not specified for the jtreg data section, due to which the test was failing to compile when run with jtreg.

 

Thanks,

Krishna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180330/621055b5/attachment.html>

From philip.race at oracle.com  Fri Mar 30 18:51:20 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 30 Mar 2018 11:51:20 -0700
Subject: <AWT Dev> [11]JDK-8200525: test
 java/awt/event/SequencedEvent/SequencedEventTest.java fails to compile
In-Reply-To: <43f5e555-240f-4eae-a525-f69bd02755f1@default>
References: <43f5e555-240f-4eae-a525-f69bd02755f1@default>
Message-ID: <848580a1-e9c8-7e21-0289-b280f5d75f95@oracle.com>

+1 .. but since you are fixing this can you correct the spelling of 
occurs before you push :

   * @summary AWT hang occurrs when sequenced events arrive out of sequence

-phil.



On 03/30/2018 11:09 AM, Krishna Addepalli wrote:
>
> Hi All,
>
> Please review a trivial compilation fix for the bug: 
> https://bugs.openjdk.java.net/browse/JDK-8200525
>
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8200525/webrev00/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8200525/webrev00/>
>
> The problem was, the test case uses some of the internal classes, 
> which were not specified for the jtreg data section, due to which the 
> test was failing to compile when run with jtreg.
>
> Thanks,
>
> Krishna
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180330/5a6d6d2b/attachment.html>

From Sergey.Bylokhov at oracle.com  Fri Mar 30 20:48:45 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 30 Mar 2018 13:48:45 -0700
Subject: <AWT Dev> [11]JDK-8200525: test
 java/awt/event/SequencedEvent/SequencedEventTest.java fails to compile
In-Reply-To: <43f5e555-240f-4eae-a525-f69bd02755f1@default>
References: <43f5e555-240f-4eae-a525-f69bd02755f1@default>
Message-ID: <b14f0d95-4bc7-f297-b150-a4586d1d3057@oracle.com>

+1

On 30/03/2018 11:09, Krishna Addepalli wrote:
> Hi All,
> 
> Please review a trivial compilation fix for the bug: 
> https://bugs.openjdk.java.net/browse/JDK-8200525
> 
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8200525/webrev00/
> 
> The problem was, the test case uses some of the internal classes, which 
> were not specified for the jtreg data section, due to which the test was 
> failing to compile when run with jtreg.
> 
> Thanks,
> 
> Krishna
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Mar 30 22:52:13 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 30 Mar 2018 15:52:13 -0700
Subject: <AWT Dev> [11] Review Request: 8200146 Remove the appletviewer
	launcher
Message-ID: <419d6585-fa7f-f14a-bac8-3129ceb53c8b@oracle.com>

Hello.
Please review fix for jdk11.

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

Fix description:
  - The appletviewer launcher was removed from jdk/bin
  - The man pages were removed
  - Two tests which used appletviewer launcher directly were removed

Note that the appletviewer was deprecated in in jdk9:
https://bugs.openjdk.java.net/browse/JDK-8074165

-- 
Best regards, Sergey.