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
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
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
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
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()
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
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...
> >
> >
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
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
>>
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):
>
>
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:
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
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
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
14 matches
Mail list logo