Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Stephen, see comments below - Mail original - > De: "Stephen Colebourne" <scolebou...@joda.org> > À: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Dimanche 1 Novembre 2015 22:46:21 > Objet: Re: RFR 9: 8138963 : java.lang.Objects

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 31 October 2015 at 20:29, Roger Riggs wrote: > And, going back nearly to the beginning of the thread, some folks are > familiar with > > T firstNonNull(T, T) proposed from Guava. > > But since the exercise was turned into simplify: (x != null) ? x : >

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 30, 2015, at 12:07 PM, Roger Riggs wrote: > > The longer names disambiguate adequately but add to the bulk of the code. > I see maturing systems end up being weighed down by the seemingly necessary > qualification. I agree with your statement of the problem, but

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

OK, it's Halloween, so a certain amount of bikeshed vandalism might be allowable. I will to select my spray-paint color from the following paint-store aisle: http://www.thesaurus.com/browse/deter There's something in there to charm everyone.

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi, And, going back nearly to the beginning of the thread, some folks are familiar with T firstNonNull(T, T) proposed from Guava. But since the exercise was turned into simplify: (x != null) ? x : requireNonNull(y); My favorite at this point is to identify the thread as a failed

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 31, 2015, at 4:17 AM, Remi Forax wrote: > > Hi John, > I think there is a good reason to not reuse/enhance the requireNonNull prefix, > requireNonNull here is used to check a precondition or an invariant (a > contract), hence a name that starts with 'require' like in

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

How about Objects.ifNull? Short and sweet. I don't like requireXXX for this semantic either. sent from my phone On Oct 31, 2015 3:45 PM, "John Rose" wrote: > On Oct 31, 2015, at 4:17 AM, Remi Forax wrote: > > > > Hi John, > > I think there is a good

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

It's hard to escape bikeshedding, everyone's subconsciously favorite pastime. :) To me, checkNull still means there's an error path somewhere there (I've seen plenty of internal validation/util APIs where check methods throw if arg is null). To me, we're saying "here's a method that returns

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

. - Mail original - > De: "John Rose" <john.r.r...@oracle.com> > À: "Roger Riggs" <roger.ri...@oracle.com> > Cc: core-libs-dev@openjdk.java.net > Envoyé: Samedi 31 Octobre 2015 08:01:03 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to def

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi John, Thanks for the followup. It is a subtle issue and seems to hinge on the relative priority of consistency in naming and the degree that historical artifacts ('mistakes') constrain contemporary patterns. If we were re-writing history: boolean nonNull(obj) could/should have been

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 9, 2015, at 8:46 AM, Roger Riggs wrote: > > The primary purpose of the existing 'requireNonNull' methods is to check for > null > and throw an exception. It is used for explicit testing and producing a > cogent exception. > Returning the value was a secondary

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 28, 2015, at 4:44 PM, John Rose wrote: > > As I said to you verbally, I'm not going to "die on this hill", but I do > think the name chosen has some disadvantages that could have been avoided > with a very slight mental shift about require. I.e.,

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 9 October 2015 at 01:31, John Rose wrote: > This leads me to yet another bikeshed color, FWIW: > > - T requireNonNull(T) (cf. Optional::get) > - T requireNonNullElse(T,T) (cf. Optional::orElse) > - T requireNonNullElseGet(T,Supplier) (cf. Optional::orElseGet) > - T

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

> On 9 Oct 2015, at 02:31, John Rose wrote: > > It may be instructive to link nulls to Optionals by encoding null-ness using > Optional: > > T nonNullElse(T x, T y) := Optional.ofNullable(x).orElseGet(() -> > Optional.ofNullable(y).get()) > And with the new

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi, The primary purpose of the existing 'requireNonNull' methods is to check for null and throw an exception. It is used for explicit testing and producing a cogent exception. Returning the value was a secondary benefit that allowed it to be used in fluent expressions. The purpose of the

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

