Re: 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 
reviewer reviews.
http://cr.openjdk.java.net/~aniyogi/8138771/webrev.04/ 

Thank you in advance.

With Regards,
Avik Niyogi

> On 27-Oct-2016, at 2:33 am, Jim Graham  wrote:
> 
> 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] RFR JDK-8168657: [PIT] Still, on Windows test always fails: java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java

[Prasanta Sadhukhan]

What I meant to say is hidpi splashscreen support is not there in 
solaris (already told earlier too)


http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010813.html

and this
http://hg.openjdk.java.net/jdk9/client/jdk/file/eeb8b31afed6/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c#l809
returns false if it is NOT linux which means we will get base image and 
not scaled image in solaris


and this testcase is about hidpi splashscreen testing so it is not 
needed for solaris.


Regards
Prasanta
On 10/26/2016 9:57 PM, Philip Race wrote:
Are you sure about that ? I can't think why it would not work on 
Solaris just as it works everywhere else.


And when I run 'java -help' on Solaris it lists the option :-
-splash:
  show splash screen with specified image

-phil.

On 10/26/16, 8:27 AM, Prasanta Sadhukhan wrote:

No, as I understand splashscreen support is not there for solaris.

Regards
Prasanta
On 10/26/2016 8:55 PM, Sergey Bylokhov wrote:

Should this test work on Solaris as well?

On 26.10.16 10:19, Prasanta Sadhukhan wrote:

Hi All,

Please review a simple fix for splasscreen testissue where we need to
restrict this test from running on linux as this test uses linux
enviroment variable GDK_SCALE so
restricting to run only on linux.

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

diff -r aae3690e53e3
test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 



---
a/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 


Thu Oct 20 14:21:46 2016 +0300
+++
b/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 


Wed Oct 26 12:46:56 2016 +0530
@@ -47,6 +47,7 @@
  * @test @bug 8145174 8151787
  * @summary HiDPI splash screen support on Linux
  * @modules java.desktop/sun.java2d
