(had only run the java/lang/invoke tests
>> locally). An alternative approach here is to verify all methods already
>> implicitly check null and remove all these, but being explicit is nice and
>> reduces possibility of surprise.
>
> I found few more similar places
ng explicit is nice and reduces
> possibility of surprise.
I found few more similar places in JFR code, where `Objects.nonNull` is used
incorrectly.
jdk.jfr.internal.consumer.AbstractEventStream#setStartTime
jdk.jfr.consumer.EventStream#openRepository(java.nio.file.Path)
jdk.jfr.Recording#setFlushInterval
-
PR: https://git.openjdk.java.net/jdk/pull/2914
14 mod
8263380: Unintended use of Objects.nonNull in VarHandles
Reviewed-by: rriggs
-
PR: https://git.openjdk.java.net/jdk/pull/2914
On Wed, 10 Mar 2021 16:04:59 GMT, Jorn Vernee wrote:
> Nice catch!
>
> We have a test that is supposed to test this:
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java
> But it is only checking if an NPE is thrown, and not checking for a message,
> since
On Wed, 10 Mar 2021 16:04:22 GMT, Roger Riggs wrote:
>> Use requireNonNull instead.
>
> Well spotted.
Nice catch!
We have a test that is supposed to test this:
https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java
But it is only checking if an NPE is thrown, and not
On Wed, 10 Mar 2021 15:33:43 GMT, Claes Redestad wrote:
> Use requireNonNull instead.
Well spotted.
-
Marked as reviewed by rriggs (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2914
Use requireNonNull instead.
-
Commit messages:
- Unintended use of Objects.nonNull in VarHandles
Changes: https://git.openjdk.java.net/jdk/pull/2914/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2914=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8263380
Stats
I am sympathetic to this naming issue (actually indifferent is more accurate)
but it will have to wait until I return from vacation. I have tagged this
thread and will follow up when I am back in the office. Please be patient, it
will be addressed.
Mike
On Jun 20 2013, at 07:10 , Remi Forax
Really depends about whether you want the method to be bad English, or really
bad English. :-). All this double negativity gets me down. What's wrong with
exists() ?
Sent from my iPhone
On 20 Jun 2013, at 08:24, Howard Lovatt howard.lov...@gmail.com wrote:
I would say not needed, !isNull()
I would say not needed, !isNull() is sufficient. If included isNotNull() is
the better name.
On 5 May 2013 01:09, Ulf Zibis ulf.zi...@cosoco.de wrote:
Am 04.05.2013 04:28, schrieb Mike Duigou:
I have updated the webrev to include incorporate the feedback I have
received.
Like others, I would prefer isNotNull() to notNull(). Mainly for
consistency, but also for dicoverability is IDE autocomplete (as the
methods would then be next to one another)
Stephen
On 30 April 2013 23:45, Mike Duigou mike.dui...@oracle.com wrote:
Hello all;
Another changeset coming from
Yes, a fine idea.
Rémi
On 06/20/2013 11:44 AM, Stephen Colebourne wrote:
Like others, I would prefer isNotNull() to notNull(). Mainly for
consistency, but also for dicoverability is IDE autocomplete (as the
methods would then be next to one another)
Stephen
On 30 April 2013 23:45, Mike
Am 04.05.2013 04:28, schrieb Mike Duigou:
I have updated the webrev to include incorporate the feedback I have received.
http://cr.openjdk.java.net/~mduigou/JDK-8013712/1/webrev/
Regarding the naming of the nonNull method. I originally added this method in 2011 but I've forgotten since
then
I have updated the webrev to include incorporate the feedback I have received.
http://cr.openjdk.java.net/~mduigou/JDK-8013712/1/webrev/
Regarding the naming of the nonNull method. I originally added this method in
2011 but I've forgotten since then why it has the name it does. As best as I
Hello.
nonNull could be renamed into isNonNull,
else people might use it instead of requireNonNull,
especially if they are already used to a pre-Java 7
requireNonNull that would be called nonNull.
(example:
Hello all;
Another changeset coming from the lambda libraries effort. This one is two
small additions to the Objects class. The introduced methods are not really
intended to be used directly, comparison operators work better in imperative
logic, but the methods will be very useful as
On 4/30/2013 3:45 PM, Mike Duigou wrote:
Hello all;
Another changeset coming from the lambda libraries effort. This one is two
small additions to the Objects class. The introduced methods are not really
intended to be used directly, comparison operators work better in imperative
logic, but
I will make both suggested changes.
Thank you.
Mike
On Apr 30 2013, at 20:34 , Mandy Chung wrote:
On 4/30/2013 3:45 PM, Mike Duigou wrote:
Hello all;
Another changeset coming from the lambda libraries effort. This one is two
small additions to the Objects class. The introduced methods
On 15/01/2011 12:30 a.m., Stephen Colebourne wrote:
snip
5) Now
*** If you are time-pressured, I'd recommend removing this method from v7. ***
A defaultIfNull method would be much more useful in this class:
public static Object defaultIfNull(Object object, Object defaultValue) {
On 17 January 2011 05:26, Brian Goetz brian.go...@oracle.com wrote:
My aversion to checkNonNull naming pattern comes from experience. Long,
long ago in a code base far, far away I wrote a big set of unit tests
using this pattern. Coming back to it months later I had to read the
code very
Date: Thu, 13 Jan 2011 19:52:27 -0500
From: brian.go...@oracle.com
Mark Reinhold wrote:
I'm still troubled by the check prefix, though. It implies that the
named condition will be tested but it doesn't clearly relate the result
of that test to the method's exception-throwing behavior.
I still don't like checkNonNull. It checks whether its argument is
non-null, but then what does it do? Throw an exception if it is
non-null? Throw an exception if it isn't? Do something else?
My aversion to checkNonNull naming pattern comes from experience. Long,
long ago in a code base
Hi all,
As a user the first name that came to mind was expect. Expect doesn't
imply a specific error signaling pattern, but it does imply that it is
an error if the condition is not as expected. Expect is only one letter
less than throwIf, but it doesn't include a capital letter.
expectNonNull:
There are a number of strands to this thread
1) Null useful or not.
There are arguments on both sides here, and developers are divided.
Personally, I use null every single day to use not known or not
required, such as in a search request:
/**
* The set of exchange object identifiers, null
Am 14.01.2011 12:30, schrieb Stephen Colebourne:
2) Other utilities
These are prior art that users are familiar with, just as much as the JDK.
Google Guava - Objects:
public staticT T firstNonNull(T first, T second)
why not? :
public static T T firstNonNull(T... values)
Commons Lang -
On 14/01/2011 11:30, Stephen Colebourne wrote:
These are prior art that users are familiar with, just as much as the JDK.
There is actually prior art in JSRs.
JSR 305: Annotations for Software Defect Detection
Used @Nonnull. In normal circumstances, we would expect this
annotation and
* and constructors, as demonstrated below:
* blockquotepre
* public Foo(Bar bar) {
* this.bar = Objects.nonNull(bar);
* }
* /pre/blockquote
*
* @param obj the object reference to check for nullity
* @param T the type of the reference
* @return {@code
On 13/01/2011 20:06, Brian Goetz wrote:
Most of the other methods in this class are of the form do the right
thing if the object is null (or an array), but this one is throw an
exception if the object is null. The intent is clear -- it is for
simplifying fail-fast behavior by checking for
Maybe you have a nonNull() that throws NPE, and a nonNullSafe() ?
On Thu, Jan 13, 2011 at 3:12 PM, Tom Hawtin tom.haw...@oracle.com wrote:
On 13/01/2011 20:06, Brian Goetz wrote:
Most of the other methods in this class are of the form do the right
thing if the object is null (or an array),
On 01/13/2011 11:11 PM, Brian Goetz wrote:
rathole
I disagree with Tom here. We have *already* made the billion dollar
mistake, and we can't eliminate that headache (but we can provide
easier access to aspirin.) Java developers are *constantly* writing
methods like the suggested
and
public staticT T nonNull(String obj) {
return (obj == null) ? : obj;
}
etc.
I don't know, this doesn't feel right to me. It would probably make more
sense to have a:
public static T T defaulted(T test, T defVal) {
return test == null ? defVal : test;
}
This would cover both of the above
Am 13.01.2011 23:31, schrieb Rémi Forax:
I think I prefer throwIfNull() which is explicit.
+1
-Ulf
On 01/13/2011 04:31 PM, Rémi Forax wrote:
On 01/13/2011 11:11 PM, Brian Goetz wrote:
rathole
I disagree with Tom here. We have *already* made the billion dollar
mistake, and we can't eliminate that headache (but we can provide
easier access to aspirin.) Java developers are *constantly* writing
Date: Thu, 13 Jan 2011 17:11:37 -0500
From: brian.go...@oracle.com
...
One last question for Mark on the ensureXxx() convention: methods like
ensureXxx() sometimes mean make this true (like ensureCapacity() in
collections implementations) rather than barf if it is not true.
Right.
Rémi Forax said the following on 01/14/11 08:31:
I think I prefer throwIfNull() which is explicit.
+1
As to what gets thrown, none of these suggestions make that obvious from
their name so I would not be concerned about that. Every Java programmer
is very early introduced to
On 01/13/2011 11:41 PM, David M. Lloyd wrote:
On 01/13/2011 04:31 PM, Rémi Forax wrote:
On 01/13/2011 11:11 PM, Brian Goetz wrote:
rathole
I disagree with Tom here. We have *already* made the billion dollar
mistake, and we can't eliminate that headache (but we can provide
easier access to
Am 13.01.2011 23:38, schrieb Brian Goetz:
People use these to simplify cases like
if (foo != null)
for (Foo f : foo) { ... }
to
for (Foo f : nonNull(foo)) { ... }
To be honest, I don't understand the real value of nonNull().
If the argument is null, NPE would be thrown anyway.
Do I
On 01/13/2011 05:36 PM, David Holmes wrote:
Brian Goetz said the following on 01/14/11 09:15:
to go either way (both checkNonNull and ensureNonNull better
match the actual behavior of the method than plain nonNull) but
we might as well pick the right convention.
Rémi's throwIfNull(x)
Date: Thu, 13 Jan 2011 18:15:30 -0500
From: brian.go...@oracle.com
...
Between checkNonNull() and throwIfNull(), I lean towards the former. In any
case the answer should be driven by what is more obvious to the reader.
Agreed.
On 01/14/2011 01:20 AM, mark.reinh...@oracle.com wrote:
Date: Thu, 13 Jan 2011 18:15:30 -0500
From: brian.go...@oracle.com
...
Between checkNonNull() and throwIfNull(), I lean towards the former. In any
case the answer should be driven by what is more obvious to the reader.
Agreed.
On Thu, Jan 13, 2011 at 7:06 PM, Brian Goetz brian.go...@oracle.com wrote:
For clarification only (we're not suggesting adding these NOW, but instead
preserving the option):
People constantly write methods like
public String nonNull(String s) { return s != null ? s : }
and other versions
I'm still troubled by the check prefix, though. It implies that the
named condition will be tested but it doesn't clearly relate the result
of that test to the method's exception-throwing behavior.
Here's an idea: Why not treat this as a (degenerate) kind of conversion
operation? Call it
wouldn't expect either style to be part of the core language.
From: Brian Goetz brian.go...@oracle.com
To: mark.reinh...@oracle.com
Cc: core-libs-dev@openjdk.java.net
Sent: Thu, January 13, 2011 4:52:27 PM
Subject: Re: Objects.nonNull()
I'm still troubled
@openjdk.java.net
*Sent:* Thu, January 13, 2011 4:52:27 PM
*Subject:* Re: Objects.nonNull()
I'm still troubled by the check prefix, though. It implies that the
named condition will be tested but it doesn't clearly relate the result
of that test to the method's exception-throwing behavior
On 13/01/2011 22:11, Brian Goetz wrote:
rathole
I disagree with Tom here. We have *already* made the billion dollar
mistake, and we can't eliminate that headache (but we can provide easier
access to aspirin.) Java developers are *constantly* writing methods
like the suggested carpet-sweeping
45 matches
Mail list logo
