Re: System.getEnv(String name, String def)
I think System.getenv().getOrDefault(key, def) is already an adequate
solution.
On Thu, 18 Feb 2021 at 09:21, Loïc MATHIEU wrote:
> Hi,
>
> Thanks for your replies.
>
> My point here was that using env variables is more and more common to
> configure apps, and they have less convenient support than system
> properties (the other way to provide easy external configuration at launch
> time with key/value).
>
> I agree that Objects.requireNonNullElse(System.getEnv(String key), "n/a"));
> is an easy way to achieve this, but I still think System.getEnv(key, "n/a")
> should be a good addition.
>
> Regards,
>
> Loïc
>
> Le mar. 16 févr. 2021 à 21:59, Remi Forax a écrit :
>
> > - Mail original -
> > > De: "Michael Kuhlmann"
> > > À: "core-libs-dev"
> > > Envoyé: Mardi 16 Février 2021 13:34:30
> > > Objet: Re: System.getEnv(String name, String def)
> >
> > > Hi Rémi,
> > >
> > > I don't want to be pedantic, but I see this as an anti-pattern. You
> > > would create an Optional just to immediately call orElse() on it.
> That's
> > > not how Optional should be used. (But you know that.)
> > >
> > > It's described in Recipe 12 of this Java Magazine article, for
> instance:
> > >
> >
> https://blogs.oracle.com/javamagazine/12-recipes-for-using-the-optional-class-as-its-meant-to-be-used
> >
> > yep, you are right.
> > Optional.ofNullable(...).orElse(...) is not the best pattern in term of
> > readability.
> >
> > >
> > > Best,
> > > Michael
> >
> > regards,
> > Rémi
> >
> > >
> > > On 2/15/21 3:09 PM, Remi Forax wrote:
> > >> Hi Loic,
> > >> You can use Optional.OfNullable() which is a kind of the general
> bridge
> > between
> > >> the nullable world and the non-nullable one.
> > >>
> > >>var fooOptional = Optional.ofNullable(System.getenv("FOO"));
> > >>var fooValue = fooOptional.orElse(defaultValue);
> > >>
> > >> regards,
> > >> Rémi Forax
> > >>
> > >> - Mail original -
> > >>> De: "Loïc MATHIEU"
> > >>> À: "core-libs-dev"
> > >>> Envoyé: Lundi 15 Février 2021 14:59:42
> > >>> Objet: System.getEnv(String name, String def)
> > >>
> > >>> Hello,
> > >>>
> > >>> I wonder if there has already been some discussion to provide
> > >>> a System.getEnv(String name, String def) method that allows to
> return a
> > >>> default value in case the env variable didn't exist.
> > >>>
> > >>> When using system properties instead of env variable, we do have a
> > >>> System.getProperty(String key, String def) variant.
> > >>>
> > >>> Stating the JavaDoc of System.getEnv():
> > >>> *System properties and environment variables are both conceptually
> > mappings
> > >>> between names and values*
> > >>>
> > >>> So if system properties and environment variables are similar
> concepts,
> > >>> they should provide the same functionalities right ?
> > >>>
> > >>> This would be very convenient as more and more people rely on
> > >>> environment variables these days to configure their applications.
> > >>>
> > >>> Regards,
> > >>>
> > > >> Loïc
> >
>
Re: System.getEnv(String name, String def)
Hi,
Thanks for your replies.
My point here was that using env variables is more and more common to
configure apps, and they have less convenient support than system
properties (the other way to provide easy external configuration at launch
time with key/value).
I agree that Objects.requireNonNullElse(System.getEnv(String key), "n/a"));
is an easy way to achieve this, but I still think System.getEnv(key, "n/a")
should be a good addition.
Regards,
Loïc
Le mar. 16 févr. 2021 à 21:59, Remi Forax a écrit :
> - Mail original -
> > De: "Michael Kuhlmann"
> > À: "core-libs-dev"
> > Envoyé: Mardi 16 Février 2021 13:34:30
> > Objet: Re: System.getEnv(String name, String def)
>
> > Hi Rémi,
> >
> > I don't want to be pedantic, but I see this as an anti-pattern. You
> > would create an Optional just to immediately call orElse() on it. That's
> > not how Optional should be used. (But you know that.)
> >
> > It's described in Recipe 12 of this Java Magazine article, for instance:
> >
> https://blogs.oracle.com/javamagazine/12-recipes-for-using-the-optional-class-as-its-meant-to-be-used
>
> yep, you are right.
> Optional.ofNullable(...).orElse(...) is not the best pattern in term of
> readability.
>
> >
> > Best,
> > Michael
>
> regards,
> Rémi
>
> >
> > On 2/15/21 3:09 PM, Remi Forax wrote:
> >> Hi Loic,
> >> You can use Optional.OfNullable() which is a kind of the general bridge
> between
> >> the nullable world and the non-nullable one.
> >>
> >>var fooOptional = Optional.ofNullable(System.getenv("FOO"));
> >> var fooValue = fooOptional.orElse(defaultValue);
> >>
> >> regards,
> >> Rémi Forax
> >>
> >> - Mail original -----
> >>> De: "Loïc MATHIEU"
> >>> À: "core-libs-dev"
> >>> Envoyé: Lundi 15 Février 2021 14:59:42
> >>> Objet: System.getEnv(String name, String def)
> >>
> >>> Hello,
> >>>
> >>> I wonder if there has already been some discussion to provide
> >>> a System.getEnv(String name, String def) method that allows to return a
> >>> default value in case the env variable didn't exist.
> >>>
> >>> When using system properties instead of env variable, we do have a
> >>> System.getProperty(String key, String def) variant.
> >>>
> >>> Stating the JavaDoc of System.getEnv():
> >>> *System properties and environment variables are both conceptually
> mappings
> >>> between names and values*
> >>>
> >>> So if system properties and environment variables are similar concepts,
> >>> they should provide the same functionalities right ?
> >>>
> >>> This would be very convenient as more and more people rely on
> >>> environment variables these days to configure their applications.
> >>>
> >>> Regards,
> >>>
> > >> Loïc
>
Re: System.getEnv(String name, String def)
- Mail original -
> De: "Michael Kuhlmann"
> À: "core-libs-dev"
> Envoyé: Mardi 16 Février 2021 13:34:30
> Objet: Re: System.getEnv(String name, String def)
> Hi Rémi,
>
> I don't want to be pedantic, but I see this as an anti-pattern. You
> would create an Optional just to immediately call orElse() on it. That's
> not how Optional should be used. (But you know that.)
>
> It's described in Recipe 12 of this Java Magazine article, for instance:
> https://blogs.oracle.com/javamagazine/12-recipes-for-using-the-optional-class-as-its-meant-to-be-used
yep, you are right.
Optional.ofNullable(...).orElse(...) is not the best pattern in term of
readability.
>
> Best,
> Michael
regards,
Rémi
>
> On 2/15/21 3:09 PM, Remi Forax wrote:
>> Hi Loic,
>> You can use Optional.OfNullable() which is a kind of the general bridge
>> between
>> the nullable world and the non-nullable one.
>>
>>var fooOptional = Optional.ofNullable(System.getenv("FOO"));
>>var fooValue = fooOptional.orElse(defaultValue);
>>
>> regards,
>> Rémi Forax
>>
>> ----- Mail original -
>>> De: "Loïc MATHIEU"
>>> À: "core-libs-dev"
>>> Envoyé: Lundi 15 Février 2021 14:59:42
>>> Objet: System.getEnv(String name, String def)
>>
>>> Hello,
>>>
>>> I wonder if there has already been some discussion to provide
>>> a System.getEnv(String name, String def) method that allows to return a
>>> default value in case the env variable didn't exist.
>>>
>>> When using system properties instead of env variable, we do have a
>>> System.getProperty(String key, String def) variant.
>>>
>>> Stating the JavaDoc of System.getEnv():
>>> *System properties and environment variables are both conceptually mappings
>>> between names and values*
>>>
>>> So if system properties and environment variables are similar concepts,
>>> they should provide the same functionalities right ?
>>>
>>> This would be very convenient as more and more people rely on
>>> environment variables these days to configure their applications.
>>>
>>> Regards,
>>>
> >> Loïc
Re: System.getEnv(String name, String def)
Hi Rémi,
I don't want to be pedantic, but I see this as an anti-pattern. You
would create an Optional just to immediately call orElse() on it. That's
not how Optional should be used. (But you know that.)
It's described in Recipe 12 of this Java Magazine article, for instance:
https://blogs.oracle.com/javamagazine/12-recipes-for-using-the-optional-class-as-its-meant-to-be-used
Best,
Michael
On 2/15/21 3:09 PM, Remi Forax wrote:
Hi Loic,
You can use Optional.OfNullable() which is a kind of the general bridge between
the nullable world and the non-nullable one.
var fooOptional = Optional.ofNullable(System.getenv("FOO"));
var fooValue = fooOptional.orElse(defaultValue);
regards,
Rémi Forax
- Mail original -
De: "Loïc MATHIEU"
À: "core-libs-dev"
Envoyé: Lundi 15 Février 2021 14:59:42
Objet: System.getEnv(String name, String def)
Hello,
I wonder if there has already been some discussion to provide
a System.getEnv(String name, String def) method that allows to return a
default value in case the env variable didn't exist.
When using system properties instead of env variable, we do have a
System.getProperty(String key, String def) variant.
Stating the JavaDoc of System.getEnv():
*System properties and environment variables are both conceptually mappings
between names and values*
So if system properties and environment variables are similar concepts,
they should provide the same functionalities right ?
This would be very convenient as more and more people rely on
environment variables these days to configure their applications.
Regards,
Loïc
Re: System.getEnv(String name, String def)
Hi, An alternative to a new API is to use the general purpose java.util.Objects.requireNonNull(T,T); Objects.requireNonNullElse(System.getEnv(String key), "n/a")); But a defaulting overload is straightforward. Regard, Roger On 2/15/21 8:59 AM, Loïc MATHIEU wrote: Hello, I wonder if there has already been some discussion to provide a System.getEnv(String name, String def) method that allows to return a default value in case the env variable didn't exist. When using system properties instead of env variable, we do have a System.getProperty(String key, String def) variant. Stating the JavaDoc of System.getEnv(): *System properties and environment variables are both conceptually mappings between names and values* So if system properties and environment variables are similar concepts, they should provide the same functionalities right ? This would be very convenient as more and more people rely on environment variables these days to configure their applications. Regards, Loïc
Re: System.getEnv(String name, String def)
Hi Loic,
You can use Optional.OfNullable() which is a kind of the general bridge between
the nullable world and the non-nullable one.
var fooOptional = Optional.ofNullable(System.getenv("FOO"));
var fooValue = fooOptional.orElse(defaultValue);
regards,
Rémi Forax
- Mail original -
> De: "Loïc MATHIEU"
> À: "core-libs-dev"
> Envoyé: Lundi 15 Février 2021 14:59:42
> Objet: System.getEnv(String name, String def)
> Hello,
>
> I wonder if there has already been some discussion to provide
> a System.getEnv(String name, String def) method that allows to return a
> default value in case the env variable didn't exist.
>
> When using system properties instead of env variable, we do have a
> System.getProperty(String key, String def) variant.
>
> Stating the JavaDoc of System.getEnv():
> *System properties and environment variables are both conceptually mappings
> between names and values*
>
> So if system properties and environment variables are similar concepts,
> they should provide the same functionalities right ?
>
> This would be very convenient as more and more people rely on
> environment variables these days to configure their applications.
>
> Regards,
>
> Loïc
System.getEnv(String name, String def)
Hello, I wonder if there has already been some discussion to provide a System.getEnv(String name, String def) method that allows to return a default value in case the env variable didn't exist. When using system properties instead of env variable, we do have a System.getProperty(String key, String def) variant. Stating the JavaDoc of System.getEnv(): *System properties and environment variables are both conceptually mappings between names and values* So if system properties and environment variables are similar concepts, they should provide the same functionalities right ? This would be very convenient as more and more people rely on environment variables these days to configure their applications. Regards, Loïc