+ * @requires (os.family == "linux")
  * @run main UnixMultiResolutionSplashTest
  */
 public class UnixMultiResolutionSplashTest {


Regards
Prasanta

Re: [9] Review request for 8074883: Tab key should move to focused button in a button group

[Semyon Sadetsky]

Thank you, Alexander. Please review the updated webrev: 
http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.01/


CCC request will be filed after the fix is approved.

--Semyon


On 10/25/2016 3:14 PM, Alexandr Scherbatiy wrote:

On 10/19/2016 8:14 PM, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK9:

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

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

To avoid unexpected selection change the selected button of a button 
group should always grab focus when focus is transferred form 
component outside the group to any unselected button inside the group 
in case of traversal or initial container activation actions.
  - It is better to pass the cause and boolean focusInWindow arguments 
to the getGroupSelection() method to avoid some code duplication like 
switching over the same cause values.
  - The fix will require a CCC request because it updates a javadoc 
for the publci method.


  Thanks,
  Alexandr.


--Semyon

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

[Mandy Chung]

Should the same change be applied to the .h files as well?

Mandy

> On Oct 26, 2016, at 7:24 PM, Pete Brunet  wrote:
> 
> Please review the latest update at
> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/
> 
> The change is to AccessBridgeCalls.c.  The license has been changed from
> GPL2 to BSD.  This is because the file was originally unlicensed prior
> to being bundled into the JDK and the compiled .obj is linked to by
> vendors creating proprietary code.  Vendors will be instructed to
> download AccessBridgeCalls.c from the OpenJDK repository.  Also the
> include/use of AccessBridgeDebug.h/cpp has been removed.
> 
> Please also review readme.html which has been added to
> .../jdk/include/win32/bridge.
> 
> Pete
> 
> On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:
>> 
>> The fix looks good to me.
>> 
>> Thanks,
>> Alexandr.
>> 
>> On 10/24/2016 1:18 PM, Erik Joelsson wrote:
>>> The last change looks good and simple to me.
>>> 
>>> /Erik
>>> 
>>> 
>>> On 2016-10-21 06:55, Pete Brunet wrote:
 Please see the latest update
 http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/
 
 The fix now is to simply remove the copy of the AccessBridgeCalls.c
 file
 into the JDK.
 
 AccessBridgeCalls.c is the implementation of the documented Java Access
 Bridge API and is a set of wrapper functions that hides the
 complications related to interfacing to JAB's WindowsAccessBridge*.dll.
 In the past users of the API would compile and link to
 AccessBridgeCalls.c/obj.
 
 Since the interface implementation of AccessBridgeCalls.c will no
 longer
 be provided the JAB API documentation will be updated to instruct a
 user
 how to create an equivalent of AccessBridgeCalls.c.  The documentation
 will also contain a reference to the JAB 2.0.2 download
 http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html
 
 which does contain AccessBridgeCalls.c and which is compatible with the
 current API and related calls into WindowsAccessBridge*.dll.
 
 Pete
 
 On 10/18/16 12:28 PM, Pete Brunet wrote:
> I've updated the webrev.  Please see
> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/
> 
> Rather than removing the files needed by Assistive Technology
> developers
> we have to provide them in JDK.  However since there is a .c file
> in the
> group of files the files were moved from the include directory to a
> new
> javaaccessbridge directory.
> 
> On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:
>> On 2016-10-14 17:51, Pete Brunet wrote:
>>> Please review the following.
>>> 
>>> The .h files and .c file provided to allow Assistive Technology to
>>> interface to the Java Access Bridge API are being removed from
>>> the built
>>> JRE/JDK images.  They are not used much and they can be obtained
>>> online
>>> via the OpenJDK web site.  The pubs will be updated to mention the
>>> location of the files.
>>> 
>>> Since there is a .c file in this group of files the directory
>>> structure
>>> has been changed slightly to remove the include directory.
>>> 
>>> There was one file missing from the group of files needed by
>>> developers
>>> and that was moved from the common to the bridge directory.
>>> 
>>> The make was updated in response to the above.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167213
>>> 
>>> Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.00/
>> Build changes looks good to me.
>> 
>> /Magnus
>>> 
>> 
> 

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

[Pete Brunet]

Thanks Anirvan.  Appreciate you taking the time to participate in this
thread.

On 10/26/16 11:27 PM, Anirvan Sarkar wrote:
> Hi,
>
> If you replace the hex number with 'tip' then it will always point to
> the latest version. 
>
> Something
> like 
> http://hg.openjdk.java.net/jdk9/client/jdk/file/tip/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c
> 
>
> Regards,
> Anirvan Sarkar
>
> On Thursday 27 October 2016, Pete Brunet  > wrote:
>
>
>
> On 10/26/16 10:44 PM, Philip Race wrote:
>> >
>>   15 > href="http://hg.openjdk.java.net/jdk9/client/jdk/file/544828ab2a9b/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c";
>> 
>> >
>> That URL is definitely not authoritative.
>>
>> I think you need to give a pointer to something more like
>> 
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c
>> 
>> 
> Looks like that hex number in there is the Mercurial long revision
> number of the tip so that's going to keep changing.  I'm not aware
> of a "latest" link.  Maybe some other reader will know.
>> But I am not sure about that either .. it may need to be split between 
>> the main URL and the location in the repo.
>>
>> -phil 
>> On 10/26/16, 7:24 PM, Pete Brunet wrote:
>>> Please review the latest update at
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/
>>> 
>>>
>>> The change is to AccessBridgeCalls.c.  The license has been changed from
>>> GPL2 to BSD.  This is because the file was originally unlicensed prior
>>> to being bundled into the JDK and the compiled .obj is linked to by
>>> vendors creating proprietary code.  Vendors will be instructed to
>>> download AccessBridgeCalls.c from the OpenJDK repository.  Also the
>>> include/use of AccessBridgeDebug.h/cpp has been removed.
>>>
>>> Please also review readme.html which has been added to
>>> .../jdk/include/win32/bridge.
>>>
>>> Pete
>>>
>>> On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:
 The fix looks good to me.

 Thanks,
 Alexandr.

 On 10/24/2016 1:18 PM, Erik Joelsson wrote:
> The last change looks good and simple to me.
>
> /Erik
>
>
> On 2016-10-21 06:55, Pete Brunet wrote:
>> Please see the latest update
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/
>> 
>>
>> The fix now is to simply remove the copy of the AccessBridgeCalls.c
>> file
>> into the JDK.
>>
>> AccessBridgeCalls.c is the implementation of the documented Java 
>> Access
>> Bridge API and is a set of wrapper functions that hides the
>> complications related to interfacing to JAB's 
>> WindowsAccessBridge*.dll.
>> In the past users of the API would compile and link to
>> AccessBridgeCalls.c/obj.
>>
>> Since the interface implementation of AccessBridgeCalls.c will no
>> longer
>> be provided the JAB API documentation will be updated to instruct a
>> user
>> how to create an equivalent of AccessBridgeCalls.c.  The 
>> documentation
>> will also contain a reference to the JAB 2.0.2 download
>> 
>> http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html
>> 
>> 
>>
>> which does contain AccessBridgeCalls.c and which is compatible with 
>> the
>> current API and related calls into WindowsAccessBridge*.dll.
>>
>> Pete
>>
>> On 10/18/16 12:28 PM, Pete Brunet wrote:
>>> I've updated the webrev.  Please see
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/
>>> 
>>>
>>> Rather than removing the files needed by Assistive Technology
>>> developers
>>> we have to provide them in JDK.  However since there is a .c file
>>> in the
>>> group of files the files were moved from the include directory to a
>>> new
>>> javaaccessbridge directory.
>>>
>>> On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:
 On 2016-10-14 17:51, Pete Brunet wrote:
> Please review the

RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

[Anirvan Sarkar]

Hi,

If you replace the hex number with 'tip' then it will always point to the
latest version.

Something like http://hg.openjdk.java.net/jdk9/client/jdk/file/tip/
src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c

Regards,
Anirvan Sarkar

On Thursday 27 October 2016, Pete Brunet > wrote:

>
>
> On 10/26/16 10:44 PM, Philip Race wrote:
>
> >
>
>   15  href="http://hg.openjdk.java.net/jdk9/client/jdk/file/544828ab2a9b/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c";
>  
> >
> That URL is definitely not authoritative.
>
> I think you need to give a pointer to something more 
> likehttp://hg.openjdk.java.net/jdk9/jdk9/jdk/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c
>
> Looks like that hex number in there is the Mercurial long revision number
> of the tip so that's going to keep changing.  I'm not aware of a "latest"
> link.  Maybe some other reader will know.
>
> But I am not sure about that either .. it may need to be split between the 
> main URL and the location in the repo.
>
> -phil
>
>
>
> On 10/26/16, 7:24 PM, Pete Brunet wrote:
>
> Please review the latest update 
> athttp://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/
>
> The change is to AccessBridgeCalls.c.  The license has been changed from
> GPL2 to BSD.  This is because the file was originally unlicensed prior
> to being bundled into the JDK and the compiled .obj is linked to by
> vendors creating proprietary code.  Vendors will be instructed to
> download AccessBridgeCalls.c from the OpenJDK repository.  Also the
> include/use of AccessBridgeDebug.h/cpp has been removed.
>
> Please also review readme.html which has been added to
> .../jdk/include/win32/bridge.
>
> Pete
>
> On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:
>
> The fix looks good to me.
>
> Thanks,
> Alexandr.
>
> On 10/24/2016 1:18 PM, Erik Joelsson wrote:
>
> The last change looks good and simple to me.
>
> /Erik
>
>
> On 2016-10-21 06:55, Pete Brunet wrote:
>
> Please see the latest 
> updatehttp://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/
>
> The fix now is to simply remove the copy of the AccessBridgeCalls.c
> file
> into the JDK.
>
> AccessBridgeCalls.c is the implementation of the documented Java Access
> Bridge API and is a set of wrapper functions that hides the
> complications related to interfacing to JAB's WindowsAccessBridge*.dll.
> In the past users of the API would compile and link to
> AccessBridgeCalls.c/obj.
>
> Since the interface implementation of AccessBridgeCalls.c will no
> longer
> be provided the JAB API documentation will be updated to instruct a
> user
> how to create an equivalent of AccessBridgeCalls.c.  The documentation
> will also contain a reference to the JAB 2.0.2 
> downloadhttp://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html
>
> which does contain AccessBridgeCalls.c and which is compatible with the
> current API and related calls into WindowsAccessBridge*.dll.
>
> Pete
>
> On 10/18/16 12:28 PM, Pete Brunet wrote:
>
> I've updated the webrev.  Please 
> seehttp://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/
>
> Rather than removing the files needed by Assistive Technology
> developers
> we have to provide them in JDK.  However since there is a .c file
> in the
> group of files the files were moved from the include directory to a
> new
> javaaccessbridge directory.
>
> On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:
>
> On 2016-10-14 17:51, Pete Brunet wrote:
>
> Please review the following.
>
> The .h files and .c file provided to allow Assistive Technology to
> interface to the Java Access Bridge API are being removed from
> the built
> JRE/JDK images.  They are not used much and they can be obtained
> online
> via the OpenJDK web site.  The pubs will be updated to mention the
> location of the files.
>
> Since there is a .c file in this group of files the directory
> structure
> has been changed slightly to remove the include directory.
>
> There was one file missing from the group of files needed by
> developers
> and that was moved from the common to the bridge directory.
>
> The make was updated in response to the above.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167213
>
> Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.00/
>
> Build changes looks good to me.
>
> /Magnus
>
>
>

-- 
Sent from Gmail Mobile

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

[Pete Brunet]

I found a comment from Mandy in the bug.  That hex number can be
replaced with "tip".

I uploaded http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.04/

Pete


On 10/26/16 11:05 PM, Pete Brunet wrote:
>
>
> On 10/26/16 10:44 PM, Philip Race wrote:
>> >
>>   15 > href="http://hg.openjdk.java.net/jdk9/client/jdk/file/544828ab2a9b/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c";>
>> That URL is definitely not authoritative.
>>
>> I think you need to give a pointer to something more like
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c
> Looks like that hex number in there is the Mercurial long revision
> number of the tip so that's going to keep changing.  I'm not aware of
> a "latest" link.  Maybe some other reader will know.
>> But I am not sure about that either .. it may need to be split between the 
>> main URL and the location in the repo.
>>
>> -phil 
>>
>>
>> On 10/26/16, 7:24 PM, Pete Brunet wrote:
>>> Please review the latest update at
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/
>>>
>>> The change is to AccessBridgeCalls.c.  The license has been changed from
>>> GPL2 to BSD.  This is because the file was originally unlicensed prior
>>> to being bundled into the JDK and the compiled .obj is linked to by
>>> vendors creating proprietary code.  Vendors will be instructed to
>>> download AccessBridgeCalls.c from the OpenJDK repository.  Also the
>>> include/use of AccessBridgeDebug.h/cpp has been removed.
>>>
>>> Please also review readme.html which has been added to
>>> .../jdk/include/win32/bridge.
>>>
>>> Pete
>>>
>>> On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:
 The fix looks good to me.

 Thanks,
 Alexandr.

 On 10/24/2016 1:18 PM, Erik Joelsson wrote:
> The last change looks good and simple to me.
>
> /Erik
>
>
> On 2016-10-21 06:55, Pete Brunet wrote:
>> Please see the latest update
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/
>>
>> The fix now is to simply remove the copy of the AccessBridgeCalls.c
>> file
>> into the JDK.
>>
>> AccessBridgeCalls.c is the implementation of the documented Java Access
>> Bridge API and is a set of wrapper functions that hides the
>> complications related to interfacing to JAB's WindowsAccessBridge*.dll.
>> In the past users of the API would compile and link to
>> AccessBridgeCalls.c/obj.
>>
>> Since the interface implementation of AccessBridgeCalls.c will no
>> longer
>> be provided the JAB API documentation will be updated to instruct a
>> user
>> how to create an equivalent of AccessBridgeCalls.c.  The documentation
>> will also contain a reference to the JAB 2.0.2 download
>> http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html
>>
>> which does contain AccessBridgeCalls.c and which is compatible with the
>> current API and related calls into WindowsAccessBridge*.dll.
>>
>> Pete
>>
>> On 10/18/16 12:28 PM, Pete Brunet wrote:
>>> I've updated the webrev.  Please see
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/
>>>
>>> Rather than removing the files needed by Assistive Technology
>>> developers
>>> we have to provide them in JDK.  However since there is a .c file
>>> in the
>>> group of files the files were moved from the include directory to a
>>> new
>>> javaaccessbridge directory.
>>>
>>> On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:
 On 2016-10-14 17:51, Pete Brunet wrote:
> Please review the following.
>
> The .h files and .c file provided to allow Assistive Technology to
> interface to the Java Access Bridge API are being removed from
> the built
> JRE/JDK images.  They are not used much and they can be obtained
> online
> via the OpenJDK web site.  The pubs will be updated to mention the
> location of the files.
>
> Since there is a .c file in this group of files the directory
> structure
> has been changed slightly to remove the include directory.
>
> There was one file missing from the group of files needed by
> developers
> and that was moved from the common to the bridge directory.
>
> The make was updated in response to the above.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167213
>
> Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.00/
 Build changes looks good to me.

 /Magnus
>

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

[Pete Brunet]

On 10/26/16 10:44 PM, Philip Race wrote:
> >
>   15  href="http://hg.openjdk.java.net/jdk9/client/jdk/file/544828ab2a9b/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c";>
> That URL is definitely not authoritative.
>
> I think you need to give a pointer to something more like
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c
Looks like that hex number in there is the Mercurial long revision
number of the tip so that's going to keep changing.  I'm not aware of a
"latest" link.  Maybe some other reader will know.
>
> But I am not sure about that either .. it may need to be split between the 
> main URL and the location in the repo.
>
> -phil 
>
>
> On 10/26/16, 7:24 PM, Pete Brunet wrote:
>> Please review the latest update at
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/
>>
>> The change is to AccessBridgeCalls.c.  The license has been changed from
>> GPL2 to BSD.  This is because the file was originally unlicensed prior
>> to being bundled into the JDK and the compiled .obj is linked to by
>> vendors creating proprietary code.  Vendors will be instructed to
>> download AccessBridgeCalls.c from the OpenJDK repository.  Also the
>> include/use of AccessBridgeDebug.h/cpp has been removed.
>>
>> Please also review readme.html which has been added to
>> .../jdk/include/win32/bridge.
>>
>> Pete
>>
>> On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:
>>> The fix looks good to me.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>> On 10/24/2016 1:18 PM, Erik Joelsson wrote:
 The last change looks good and simple to me.

 /Erik


 On 2016-10-21 06:55, Pete Brunet wrote:
> Please see the latest update
> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/
>
> The fix now is to simply remove the copy of the AccessBridgeCalls.c
> file
> into the JDK.
>
> AccessBridgeCalls.c is the implementation of the documented Java Access
> Bridge API and is a set of wrapper functions that hides the
> complications related to interfacing to JAB's WindowsAccessBridge*.dll.
> In the past users of the API would compile and link to
> AccessBridgeCalls.c/obj.
>
> Since the interface implementation of AccessBridgeCalls.c will no
> longer
> be provided the JAB API documentation will be updated to instruct a
> user
> how to create an equivalent of AccessBridgeCalls.c.  The documentation
> will also contain a reference to the JAB 2.0.2 download
> http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html
>
> which does contain AccessBridgeCalls.c and which is compatible with the
> current API and related calls into WindowsAccessBridge*.dll.
>
> Pete
>
> On 10/18/16 12:28 PM, Pete Brunet wrote:
>> I've updated the webrev.  Please see
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/
>>
>> Rather than removing the files needed by Assistive Technology
>> developers
>> we have to provide them in JDK.  However since there is a .c file
>> in the
>> group of files the files were moved from the include directory to a
>> new
>> javaaccessbridge directory.
>>
>> On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:
>>> On 2016-10-14 17:51, Pete Brunet wrote:
 Please review the following.

 The .h files and .c file provided to allow Assistive Technology to
 interface to the Java Access Bridge API are being removed from
 the built
 JRE/JDK images.  They are not used much and they can be obtained
 online
 via the OpenJDK web site.  The pubs will be updated to mention the
 location of the files.

 Since there is a .c file in this group of files the directory
 structure
 has been changed slightly to remove the include directory.

 There was one file missing from the group of files needed by
 developers
 and that was moved from the common to the bridge directory.

 The make was updated in response to the above.

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

 Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.00/
>>> Build changes looks good to me.
>>>
>>> /Magnus

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

[Philip Race]

>

  15http://hg.openjdk.java.net/jdk9/client/jdk/file/544828ab2a9b/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c";>
That URL is definitely not authoritative.

I think you need to give a pointer to something more like
http://hg.openjdk.java.net/jdk9/jdk9/jdk/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c

But I am not sure about that either .. it may need to be split between the main 
URL and the location in the repo.

-phil



On 10/26/16, 7:24 PM, Pete Brunet wrote:

Please review the latest update at
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/

The change is to AccessBridgeCalls.c.  The license has been changed from
GPL2 to BSD.  This is because the file was originally unlicensed prior
to being bundled into the JDK and the compiled .obj is linked to by
vendors creating proprietary code.  Vendors will be instructed to
download AccessBridgeCalls.c from the OpenJDK repository.  Also the
include/use of AccessBridgeDebug.h/cpp has been removed.

Please also review readme.html which has been added to
.../jdk/include/win32/bridge.

Pete

On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:

The fix looks good to me.

Thanks,
Alexandr.

On 10/24/2016 1:18 PM, Erik Joelsson wrote:

The last change looks good and simple to me.

/Erik


On 2016-10-21 06:55, Pete Brunet wrote:

Please see the latest update
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/

The fix now is to simply remove the copy of the AccessBridgeCalls.c
file
into the JDK.

AccessBridgeCalls.c is the implementation of the documented Java Access
Bridge API and is a set of wrapper functions that hides the
complications related to interfacing to JAB's WindowsAccessBridge*.dll.
In the past users of the API would compile and link to
AccessBridgeCalls.c/obj.

Since the interface implementation of AccessBridgeCalls.c will no
longer
be provided the JAB API documentation will be updated to instruct a
user
how to create an equivalent of AccessBridgeCalls.c.  The documentation
will also contain a reference to the JAB 2.0.2 download
http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html

which does contain AccessBridgeCalls.c and which is compatible with the
current API and related calls into WindowsAccessBridge*.dll.

Pete

On 10/18/16 12:28 PM, Pete Brunet wrote:

I've updated the webrev.  Please see
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/

Rather than removing the files needed by Assistive Technology
developers
we have to provide them in JDK.  However since there is a .c file
in the
group of files the files were moved from the include directory to a
new
javaaccessbridge directory.

On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:

On 2016-10-14 17:51, Pete Brunet wrote:

Please review the following.

The .h files and .c file provided to allow Assistive Technology to
interface to the Java Access Bridge API are being removed from
the built
JRE/JDK images.  They are not used much and they can be obtained
online
via the OpenJDK web site.  The pubs will be updated to mention the
location of the files.

Since there is a .c file in this group of files the directory
structure
has been changed slightly to remove the include directory.

There was one file missing from the group of files needed by
developers
and that was moved from the common to the bridge directory.

The make was updated in response to the above.

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

Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.00/

Build changes looks good to me.

/Magnus

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

[Pete Brunet]

Please review the latest update at
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/

The change is to AccessBridgeCalls.c.  The license has been changed from
GPL2 to BSD.  This is because the file was originally unlicensed prior
to being bundled into the JDK and the compiled .obj is linked to by
vendors creating proprietary code.  Vendors will be instructed to
download AccessBridgeCalls.c from the OpenJDK repository.  Also the
include/use of AccessBridgeDebug.h/cpp has been removed.

Please also review readme.html which has been added to
.../jdk/include/win32/bridge.

Pete

On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:
>
> The fix looks good to me.
>
> Thanks,
> Alexandr.
>
> On 10/24/2016 1:18 PM, Erik Joelsson wrote:
>> The last change looks good and simple to me.
>>
>> /Erik
>>
>>
>> On 2016-10-21 06:55, Pete Brunet wrote:
>>> Please see the latest update
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/
>>>
>>> The fix now is to simply remove the copy of the AccessBridgeCalls.c
>>> file
>>> into the JDK.
>>>
>>> AccessBridgeCalls.c is the implementation of the documented Java Access
>>> Bridge API and is a set of wrapper functions that hides the
>>> complications related to interfacing to JAB's WindowsAccessBridge*.dll.
>>> In the past users of the API would compile and link to
>>> AccessBridgeCalls.c/obj.
>>>
>>> Since the interface implementation of AccessBridgeCalls.c will no
>>> longer
>>> be provided the JAB API documentation will be updated to instruct a
>>> user
>>> how to create an equivalent of AccessBridgeCalls.c.  The documentation
>>> will also contain a reference to the JAB 2.0.2 download
>>> http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html
>>>
>>> which does contain AccessBridgeCalls.c and which is compatible with the
>>> current API and related calls into WindowsAccessBridge*.dll.
>>>
>>> Pete
>>>
>>> On 10/18/16 12:28 PM, Pete Brunet wrote:
 I've updated the webrev.  Please see
 http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/

 Rather than removing the files needed by Assistive Technology
 developers
 we have to provide them in JDK.  However since there is a .c file
 in the
 group of files the files were moved from the include directory to a
 new
 javaaccessbridge directory.

 On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:
> On 2016-10-14 17:51, Pete Brunet wrote:
>> Please review the following.
>>
>> The .h files and .c file provided to allow Assistive Technology to
>> interface to the Java Access Bridge API are being removed from
>> the built
>> JRE/JDK images.  They are not used much and they can be obtained
>> online
>> via the OpenJDK web site.  The pubs will be updated to mention the
>> location of the files.
>>
>> Since there is a .c file in this group of files the directory
>> structure
>> has been changed slightly to remove the include directory.
>>
>> There was one file missing from the group of files needed by
>> developers
>> and that was moved from the common to the bridge directory.
>>
>> The make was updated in response to the above.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167213
>>
>> Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.00/
> Build changes looks good to me.
>
> /Magnus
>>
>

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] RFR JDK-8168657: [PIT] Still, on Windows test always fails: java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java

