Re: [OpenJDK 2D-Dev] [12] RFR(XS) JDK-8214817: Bad links in ImageInputStream.java & ImageOutputStream.java

2018-12-10 Thread Prasanta Sadhukhan 

+1

Regards
Prasanta
On 07-Dec-18 2:52 PM, Jayathirth D V wrote:

Hi Alexey,

Thanks for the review.
I will add space before pushing the change.

Regards,
Jay

-Original Message-
From: Alexey Ivanov
Sent: Thursday, December 06, 2018 12:45 AM
To: Jayathirth D V; 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [12] RFR(XS) JDK-8214817: Bad links in 
ImageInputStream.java & ImageOutputStream.java

Hi Jay,

"modified UTF-8" had space before but it doesn't.

Otherwise, looks good.

Regards,
Alexey

On 05/12/2018 12:35, Jayathirth D V wrote:

Hello All,

Please review the following fix in JDK12:

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

Webrev : http://cr.openjdk.java.net/~jdv/8214817/webrev.00/

Thanks,

Jay

Re: [OpenJDK 2D-Dev] [12] RFR(XS) JDK-8214876: Add "intermittent" key for imageio/stream/StreamCloserLeak/run_test.sh

2018-12-10 Thread Prasanta Sadhukhan 

+1

Regards
Prasanta
On 05-Dec-18 6:49 PM, Jayathirth D V wrote:


Hello All,

Please review the following fix in JDK12:

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

Webrev : http://cr.openjdk.java.net/~jdv/8214876/webrev.00/ 



I have not added JBS bug id under @bug since it is a trivial test change.

Thanks,

Jay

Re: [OpenJDK 2D-Dev] [12] JDK-8212202: NPE in the print tests after JDK-8153732

2018-12-10 Thread Shashidhara Veerabhadraiah 
Hi Phil, Please find the updated Webrev.

 

http://cr.openjdk.java.net/~sveerabhadra/8212202/webrev.03/

 

Thanks and regards,

Shashi

 

From: Philip Race 
Sent: Friday, December 7, 2018 8:54 PM
To: Shashidhara Veerabhadraiah 
Cc: Prasanta Sadhukhan ; 2d-dev@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] [12] JDK-8212202: NPE in the print tests after 
JDK-8153732

 

First off, I think the high order bit is that if a non-null array reference is 
returned there are NO
null String entries in it. Whether a zero length or null array is returned when 
there are no printers
is the less important issue.

However an empty array also tells you there are no printers, and you are less 
likely to get an NPE from that.
It is arguably easier for the caller, if they don't need the extra null check 
first.
FWIW the javax.print public APIs return zero length arrays instead of null and 
applications seem to survive :-)

I don't know what you mean by :
> (And anyway we need to handle the first null string reference)?

If you are referring to a small matter of coding in the native layer, then that 
is not an insurmountable problem.

Basically if there are problems getting names or whatever in the native layer, 
handle it THERE, don't make
everyone else have to deal with it.

One caveat: JNI calls can theoretically fail due to OOME .. in such a case we 
are doomed and
the main goal is to not crash in native and to obey all JNI rules. What is 
returned in that case
can be a null array reference and an NPE in a Java-level user of that reference 
in such a case is not a big deal.

-phil

On 12/6/18, 8:10 PM, Shashidhara Veerabhadraiah wrote: 

Hi Phil, Is it advisable to return zero length array from native? The null 
return from native is telling the caller that there are no printers connected 
to the system. To tell this should we allocate a zero length array containing 
null back to the caller(And anyway we need to handle the first null string 
reference)? Handling the null on the caller isn't an easier option?

 

Thanks and regards,

Shashi

 

From: Phil Race 
Sent: Thursday, December 6, 2018 2:35 AM
To: Shashidhara Veerabhadraiah HYPERLINK 
"mailto:shashidhara.veerabhadra...@oracle.com";;
 Prasanta Sadhukhan HYPERLINK 
"mailto:prasanta.sadhuk...@oracle.com";; 
HYPERLINK "mailto:2d-dev@openjdk.java.net"2d-dev@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] [12] JDK-8212202: NPE in the print tests after 
JDK-8153732

 

But what I am saying is we should not return a NULL string reference
from native. You are still allowing that and then having to handle
it in Java code.

And FWIW you can return a zero length array as well so there
isn't a NULL array reference to deal with either.

-phil.

On 12/3/18 8:29 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, There were 2 problems earlier. One is that, from the native it is 
possible to have no printers being associated with the system(causing to return 
null reference) and other problem in the implementation was that there may be 
no network printers and still return a valid array reference containing a null 
string. The first problem is fixed by handling null references returned from 
this function and other problem was that earlier there were different base 
conditions, for updating the reference and use it to create the printer name 
array which could produce a valid reference pointing to null string. Here is 
the updated Webrev which fixes these problems:

 

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

 

The big problem was that I was not able to reproduce this problem neither at my 
end nor at the systems used for PIT testing. Only Sergey had produced this NPE 
till now.

 

Thanks and regards,

Shashi

 

From: Phil Race 
Sent: Wednesday, November 28, 2018 11:19 PM
To: Shashidhara Veerabhadraiah HYPERLINK 
"mailto:shashidhara.veerabhadra...@oracle.com";;
 Prasanta Sadhukhan HYPERLINK 
"mailto:prasanta.sadhuk...@oracle.com";; 
HYPERLINK "mailto:2d-dev@openjdk.java.net"2d-dev@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] [12] JDK-8212202: NPE in the print tests after 
JDK-8153732

 

