Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2017-02-13 Thread Alan Bateman
On 14/02/2017 07:36, Volker Simonis wrote: : Finally somebody who understands me :) As this seems a very controversial topic, I'll wait for a second positive review before I'll push this. If you are going to push this change then best to do it with another JIRA issue as JDK-8033909 is a

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2017-02-13 Thread Volker Simonis
On Tue, Feb 14, 2017 at 12:56 AM, David Holmes wrote: > On 14/02/2017 2:57 AM, Alan Bateman wrote: >> >> On 09/02/2017 16:18, Volker Simonis wrote: >> >>> : >>> >>> I really think that the simplest and most natural fix for this problem >>> is to simply check for a null

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2017-02-13 Thread David Holmes
On 14/02/2017 2:57 AM, Alan Bateman wrote: On 09/02/2017 16:18, Volker Simonis wrote: : I really think that the simplest and most natural fix for this problem is to simply check for a null Supplier argument and create the NPE with an explicit null message in that case (as outlined in the

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2017-02-13 Thread David Holmes
On 13/02/2017 7:10 PM, Volker Simonis wrote: On Mon, Feb 13, 2017 at 9:27 AM, David Holmes wrote: FWIW I think a null Supplier should simply be ignored. What do you mean by ignored? Do you mean "ignored" in the sense of my proposed changes (i.e. throw a NPE with a

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2017-02-13 Thread Alan Bateman
On 09/02/2017 16:18, Volker Simonis wrote: : I really think that the simplest and most natural fix for this problem is to simply check for a null Supplier argument and create the NPE with an explicit null message in that case (as outlined in the webrev). This: - makes the two requireNonNul()

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2017-02-13 Thread Volker Simonis
On Mon, Feb 13, 2017 at 9:27 AM, David Holmes wrote: > FWIW I think a null Supplier should simply be ignored. > What do you mean by ignored? Do you mean "ignored" in the sense of my proposed changes (i.e. throw a NPE with a a null message) or do you mean "ignored" in

RE: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2017-02-13 Thread Langer, Christoph
Hi > FWIW I think a null Supplier should simply be ignored. ...which is what Volker's change does. After reading through all the discussion, I'm pro adding the null check as proposed in Volker's webrev. Best regards Christoph > On 13/02/2017 6:04 PM, Volker Simonis wrote: > > Ping... > > > >

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2017-02-13 Thread David Holmes
FWIW I think a null Supplier should simply be ignored. David On 13/02/2017 6:04 PM, Volker Simonis wrote: Ping... On Thu, Feb 9, 2017 at 5:32 PM, Jeff Dinkins wrote: Adding Mike’s current email. -jeff On Feb 9, 2017, at 10:18 AM, Volker Simonis

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2017-02-13 Thread Volker Simonis
Ping... On Thu, Feb 9, 2017 at 5:32 PM, Jeff Dinkins wrote: > > Adding Mike’s current email. > > -jeff > >> On Feb 9, 2017, at 10:18 AM, Volker Simonis wrote: >> >> Hi, >> >> I want to finally resolve this long standing issue (or close it as >>

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2017-02-09 Thread Jeff Dinkins
Adding Mike’s current email. -jeff > On Feb 9, 2017, at 10:18 AM, Volker Simonis wrote: > > Hi, > > I want to finally resolve this long standing issue (or close it as > "will not fix" if that's not possible): > >

RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2017-02-09 Thread Volker Simonis
Hi, I want to finally resolve this long standing issue (or close it as "will not fix" if that's not possible): http://cr.openjdk.java.net/~simonis/webrevs/2017/8033909/ This change has already been discussed in length on the mailing list:

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2014-02-11 Thread Volker Simonis
Hi Mike, as described in the bug comments, I still think that correctly handling a null Supplier is the cleanest and easiest solution. Without the change our VM will throw the following NPE: java.lang.NullPointerException: while trying to invoke the method java.util.function.Supplier.get() of a

RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2014-02-10 Thread Volker Simonis
Hi, could you please review the following tiny change which fixes a problem in Objects.requireNonNull: http://cr.openjdk.java.net/~simonis/webrevs/8033909/ https://bugs.openjdk.java.net/browse/JDK-8033909 The problem is that Objects.requireNonNull(T, Supplier) does not check for the Supplier

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

2014-02-10 Thread Mike Duigou
I would prefer to leave the implementation as is and amend the documentation. The difference in behaviour between the overloads seems OK since it will still be valid for the Supplier to return null. The String overload reasonably allows null since the Throwable(String) constructor allows null