[Philip Race]

Are you sure about that ? I can't think why it would not work on Solaris 
just as it works everywhere else.


And when I run 'java -help' on Solaris it lists the option :-
-splash:
  show splash screen with specified image

-phil.

On 10/26/16, 8:27 AM, Prasanta Sadhukhan wrote:

No, as I understand splashscreen support is not there for solaris.

Regards
Prasanta
On 10/26/2016 8:55 PM, Sergey Bylokhov wrote:

Should this test work on Solaris as well?

On 26.10.16 10:19, Prasanta Sadhukhan wrote:

Hi All,

Please review a simple fix for splasscreen testissue where we need to
restrict this test from running on linux as this test uses linux
enviroment variable GDK_SCALE so
restricting to run only on linux.

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

diff -r aae3690e53e3
test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 



---
a/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 


Thu Oct 20 14:21:46 2016 +0300
+++
b/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 


Wed Oct 26 12:46:56 2016 +0530
@@ -47,6 +47,7 @@
  * @test @bug 8145174 8151787
  * @summary HiDPI splash screen support on Linux
  * @modules java.desktop/sun.java2d
+ * @requires (os.family == "linux")
  * @run main UnixMultiResolutionSplashTest
  */
 public class UnixMultiResolutionSplashTest {


Regards
Prasanta

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] RFR JDK-8168657: [PIT] Still, on Windows test always fails: java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java