I am not understanding you. I thought the problem to be we got an array of 
(say) 3 values
(ie printer names) returned from native where some or all of the *values* were 
NULL.
And I am saying we should in such a case in the native code, before returning,
remove from the returned array all values that are NULL.
That could result in an empty (zero length) array being returned from native but
no null names .. 

-phil.

On 11/26/18 10:23 PM, Shashidhara Veerabhadraiah wrote:

The windows function EnumPrinters() returns a value that could be zero or 
greater. If it is zero we have no other option but to return null from the 
function. I do not think there is a way where we can always make sure we get a 
non-zero value considering the various system scenarios. So we should handle 
the null return values as we

Re: [OpenJDK 2D-Dev] [12] JDK-8212202: NPE in the print tests after JDK-8153732

2018-12-10 Thread Shashidhara Veerabhadraiah 
Hi Phil, I have updated with small code updates:

http://cr.openjdk.java.net/~sveerabhadra/8212202/webrev.04/

 

Thanks and regards,

Shashi

 

From: Shashidhara Veerabhadraiah 
Sent: Monday, December 10, 2018 3:19 PM
To: Philip Race 
Cc: Prasanta Sadhukhan ; 2d-dev@openjdk.java.net
Subject: RE: [OpenJDK 2D-Dev] [12] JDK-8212202: NPE in the print tests after 
JDK-8153732

 

Hi Phil, Please find the updated Webrev.

 

http://cr.openjdk.java.net/~sveerabhadra/8212202/webrev.03/

 

Thanks and regards,

Shashi

 

From: Philip Race 
Sent: Friday, December 7, 2018 8:54 PM
To: Shashidhara Veerabhadraiah mailto:shashidhara.veerabhadra...@oracle.com"shashidhara.veerabhadra...@oracle.com>
Cc: Prasanta Sadhukhan mailto:prasanta.sadhuk...@oracle.com"prasanta.sadhuk...@oracle.com>; HYPERLINK 
"mailto:2d-dev@openjdk.java.net"2d-dev@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] [12] JDK-8212202: NPE in the print tests after 
JDK-8153732

 

First off, I think the high order bit is that if a non-null array reference is 
returned there are NO
null String entries in it. Whether a zero length or null array is returned when 
there are no printers
is the less important issue.

However an empty array also tells you there are no printers, and you are less 
likely to get an NPE from that.
It is arguably easier for the caller, if they don't need the extra null check 
first.
FWIW the javax.print public APIs return zero length arrays instead of null and 
applications seem to survive :-)

I don't know what you mean by :
> (And anyway we need to handle the first null string reference)?

If you are referring to a small matter of coding in the native layer, then that 
is not an insurmountable problem.

Basically if there are problems getting names or whatever in the native layer, 
handle it THERE, don't make
everyone else have to deal with it.

One caveat: JNI calls can theoretically fail due to OOME .. in such a case we 
are doomed and
the main goal is to not crash in native and to obey all JNI rules. What is 
returned in that case
can be a null array reference and an NPE in a Java-level user of that reference 
in such a case is not a big deal.

-phil

On 12/6/18, 8:10 PM, Shashidhara Veerabhadraiah wrote: 

Hi Phil, Is it advisable to return zero length array from native? The null 
return from native is telling the caller that there are no printers connected 
to the system. To tell this should we allocate a zero length array containing 
null back to the caller(And anyway we need to handle the first null string 
reference)? Handling the null on the caller isn't an easier option?

 

Thanks and regards,

Shashi

 

From: Phil Race 
Sent: Thursday, December 6, 2018 2:35 AM
To: Shashidhara Veerabhadraiah HYPERLINK 
"mailto:shashidhara.veerabhadra...@oracle.com";;
 Prasanta Sadhukhan HYPERLINK 
"mailto:prasanta.sadhuk...@oracle.com";; 
HYPERLINK "mailto:2d-dev@openjdk.java.net"2d-dev@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] [12] JDK-8212202: NPE in the print tests after 
JDK-8153732

 

But what I am saying is we should not return a NULL string reference
from native. You are still allowing that and then having to handle
it in Java code.

And FWIW you can return a zero length array as well so there
isn't a NULL array reference to deal with either.

-phil.

On 12/3/18 8:29 AM, Shashidhara Veerabhadraiah wrote:

Hi Phil, There were 2 problems earlier. One is that, from the native it is 
possible to have no printers being associated with the system(causing to return 
null reference) and other problem in the implementation was that there may be 
no network printers and still return a valid array reference containing a null 
string. The first problem is fixed by handling null references returned from 
this function and other problem was that earlier there were different base 
conditions, for updating the reference and use it to create the printer name 
array which could produce a valid reference pointing to null string. Here is 
the updated Webrev which fixes these problems:

 

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

 

The big problem was that I was not able to reproduce this problem neither at my 
end nor at the systems used for PIT testing. Only Sergey had produced this NPE 
till now.

 

Thanks and regards,

Shashi

 

From: Phil Race 
Sent: Wednesday, November 28, 2018 11:19 PM
To: Shashidhara Veerabhadraiah HYPERLINK 
"mailto:shashidhara.veerabhadra...@oracle.com";;
 Prasanta Sadhukhan HYPERLINK 
"mailto:prasanta.sadhuk...@oracle.com";; 
HYPERLINK "mailto:2d-dev@openjdk.java.net"2d-dev@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] [12] JDK-8212202: NPE in the print tests after 
JDK-8153732

 

I am not understanding you. I thought the problem to be we got an array of 
(say) 3 values
(ie printer names) returned from native where some or all of the *values* were 
NULL.
And I am saying we should in such a case in the native code, befo