Re: 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements

[Jim Graham]

The "@return" tags should not start with "returns" in the text.

Also, in the @return for getProperty(), insert a word "the" as "the property of the 
base image"...

...jim

On 10/26/16 12:36 AM, Avik Niyogi wrote:

Hi All,

Please review the proposed specification for JDK9 including inputs from reviver 
reviews.

*cr.openjdk.java.net/~aniyogi/8138771/webrev.03/* 



Thank you in advance.

With Regards,
Avik Niyogi

Re: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK

[Semyon Sadetsky]

On 10/26/2016 6:43 PM, Sergey Bylokhov wrote:

On 25.10.16 18:46, Semyon Sadetsky wrote:

I wonder why he should decide that the old code can be "simply
replaced" by the new one? I suppose that at least he should read the
specification of the new extended API. There is no notion that this
api is replaced by the new one, there is a recommendation that the new
one should be used instead.

After reading such recommendation it's hard to conclude that one "should
read the specification of the new extended API". Even "@see" tag
pointing to the extended API is not provided (I'm not even mentioning
the warning that the extended API may be nonequivalent replacement is
absent). I read this recommendation as it is: replace one constant with
another, no side effects expected.


Good to know that you don't read the specification of the methods 
before using. So what is your proposal? Should I add a notion that 
these extendent constants contains different int values, and if the 
user depends from them in some way then he should not replace the old 
one to the new one? Or what @see reference should be added from some 
fields to another?
The proposal is the same to notify user that he/she should not only 
replace the constant but start to use another API. It's up to you how to 
formulate this. If I did this in minimalistic way I would write:


@deprecated It is recommended that SHIFT_DOWN_MASK and {@link 
getModifiersEx()} be used instead.





We already have a notions that these "extended modifier constant"
should be used in the constructor of InputEvent and moreover in spec
of getModifiersEx() we have an additional examples how to use this
constants. This is why we will have a reference from old constans to
the new, and from getModifiers() to the getModifiersEx();

Re: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK

[Sergey Bylokhov]

On 25.10.16 18:46, Semyon Sadetsky wrote:

I wonder why he should decide that the old code can be "simply
replaced" by the new one? I suppose that at least he should read the
specification of the new extended API. There is no notion that this
api is replaced by the new one, there is a recommendation that the new
one should be used instead.

After reading such recommendation it's hard to conclude that one "should
read the specification of the new extended API". Even "@see" tag
pointing to the extended API is not provided (I'm not even mentioning
the warning that the extended API may be nonequivalent replacement is
absent). I read this recommendation as it is: replace one constant with
another, no side effects expected.


Good to know that you don't read the specification of the methods before 
using. So what is your proposal? Should I add a notion that these 
extendent constants contains different int values, and if the user 
depends from them in some way then he should not replace the old one to 
the new one? Or what @see reference should be added from some fields to 
another?





We already have a notions that these "extended modifier constant"
should be used in the constructor of InputEvent and moreover in spec
of getModifiersEx() we have an additional examples how to use this
constants. This is why we will have a reference from old constans to
the new, and from getModifiers() to the getModifiersEx();




--
Best regards, Sergey.

Re: [9] Review request for 8167652: Making a frame/dialog resizeble/unresizeble shifts its position on Unity.

[Semyon Sadetsky]

Please review the updated fix: 
http://cr.openjdk.java.net/~ssadetsky/8167652/webrev.01/


- unnecessary AWT locks are removed

- client code calls are taken away from AWT lock blocks

- some design improvements are made

--Semyon


On 10/19/2016 8:38 PM, Sergey Bylokhov wrote:

Hi, Semyon.
A few notes.
 - The awtLock is a lowlevel lock which should be used only when we 
access the xlib and some other native resource like opengl. We should 
not call the users code on it. In the fix the code in 
XDecoratedPeer.updateMinimumSize() will call the users code.
 - Some of the changed methods are called already under this lock, for 
example XDecoratedPeer.handlePropertyNotify(), and probably others.


On 18.10.16 16:46, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK9:

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

webrev: http://cr.openjdk.java.net/~ssadetsky/8167652/webrev.00/

In Linux, when a frame or dilalog is made resizable or non-resizable the
window decoration need to be updated. For that purpose window is
unmapped and mapped again and WM changes the window decoration parent.
The re-parenting may cause WM to send intermediate "artifact events"
which change the window location on the screen, this WM behavior is
undocumented. To avoid window move the window shift is compensated in
XWM.setShellResizable()/XWM.setShellNotResizable(), but Unity WM shifts
the window position in different way. In the proposed solution the
window shift compensation is adjusted for Unity WM.

Also in the fix all writes to the fields that store the current state of
window dimensions are protected with the AWT lock. This is necessary to
avoid unexpected window move or resize when the window dimensions are
changed from the user thread concurrently while the AWT toolkit thread
handles WM sent notifications affecting the current window state, size,
position, insets, etc.

--Semyon

8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements

[Avik Niyogi]

Hi All,

Please review the proposed specification for JDK9 including inputs from reviver 
reviews.

cr.openjdk.java.net/~aniyogi/8138771/webrev.03/ 



Thank you in advance.

With Regards,
Avik Niyogi

Re: Review Request : JDK-8168292 [TestBug]Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X

[Prasanta Sadhukhan]

Hi Prem,

+1 to 8168292 but one thing is that this issue is created to enable to 
work on 8168291 and was mentioned that the problem DragEventSource fails 
on osx will be addressed as part of 8168292 which I do not see being 
done in your webrev.

So, either open up 8168291 or fix it in this bug.

Regards
Prasanta
On 10/25/2016 2:25 PM, Ajit Ghaisas wrote:


Looks fine.

Regards,

Ajit

*From:* Prem Balakrishnan
*Sent:* Monday, October 24, 2016 3:16 PM
*To:* Ajit Ghaisas; Alexander Scherbatiy; Rajeev Chamyal; 
awt-dev@openjdk.java.net
*Subject:* RE:  Review Request : JDK-8168292 [TestBug]Test 
java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X


Hi Ajit,

Thankyou for the review.

Updated patch as per review comments.

http://cr.openjdk.java.net/~pkbalakr/8168292/webrev.01/ 



Regards,

Prem

*From:*Ajit Ghaisas
*Sent:* Monday, October 24, 2016 2:00 PM
*To:* Prem Balakrishnan; Alexander Scherbatiy; Rajeev Chamyal; 
awt-dev@openjdk.java.net 
*Subject:* RE:  Review Request : JDK-8168292 [TestBug]Test 
java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X


Hi Prem,

I know this is compilation fix, but still few corrections can be 
made to the test.


1.Please replace generic imports to specific class imports.

2.First sentence of the instruction text has a typo – please correct it.

Existing  : “Use see a Frame with a button in it."

Should be : “User sees a Frame with a button on it."

Regards,

Ajit

*From:* Prem Balakrishnan
*Sent:* Thursday, October 20, 2016 3:00 PM
*To:* Alexander Scherbatiy; Rajeev Chamyal; awt-dev@openjdk.java.net 

*Subject:*  Review Request : JDK-8168292 [TestBug]Test 
java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X


Hi,

Please review the patch.

*Test Bug: *https://bugs.openjdk.java.net/browse/JDK-8168292**

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



Compilation error: Can't find library\: ../../../regtesthelpers

Fix: updated the library path

Regards,

Prem**