[Prasanta Sadhukhan]

No, as I understand splashscreen support is not there for solaris.

Regards
Prasanta
On 10/26/2016 8:55 PM, Sergey Bylokhov wrote:

Should this test work on Solaris as well?

On 26.10.16 10:19, Prasanta Sadhukhan wrote:

Hi All,

Please review a simple fix for splasscreen testissue where we need to
restrict this test from running on linux as this test uses linux
enviroment variable GDK_SCALE so
restricting to run only on linux.

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

diff -r aae3690e53e3
test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 



---
a/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 


Thu Oct 20 14:21:46 2016 +0300
+++
b/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 


Wed Oct 26 12:46:56 2016 +0530
@@ -47,6 +47,7 @@
  * @test @bug 8145174 8151787
  * @summary HiDPI splash screen support on Linux
  * @modules java.desktop/sun.java2d
+ * @requires (os.family == "linux")
  * @run main UnixMultiResolutionSplashTest
  */
 public class UnixMultiResolutionSplashTest {


Regards
Prasanta

Re: [9] RFR JDK-8168657: [PIT] Still, on Windows test always fails: java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java

[Sergey Bylokhov]

Should this test work on Solaris as well?

On 26.10.16 10:19, Prasanta Sadhukhan wrote:

Hi All,

Please review a simple fix for splasscreen testissue where we need to
restrict this test from running on linux as this test uses linux
enviroment variable GDK_SCALE so
restricting to run only on linux.

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

diff -r aae3690e53e3
test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java

---
a/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java
Thu Oct 20 14:21:46 2016 +0300
+++
b/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java
Wed Oct 26 12:46:56 2016 +0530
@@ -47,6 +47,7 @@
  * @test @bug 8145174 8151787
  * @summary HiDPI splash screen support on Linux
  * @modules java.desktop/sun.java2d
+ * @requires (os.family == "linux")
  * @run main UnixMultiResolutionSplashTest
  */
 public class UnixMultiResolutionSplashTest {


Regards
Prasanta



--
Best regards, Sergey.

Re: [9] RFR JDK-8168657: [PIT] Still, on Windows test always fails: java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java

[Rajeev Chamyal]

Looks good to me.

Regards,
Rajeev Chamyal

-Original Message-
From: Prasanta Sadhukhan 
Sent: 26 October 2016 12:54
To: Rajeev Chamyal; Alexandr Scherbatiy; swing-dev@openjdk.java.net
Subject: Re:  [9] RFR JDK-8168657: [PIT] Still, on Windows test 
always fails: 
java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java

Please review this.

diff -r aae3690e53e3
test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java
---
a/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java
Thu Oct 20 14:21:46 2016 +0300
+++ 
b/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java
Wed Oct 26 12:53:21 2016 +0530
@@ -44,9 +44,11 @@
  import javax.imageio.ImageIO;

  /**
- * @test @bug 8145174 8151787
+ * @test
+ * @bug 8145174 8151787 8168657
   * @summary HiDPI splash screen support on Linux
   * @modules java.desktop/sun.java2d
+ * @requires (os.family == "linux")
   * @run main UnixMultiResolutionSplashTest
   */
  public class UnixMultiResolutionSplashTest {

Regards
Prasanta
On 10/26/2016 12:49 PM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a simple fix for splasscreen testissue where we need to 
> restrict this test from running on linux as this test uses linux 
> enviroment variable GDK_SCALE so restricting to run only on linux.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8168657
>
> diff -r aae3690e53e3
> test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolut
> ionSplashTest.java
> ---
> a/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResol
> utionSplashTest.java
> Thu Oct 20 14:21:46 2016 +0300
> +++ 
> b/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResol
> utionSplashTest.java
> Wed Oct 26 12:46:56 2016 +0530
> @@ -47,6 +47,7 @@
>   * @test @bug 8145174 8151787
>   * @summary HiDPI splash screen support on Linux
>   * @modules java.desktop/sun.java2d
> + * @requires (os.family == "linux")
>   * @run main UnixMultiResolutionSplashTest
>   */
>  public class UnixMultiResolutionSplashTest {
>
>
> Regards
> Prasanta

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

[9] RFR JDK-8048702: Deprecate obsolete classes in javax/swing/plaf/metal/MetalFileChooserUI.java

[Prasanta Sadhukhan]

Hi All,

Please review a fix for the issue where this obsolete class needs to be 
deprecated:


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

diff -r aae3690e53e3 
src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java
--- 
a/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java 
Thu Oct 20 14:21:46 2016 +0300
+++ 
b/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java 
Wed Oct 26 12:56:48 2016 +0530

@@ -570,8 +570,9 @@
 }

 /**
- * Obsolete class, not used in this version.
+ * Obsolete class, not used in this version. deprecated as of JDK 
version 9.

  */
+@Deprecated
 protected class SingleClickListener extends MouseAdapter {
 /**
  * Constructs an instance of {@code SingleClickListener}.
@@ -583,8 +584,9 @@
 }

 /**
- * Obsolete class, not used in this version.
+ * Obsolete class, not used in this version. deprecated as of JDK 
version 9.

  */
+@Deprecated
 @SuppressWarnings("serial") // Superclass is not serializable 
across versions

 protected class FileRenderer extends DefaultListCellRenderer  {
 }

Regards
Prasanta

Re: [9] RFR JDK-8168657: [PIT] Still, on Windows test always fails: java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java

[Prasanta Sadhukhan]

Please review this.

diff -r aae3690e53e3 
test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java
--- 
a/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 
Thu Oct 20 14:21:46 2016 +0300
+++ 
b/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 
Wed Oct 26 12:53:21 2016 +0530

@@ -44,9 +44,11 @@
 import javax.imageio.ImageIO;

 /**
- * @test @bug 8145174 8151787
+ * @test
+ * @bug 8145174 8151787 8168657
  * @summary HiDPI splash screen support on Linux
  * @modules java.desktop/sun.java2d
+ * @requires (os.family == "linux")
  * @run main UnixMultiResolutionSplashTest
  */
 public class UnixMultiResolutionSplashTest {

Regards
Prasanta
On 10/26/2016 12:49 PM, Prasanta Sadhukhan wrote:

Hi All,

Please review a simple fix for splasscreen testissue where we need to 
restrict this test from running on linux as this test uses linux 
enviroment variable GDK_SCALE so

restricting to run only on linux.

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

diff -r aae3690e53e3 
test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java
--- 
a/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 
Thu Oct 20 14:21:46 2016 +0300
+++ 
b/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 
Wed Oct 26 12:46:56 2016 +0530

@@ -47,6 +47,7 @@
  * @test @bug 8145174 8151787
  * @summary HiDPI splash screen support on Linux
  * @modules java.desktop/sun.java2d
+ * @requires (os.family == "linux")
  * @run main UnixMultiResolutionSplashTest
  */
 public class UnixMultiResolutionSplashTest {


Regards
Prasanta

[9] RFR JDK-8168657: [PIT] Still, on Windows test always fails: java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java

[Prasanta Sadhukhan]

Hi All,

Please review a simple fix for splasscreen testissue where we need to 
restrict this test from running on linux as this test uses linux 
enviroment variable GDK_SCALE so

restricting to run only on linux.

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

diff -r aae3690e53e3 
test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java
--- 
a/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 
Thu Oct 20 14:21:46 2016 +0300
+++ 
b/test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 
Wed Oct 26 12:46:56 2016 +0530

@@ -47,6 +47,7 @@
  * @test @bug 8145174 8151787
  * @summary HiDPI splash screen support on Linux
  * @modules java.desktop/sun.java2d
+ * @requires (os.family == "linux")
  * @run main UnixMultiResolutionSplashTest
  */
 public class UnixMultiResolutionSplashTest {


Regards
Prasanta

8168540: [TEST_BUG] On Unity, need a delay before screenshot taking to avoid animation

[Avik Niyogi]

Hi All,

Kindly review the proposed fix for JDK9.

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


Webrev: http://cr.openjdk.java.net/~aniyogi/8168540/webrev.00/ 


Issue: Animation before screen capture causes mismatch.

Cause: Delay before screen capture albeit provided is not enough

Fix: Delay provided to test case

With Regards,
Avik Niyogi