The semantics of require* here was that it should throw if the precondition is violated. That lead to a different naming direction than the current use case, in which null is an expected value rather than an error. Sent from my iPhone > On Oct 9, 2015, at 11:58 AM, Stephen Colebourne

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Brian, On 09/10/15 13:41, Brian Goetz wrote: The semantics of require* here was that it should throw if the precondition is violated. That lead to a different naming direction than the current use case, in which null is an expected value rather than an error. Not necessarily - as the

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

My point, and Daniel's point, is that requireNonNull can be re-interpreted (ret-conned) as enforcing a post-condition instead of a pre-condition. (The logic of JDK 8 rNN allows either view equally.) Then all of these API points hang together very nicely. After I tinkered with the

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 7 Oct 2015, at 23:44, Stephen Colebourne wrote: > On 7 October 2015 at 23:24, Roger Riggs wrote: >> Please consider and comment: >> >> T nonNullOf(T obj, T defaultObj); >> T nonNullOf(T, obj, Supplier defaultSupplier); >> >> Details are

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

e-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Jeudi 8 Octobre 2015 00:24:26 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to > non-null > > Hi, > > The original intent was to simplify the filling in of default values >

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

orm the remark of Stephen, the code is Ok. cheers, Rémi - Mail original - De: "Roger Riggs" <roger.ri...@oracle.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Envoyé: Jeudi 8 Octobre 2015 00:24:26 Objet: Re: RFR 9: 8138963 : java.

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Ivan, It was there, for compile time, to confirm the type signature of the return value; the type checking on == isn't as strong as assignment. But it would not be needed more than once. Roger On 10/8/2015 12:13 PM, Ivan Gerasimov wrote: Hi Roger! In the test, why the 'result'

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 08.10.2015 19:33, Roger Riggs wrote: Hi Ivan, It was there, for compile time, to confirm the type signature of the return value; the type checking on == isn't as strong as assignment. Ah, Okay. Thanks for explanation! Sincerely yours, Ivan But it would not be needed more than once.

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

enjdk.java.net> *Envoyé: *Jeudi 8 Octobre 2015 16:44:54 *Objet: *Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null Hi Remi, On 10/8/2015 4:49 AM, Remi Forax wrote: Hi Roger, using overloads here seems to be a bad idea,

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

*"core-libs-dev" <core-libs-dev@openjdk.java.net> *Envoyé: *Jeudi 8 Octobre 2015 21:09:26 *Objet: *Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null So for you, method overloading is a mis-feature of the language because it inhibits reada

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 8, 2015, at 12:34 PM, fo...@univ-mlv.fr wrote: > > Anyway, in this case the problem is not just overloading, it is the mix of > overloading and type inference as you said. Add type erasure to this cocktail, and it's perfect. My antennae go up when the erased types overlap. When they

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi John, Thanks for the insight, I hope it will help cut down on the thrashing. Isn't there a 4th form that throws missing? There was quite a bit of support for a version the never returned null and threw an exception if the replacement was null. Thanks, Roger On 10/8/2015 5:26 PM, John

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 8, 2015, at 2:42 PM, Roger Riggs wrote: > > Thanks for the insight, I hope it will help cut down on the thrashing. > > Isn't there a 4th form that throws missing? There are four forms in Optional, but one of them returns "void" and is not relevant here, IMO.

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

not readable. *De: *"Roger Riggs" <roger.ri...@oracle.com> *À: *"Remi Forax" <fo...@univ-mlv.fr> *Cc: *"core-libs-dev" <core-libs-dev@openjdk.java.net> *Envoyé: *Jeudi 8 Octobre 2015 1

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

regards, Rémi > > otherwise apart form the remark of Stephen, the code is Ok. > > > cheers, > > > Rémi > > > > > > ----- Mail original ----- > > > > De: "Roger Riggs" <roger.ri...@oracle.com> À: "core-libs-dev&qu

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Envoyé: Jeudi 8 Octobre 2015 00:24:26 Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null Hi, The original intent was to simplify the filling in of default values (even if null). I took R

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi, The original intent was to simplify the filling in of default values (even if null). I took Remi's point about the canonical coalescing operator not always returning non-null but the push seems to be in the direction of making sure the result is always non-null. I'd rather add a few very

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 7 October 2015 at 23:24, Roger Riggs wrote: > Please consider and comment: > > T nonNullOf(T obj, T defaultObj); > T nonNullOf(T, obj, Supplier defaultSupplier); > > Details are in the updated webrev: >

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

HI Paul, It simplifies code that looks like this: followRedirects = builder.followRedirects == null ? Redirect.NEVER : builder.followRedirects; To: followRedirects = Objects.nonNullOrElse(builder.followRedirects, Redirect.NEVER); It makes the source code more concise by

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

In the database world, the function is COALESCE. And it's not just two arguments but the first non-null argument of any items. I would go with firstNonNull(Object a, Object b) and then provide an overload for a vararg. Cheers, Paul On Tue, Oct 6, 2015 at 10:48 AM, Ivan Gerasimov

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 06.10.2015 16:58, Roger Riggs wrote: Hi Ivan, Easy enough, but I have not surveyed the codebase to see if it would be used or is necessary. Most of the cases I've seen are simple if/then/else or ?: expressions. I found a few possible candidates with grep:

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

What the existing code does would seem to be irrelevant. What is important is deciding what the correct semantics should be for a core method on Objects. If there a desperate need for the webrev semantics, how about two methods? firstNonNull(a, b) - result must not be null firstOrElse(a, b) -

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 10/06/2015 04:11 PM, Paul Benedict wrote: If the second value is allowed to be null, then I don't find this new method useful. What value do you see in it? It doesn't provide any extra functionality to a simple if-else/ternary test, right? I throw my lot in with Stephen that the return

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On 10/6/15 10:09 AM, Louis Wasserman wrote: On Tue, Oct 6, 2015 at 10:03 AM Stuart Marks > wrote: As an aside I notice that Guava's Objects.firstNonNull() is deprecated, with a recommended replacement of MoreObjects.firstNonNull(). [1]

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

..@oracle.com> > Envoyé: Mardi 6 Octobre 2015 19:03:34 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to > non-null > > I agree that with Stephen that Guava's semantics of disallowing a null > default > are preferable. It would seem very odd if a meth

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

If the second value is allowed to be null, then I don't find this new method useful. What value do you see in it? It doesn't provide any extra functionality to a simple if-else/ternary test, right? I throw my lot in with Stephen that the return value must be non-null. Cheers, Paul On Tue, Oct

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Guava uses firstNonNull(a, b). It ensures that the result is never null, by checking that b is not null. I think the semantics of Guava's method is correct. I tend to think the method name isn't bad either. Calling it nonNull(Object,Object) clashes with the existing nonNull(Object) method. Those

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Ivan, Easy enough, but I have not surveyed the codebase to see if it would be used or is necessary. Most of the cases I've seen are simple if/then/else or ?: expressions. Using the Supplier for does have some extra overhead not readily observable in the code. There is precedent for such a

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Roger! I didn't notice the message, so first commented in the Jira. Would it make sense to also add a variant with the second argument of type Supplier, so that it can be lazily calculated only if needed? Something like: public static T nonNull(T obj, Supplier nullDefaultSupplier) {

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

It's quite possible for the second argument to be null. Is that your intention? I am not sure it makes sense, but it's not harmful either. I recommend you can either (1) explicitly document that's a possibility and this method could still return null or (2) prevent it by calling requireNonNull.

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Paul, Hence the question about the method name. It already documents explicitly that the nullDefault value is returned and does not restrict the value. To be a direct replacement for the current code, it should return the 2nd value regardless of whether it is null or not. Roger On

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Stephen, Guava's firstNonNull is a useful semantic, but would not be a drop in replacement for existing code which would need to be examined for behavioral changes due to possibly throwing an exception. So perhaps the nonNullorElse name would be more accurate. Thanks, Roger On 10/6/2015

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

I agree that with Stephen that Guava's semantics of disallowing a null default are preferable. It would seem very odd if a method that has "nonNull" in its name is allowed to return null. It seems to me that the point of this and related methods is to provide a fluent way for a class to