You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Daniel Augusto Veronezi Salvador <gu...@apache.org> on 2021/09/06 23:07:57 UTC
[Discussion] String libs
Hi all,
Currently, the main String libs we are using are "commons.lang" and "commons.lang3" (either directly or by our facade, "com.cloud.utils"). We have a current discussion about using them directly or via a facade (such as "com.cloud.utils"); however, a third implementation has been added (google.common.base), which adds more to the discussion. "commons.lang" already implement all we need; therefore, adding a third one does not seem to add/improve/help with anything, but adding more moving parts and libraries that we need to watch out for (managing versions, checking for security issues, and so on).
I created a PR (https://github.com/apache/cloudstack/pull/5386) to replace "google.common.base" with "commons.lang3". However, and as Daan suggested too, I'd like to go forward and revisit this discussion to standardize our code. To guide it, I'd like to start with what I think is the main topic:
- Should we use a facade to "commons.lang"? Which are the pros and cons, according to your perspective?
Best regards,
Daniel.
Re: [Discussion] String libs
Posted by Daniel Augusto Veronezi Salvador <dv...@gmail.com>.
Thanks all for the replies.
To summarize what we discussed till now:
- Devs are inclined to use facade, as it may ease the upgrade and
maintenance process of 3rd party libs.
- We should standardize the libs we're using. "commons.lang3" is a solid
candidate, as it provides all we need, has more than 10 years in the
wild, is open-source, and maintained by Apache.
My opinion:
I do understand the pros of adopting a facade approach; however, I don't
see the necessity of it in this case.
- We're inclined to use "commons.lang3" to all the implementations,
which would make a facade of 1 to 1, which does not seem to make much sense.
- If we need to upgrade any lib, as "commons.lang" to "commons.lang3", a
simple "find/replace" would solve most of the cases. Also, it's not like
we will have to upgrade the lib every week; therefore, it will be a
once/twice in a lifetime job (this one would be the first).
- If we create a facade, we should also create unit tests to ensure that
the behavior is equal to the lib and redirect the javadocs to the
underlying lib javadocs. Therefore, it adds a complexity level to our
code and makes us responsible for the lib's operation.
Having said that, I would not be in favor of facade approach. I
understand its pros, but just don't see the need for it in this case.
I will open a voting thread to see if all are in favor of using
"commons.lang3" as the String standard library. Then, if the vote
passes, I will create the PR to address this change in the code base by
removing unnecessary libraries, and changing the code to use
"commons.lang3".
Best regards,
Daniel
On 13/09/2021 09:59, Daan Hoogland wrote:
> @Gabriel Beims Bräscher <ga...@gmail.com>, I would agree that just
> standardising could work as well, but only if we sanction just a single
> implementation. This has proven to be hard in the past. I say, let's do
> both;
> - Let's make a facade. If names are good, do a transparent passthrough, if
> not the best let's use our own, as Rohit suggested.
> - If lang3 indeed provides all that we need from any library, let's
> standardise on it.
> Note that stringutils are just a simple albeit annoying example. We have
> some more similar jobs to do, some of which involve message format or other
> things and are quite risky.
>
>
>
> On Mon, Sep 13, 2021 at 10:13 AM Suresh Anaparti <
> Suresh.Anaparti@shapeblue.com> wrote:
>
>> It's always good to move to the updated libraries, and I agree on
>> upgrading to lang3 library (from lang).
>>
>> We can continue use/improve our facade 'com.cloud.utils.StringUtils' for
>> readability, custom utils from third party libs, this will be a single
>> point of update whenever any util library is upgraded in future.
>>
>> Regards,
>> Suresh
>>
>> On 10/09/21, 11:00 PM, "Gabriel Bräscher" <ga...@gmail.com> wrote:
>>
>> I do understand that a facade adds great value in many situations.
>>
>> However, I am afraid that this could escalate up to a point of us
>> maintaining multiple facades of well-known libraries that in the end
>> already offer us what we need.
>> Such libraries tend to be stable; as an example, lang3 was launched in
>> 2011
>> and has been rock solid since then.
>> If we get into upgrading, at least in the "apache.commons.lang3"
>> example,
>> wpiçd be a "find and replace" operation [see:
>> https://commons.apache.org/proper/commons-lang/article3_0.html].
>>
>> I am inclined into adopting "apache.commons.lang3" and then upgrading
>> all
>> occurrences of "apache.commons.lang" (as mentioned, "find and replace"
>> operation). But I would be OK in moving into a facade.
>> My main concern/goal is to adopt a pattern ASAP, and I would be +1 both
>> ways as long as we ensure a standard in the current and future
>> codebase.
>>
>> Em qua., 8 de set. de 2021 às 12:21, Daan Hoogland <
>> daan.hoogland@gmail.com>
>> escreveu:
>>
>> > Daniel et al,
>> > I've no preference and don't mind multiple dependencies when they
>> supply
>> > overlapping features. I do want to keep 3rd party libraries in facade
>> > projects at all times. It keeps maintenance surface small and it is
>> easier
>> > to see conflicts happening (a good reason to reduce dependencies
>> btw, me
>> > contradicting me).
>> > Both your and Rohit's points make sense to me.
>> >
>> > On Wed, Sep 8, 2021 at 2:36 PM Nicolas Vazquez <
>> > Nicolas.Vazquez@shapeblue.com> wrote:
>> >
>> > > Hi Daniel,
>> > >
>> > > I don't have a preference either, but the work you are proposing
>> on your
>> > > PR makes sense to me.
>> > >
>> > >
>> > > Regards,
>> > >
>> > > Nicolas Vazquez
>> > >
>> > > ________________________________
>> > > From: Rohit Yadav <ro...@shapeblue.com>
>> > > Sent: Wednesday, September 8, 2021 5:05 AM
>> > > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
>> > > Subject: Re: [Discussion] String libs
>> > >
>> > > I don't have any specific inclination, I would use whatever
>> becomes a
>> > > standard.
>> > >
>> > > However, I prefer the readability of a utility method that is
>> readable
>> > and
>> > > easy to understand such as isNullOrEmpty (which suggests it's
>> doing a
>> > null
>> > > check) versus isEmpty.
>> > >
>> > > I suppose a refactoring exercise can be done by picking whatever
>> > favourite
>> > > dependency community consensus is built for (if at all) and then
>> write a
>> > > utility method in something like StringsUtil in cloud-utils and
>> use it
>> > > throughout the codebase so in future if we want to move to
>> something
>> > else -
>> > > all you do is replace your favourite dependency with something new
>> only
>> > in
>> > > StringsUtils of cloud-utils.
>> > >
>> > > ... and update the cloudstack-checkstyle to enforce the new agreed
>> upon
>> > > rule and also update -
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Coding+conventions
>> > >
>> > >
>> > > Regards.
>> > >
>> > > ________________________________
>> > > From: Daniel Augusto Veronezi Salvador <gu...@apache.org>
>> > > Sent: Tuesday, September 7, 2021 04:37
>> > > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
>> > > Subject: [Discussion] String libs
>> > >
>> > > Hi all,
>> > >
>> > > Currently, the main String libs we are using are "commons.lang" and
>> > > "commons.lang3" (either directly or by our facade,
>> "com.cloud.utils"). We
>> > > have a current discussion about using them directly or via a
>> facade (such
>> > > as "com.cloud.utils"); however, a third implementation has been
>> added
>> > > (google.common.base), which adds more to the discussion.
>> "commons.lang"
>> > > already implement all we need; therefore, adding a third one does
>> not
>> > seem
>> > > to add/improve/help with anything, but adding more moving parts and
>> > > libraries that we need to watch out for (managing versions,
>> checking for
>> > > security issues, and so on).
>> > >
>> > > I created a PR (https://github.com/apache/cloudstack/pull/5386) to
>> > > replace "google.common.base" with "commons.lang3". However, and as
>> Daan
>> > > suggested too, I'd like to go forward and revisit this discussion
>> to
>> > > standardize our code. To guide it, I'd like to start with what I
>> think is
>> > > the main topic:
>> > >
>> > > - Should we use a facade to "commons.lang"? Which are the pros and
>> cons,
>> > > according to your perspective?
>> > >
>> > > Best regards,
>> > > Daniel.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> > --
>> > Daan
>> >
>>
>>
>>
>>
>>
Re: [Discussion] String libs
Posted by Daan Hoogland <da...@gmail.com>.
@Gabriel Beims Bräscher <ga...@gmail.com>, I would agree that just
standardising could work as well, but only if we sanction just a single
implementation. This has proven to be hard in the past. I say, let's do
both;
- Let's make a facade. If names are good, do a transparent passthrough, if
not the best let's use our own, as Rohit suggested.
- If lang3 indeed provides all that we need from any library, let's
standardise on it.
Note that stringutils are just a simple albeit annoying example. We have
some more similar jobs to do, some of which involve message format or other
things and are quite risky.
On Mon, Sep 13, 2021 at 10:13 AM Suresh Anaparti <
Suresh.Anaparti@shapeblue.com> wrote:
> It's always good to move to the updated libraries, and I agree on
> upgrading to lang3 library (from lang).
>
> We can continue use/improve our facade 'com.cloud.utils.StringUtils' for
> readability, custom utils from third party libs, this will be a single
> point of update whenever any util library is upgraded in future.
>
> Regards,
> Suresh
>
> On 10/09/21, 11:00 PM, "Gabriel Bräscher" <ga...@gmail.com> wrote:
>
> I do understand that a facade adds great value in many situations.
>
> However, I am afraid that this could escalate up to a point of us
> maintaining multiple facades of well-known libraries that in the end
> already offer us what we need.
> Such libraries tend to be stable; as an example, lang3 was launched in
> 2011
> and has been rock solid since then.
> If we get into upgrading, at least in the "apache.commons.lang3"
> example,
> wpiçd be a "find and replace" operation [see:
> https://commons.apache.org/proper/commons-lang/article3_0.html].
>
> I am inclined into adopting "apache.commons.lang3" and then upgrading
> all
> occurrences of "apache.commons.lang" (as mentioned, "find and replace"
> operation). But I would be OK in moving into a facade.
> My main concern/goal is to adopt a pattern ASAP, and I would be +1 both
> ways as long as we ensure a standard in the current and future
> codebase.
>
> Em qua., 8 de set. de 2021 às 12:21, Daan Hoogland <
> daan.hoogland@gmail.com>
> escreveu:
>
> > Daniel et al,
> > I've no preference and don't mind multiple dependencies when they
> supply
> > overlapping features. I do want to keep 3rd party libraries in facade
> > projects at all times. It keeps maintenance surface small and it is
> easier
> > to see conflicts happening (a good reason to reduce dependencies
> btw, me
> > contradicting me).
> > Both your and Rohit's points make sense to me.
> >
> > On Wed, Sep 8, 2021 at 2:36 PM Nicolas Vazquez <
> > Nicolas.Vazquez@shapeblue.com> wrote:
> >
> > > Hi Daniel,
> > >
> > > I don't have a preference either, but the work you are proposing
> on your
> > > PR makes sense to me.
> > >
> > >
> > > Regards,
> > >
> > > Nicolas Vazquez
> > >
> > > ________________________________
> > > From: Rohit Yadav <ro...@shapeblue.com>
> > > Sent: Wednesday, September 8, 2021 5:05 AM
> > > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > > Subject: Re: [Discussion] String libs
> > >
> > > I don't have any specific inclination, I would use whatever
> becomes a
> > > standard.
> > >
> > > However, I prefer the readability of a utility method that is
> readable
> > and
> > > easy to understand such as isNullOrEmpty (which suggests it's
> doing a
> > null
> > > check) versus isEmpty.
> > >
> > > I suppose a refactoring exercise can be done by picking whatever
> > favourite
> > > dependency community consensus is built for (if at all) and then
> write a
> > > utility method in something like StringsUtil in cloud-utils and
> use it
> > > throughout the codebase so in future if we want to move to
> something
> > else -
> > > all you do is replace your favourite dependency with something new
> only
> > in
> > > StringsUtils of cloud-utils.
> > >
> > > ... and update the cloudstack-checkstyle to enforce the new agreed
> upon
> > > rule and also update -
> > >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Coding+conventions
> > >
> > >
> > > Regards.
> > >
> > > ________________________________
> > > From: Daniel Augusto Veronezi Salvador <gu...@apache.org>
> > > Sent: Tuesday, September 7, 2021 04:37
> > > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > > Subject: [Discussion] String libs
> > >
> > > Hi all,
> > >
> > > Currently, the main String libs we are using are "commons.lang" and
> > > "commons.lang3" (either directly or by our facade,
> "com.cloud.utils"). We
> > > have a current discussion about using them directly or via a
> facade (such
> > > as "com.cloud.utils"); however, a third implementation has been
> added
> > > (google.common.base), which adds more to the discussion.
> "commons.lang"
> > > already implement all we need; therefore, adding a third one does
> not
> > seem
> > > to add/improve/help with anything, but adding more moving parts and
> > > libraries that we need to watch out for (managing versions,
> checking for
> > > security issues, and so on).
> > >
> > > I created a PR (https://github.com/apache/cloudstack/pull/5386) to
> > > replace "google.common.base" with "commons.lang3". However, and as
> Daan
> > > suggested too, I'd like to go forward and revisit this discussion
> to
> > > standardize our code. To guide it, I'd like to start with what I
> think is
> > > the main topic:
> > >
> > > - Should we use a facade to "commons.lang"? Which are the pros and
> cons,
> > > according to your perspective?
> > >
> > > Best regards,
> > > Daniel.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Daan
> >
>
>
>
>
>
--
Daan
Re: [Discussion] String libs
Posted by Suresh Anaparti <Su...@shapeblue.com>.
It's always good to move to the updated libraries, and I agree on upgrading to lang3 library (from lang).
We can continue use/improve our facade 'com.cloud.utils.StringUtils' for readability, custom utils from third party libs, this will be a single point of update whenever any util library is upgraded in future.
Regards,
Suresh
On 10/09/21, 11:00 PM, "Gabriel Bräscher" <ga...@gmail.com> wrote:
I do understand that a facade adds great value in many situations.
However, I am afraid that this could escalate up to a point of us
maintaining multiple facades of well-known libraries that in the end
already offer us what we need.
Such libraries tend to be stable; as an example, lang3 was launched in 2011
and has been rock solid since then.
If we get into upgrading, at least in the "apache.commons.lang3" example,
wpiçd be a "find and replace" operation [see:
https://commons.apache.org/proper/commons-lang/article3_0.html].
I am inclined into adopting "apache.commons.lang3" and then upgrading all
occurrences of "apache.commons.lang" (as mentioned, "find and replace"
operation). But I would be OK in moving into a facade.
My main concern/goal is to adopt a pattern ASAP, and I would be +1 both
ways as long as we ensure a standard in the current and future codebase.
Em qua., 8 de set. de 2021 às 12:21, Daan Hoogland <da...@gmail.com>
escreveu:
> Daniel et al,
> I've no preference and don't mind multiple dependencies when they supply
> overlapping features. I do want to keep 3rd party libraries in facade
> projects at all times. It keeps maintenance surface small and it is easier
> to see conflicts happening (a good reason to reduce dependencies btw, me
> contradicting me).
> Both your and Rohit's points make sense to me.
>
> On Wed, Sep 8, 2021 at 2:36 PM Nicolas Vazquez <
> Nicolas.Vazquez@shapeblue.com> wrote:
>
> > Hi Daniel,
> >
> > I don't have a preference either, but the work you are proposing on your
> > PR makes sense to me.
> >
> >
> > Regards,
> >
> > Nicolas Vazquez
> >
> > ________________________________
> > From: Rohit Yadav <ro...@shapeblue.com>
> > Sent: Wednesday, September 8, 2021 5:05 AM
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Subject: Re: [Discussion] String libs
> >
> > I don't have any specific inclination, I would use whatever becomes a
> > standard.
> >
> > However, I prefer the readability of a utility method that is readable
> and
> > easy to understand such as isNullOrEmpty (which suggests it's doing a
> null
> > check) versus isEmpty.
> >
> > I suppose a refactoring exercise can be done by picking whatever
> favourite
> > dependency community consensus is built for (if at all) and then write a
> > utility method in something like StringsUtil in cloud-utils and use it
> > throughout the codebase so in future if we want to move to something
> else -
> > all you do is replace your favourite dependency with something new only
> in
> > StringsUtils of cloud-utils.
> >
> > ... and update the cloudstack-checkstyle to enforce the new agreed upon
> > rule and also update -
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Coding+conventions
> >
> >
> > Regards.
> >
> > ________________________________
> > From: Daniel Augusto Veronezi Salvador <gu...@apache.org>
> > Sent: Tuesday, September 7, 2021 04:37
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Subject: [Discussion] String libs
> >
> > Hi all,
> >
> > Currently, the main String libs we are using are "commons.lang" and
> > "commons.lang3" (either directly or by our facade, "com.cloud.utils"). We
> > have a current discussion about using them directly or via a facade (such
> > as "com.cloud.utils"); however, a third implementation has been added
> > (google.common.base), which adds more to the discussion. "commons.lang"
> > already implement all we need; therefore, adding a third one does not
> seem
> > to add/improve/help with anything, but adding more moving parts and
> > libraries that we need to watch out for (managing versions, checking for
> > security issues, and so on).
> >
> > I created a PR (https://github.com/apache/cloudstack/pull/5386) to
> > replace "google.common.base" with "commons.lang3". However, and as Daan
> > suggested too, I'd like to go forward and revisit this discussion to
> > standardize our code. To guide it, I'd like to start with what I think is
> > the main topic:
> >
> > - Should we use a facade to "commons.lang"? Which are the pros and cons,
> > according to your perspective?
> >
> > Best regards,
> > Daniel.
> >
> >
> >
> >
> >
> >
> >
>
> --
> Daan
>
Re: [Discussion] String libs
Posted by Gabriel Bräscher <ga...@gmail.com>.
I do understand that a facade adds great value in many situations.
However, I am afraid that this could escalate up to a point of us
maintaining multiple facades of well-known libraries that in the end
already offer us what we need.
Such libraries tend to be stable; as an example, lang3 was launched in 2011
and has been rock solid since then.
If we get into upgrading, at least in the "apache.commons.lang3" example,
wpiçd be a "find and replace" operation [see:
https://commons.apache.org/proper/commons-lang/article3_0.html].
I am inclined into adopting "apache.commons.lang3" and then upgrading all
occurrences of "apache.commons.lang" (as mentioned, "find and replace"
operation). But I would be OK in moving into a facade.
My main concern/goal is to adopt a pattern ASAP, and I would be +1 both
ways as long as we ensure a standard in the current and future codebase.
Em qua., 8 de set. de 2021 às 12:21, Daan Hoogland <da...@gmail.com>
escreveu:
> Daniel et al,
> I've no preference and don't mind multiple dependencies when they supply
> overlapping features. I do want to keep 3rd party libraries in facade
> projects at all times. It keeps maintenance surface small and it is easier
> to see conflicts happening (a good reason to reduce dependencies btw, me
> contradicting me).
> Both your and Rohit's points make sense to me.
>
> On Wed, Sep 8, 2021 at 2:36 PM Nicolas Vazquez <
> Nicolas.Vazquez@shapeblue.com> wrote:
>
> > Hi Daniel,
> >
> > I don't have a preference either, but the work you are proposing on your
> > PR makes sense to me.
> >
> >
> > Regards,
> >
> > Nicolas Vazquez
> >
> > ________________________________
> > From: Rohit Yadav <ro...@shapeblue.com>
> > Sent: Wednesday, September 8, 2021 5:05 AM
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Subject: Re: [Discussion] String libs
> >
> > I don't have any specific inclination, I would use whatever becomes a
> > standard.
> >
> > However, I prefer the readability of a utility method that is readable
> and
> > easy to understand such as isNullOrEmpty (which suggests it's doing a
> null
> > check) versus isEmpty.
> >
> > I suppose a refactoring exercise can be done by picking whatever
> favourite
> > dependency community consensus is built for (if at all) and then write a
> > utility method in something like StringsUtil in cloud-utils and use it
> > throughout the codebase so in future if we want to move to something
> else -
> > all you do is replace your favourite dependency with something new only
> in
> > StringsUtils of cloud-utils.
> >
> > ... and update the cloudstack-checkstyle to enforce the new agreed upon
> > rule and also update -
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Coding+conventions
> >
> >
> > Regards.
> >
> > ________________________________
> > From: Daniel Augusto Veronezi Salvador <gu...@apache.org>
> > Sent: Tuesday, September 7, 2021 04:37
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Subject: [Discussion] String libs
> >
> > Hi all,
> >
> > Currently, the main String libs we are using are "commons.lang" and
> > "commons.lang3" (either directly or by our facade, "com.cloud.utils"). We
> > have a current discussion about using them directly or via a facade (such
> > as "com.cloud.utils"); however, a third implementation has been added
> > (google.common.base), which adds more to the discussion. "commons.lang"
> > already implement all we need; therefore, adding a third one does not
> seem
> > to add/improve/help with anything, but adding more moving parts and
> > libraries that we need to watch out for (managing versions, checking for
> > security issues, and so on).
> >
> > I created a PR (https://github.com/apache/cloudstack/pull/5386) to
> > replace "google.common.base" with "commons.lang3". However, and as Daan
> > suggested too, I'd like to go forward and revisit this discussion to
> > standardize our code. To guide it, I'd like to start with what I think is
> > the main topic:
> >
> > - Should we use a facade to "commons.lang"? Which are the pros and cons,
> > according to your perspective?
> >
> > Best regards,
> > Daniel.
> >
> >
> >
> >
> >
> >
> >
>
> --
> Daan
>
Re: [Discussion] String libs
Posted by Daan Hoogland <da...@gmail.com>.
Daniel et al,
I've no preference and don't mind multiple dependencies when they supply
overlapping features. I do want to keep 3rd party libraries in facade
projects at all times. It keeps maintenance surface small and it is easier
to see conflicts happening (a good reason to reduce dependencies btw, me
contradicting me).
Both your and Rohit's points make sense to me.
On Wed, Sep 8, 2021 at 2:36 PM Nicolas Vazquez <
Nicolas.Vazquez@shapeblue.com> wrote:
> Hi Daniel,
>
> I don't have a preference either, but the work you are proposing on your
> PR makes sense to me.
>
>
> Regards,
>
> Nicolas Vazquez
>
> ________________________________
> From: Rohit Yadav <ro...@shapeblue.com>
> Sent: Wednesday, September 8, 2021 5:05 AM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: Re: [Discussion] String libs
>
> I don't have any specific inclination, I would use whatever becomes a
> standard.
>
> However, I prefer the readability of a utility method that is readable and
> easy to understand such as isNullOrEmpty (which suggests it's doing a null
> check) versus isEmpty.
>
> I suppose a refactoring exercise can be done by picking whatever favourite
> dependency community consensus is built for (if at all) and then write a
> utility method in something like StringsUtil in cloud-utils and use it
> throughout the codebase so in future if we want to move to something else -
> all you do is replace your favourite dependency with something new only in
> StringsUtils of cloud-utils.
>
> ... and update the cloudstack-checkstyle to enforce the new agreed upon
> rule and also update -
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Coding+conventions
>
>
> Regards.
>
> ________________________________
> From: Daniel Augusto Veronezi Salvador <gu...@apache.org>
> Sent: Tuesday, September 7, 2021 04:37
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: [Discussion] String libs
>
> Hi all,
>
> Currently, the main String libs we are using are "commons.lang" and
> "commons.lang3" (either directly or by our facade, "com.cloud.utils"). We
> have a current discussion about using them directly or via a facade (such
> as "com.cloud.utils"); however, a third implementation has been added
> (google.common.base), which adds more to the discussion. "commons.lang"
> already implement all we need; therefore, adding a third one does not seem
> to add/improve/help with anything, but adding more moving parts and
> libraries that we need to watch out for (managing versions, checking for
> security issues, and so on).
>
> I created a PR (https://github.com/apache/cloudstack/pull/5386) to
> replace "google.common.base" with "commons.lang3". However, and as Daan
> suggested too, I'd like to go forward and revisit this discussion to
> standardize our code. To guide it, I'd like to start with what I think is
> the main topic:
>
> - Should we use a facade to "commons.lang"? Which are the pros and cons,
> according to your perspective?
>
> Best regards,
> Daniel.
>
>
>
>
>
>
>
--
Daan
Re: [Discussion] String libs
Posted by Nicolas Vazquez <Ni...@shapeblue.com>.
Hi Daniel,
I don't have a preference either, but the work you are proposing on your PR makes sense to me.
Regards,
Nicolas Vazquez
________________________________
From: Rohit Yadav <ro...@shapeblue.com>
Sent: Wednesday, September 8, 2021 5:05 AM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: Re: [Discussion] String libs
I don't have any specific inclination, I would use whatever becomes a standard.
However, I prefer the readability of a utility method that is readable and easy to understand such as isNullOrEmpty (which suggests it's doing a null check) versus isEmpty.
I suppose a refactoring exercise can be done by picking whatever favourite dependency community consensus is built for (if at all) and then write a utility method in something like StringsUtil in cloud-utils and use it throughout the codebase so in future if we want to move to something else - all you do is replace your favourite dependency with something new only in StringsUtils of cloud-utils.
... and update the cloudstack-checkstyle to enforce the new agreed upon rule and also update - https://cwiki.apache.org/confluence/display/CLOUDSTACK/Coding+conventions
Regards.
________________________________
From: Daniel Augusto Veronezi Salvador <gu...@apache.org>
Sent: Tuesday, September 7, 2021 04:37
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: [Discussion] String libs
Hi all,
Currently, the main String libs we are using are "commons.lang" and "commons.lang3" (either directly or by our facade, "com.cloud.utils"). We have a current discussion about using them directly or via a facade (such as "com.cloud.utils"); however, a third implementation has been added (google.common.base), which adds more to the discussion. "commons.lang" already implement all we need; therefore, adding a third one does not seem to add/improve/help with anything, but adding more moving parts and libraries that we need to watch out for (managing versions, checking for security issues, and so on).
I created a PR (https://github.com/apache/cloudstack/pull/5386) to replace "google.common.base" with "commons.lang3". However, and as Daan suggested too, I'd like to go forward and revisit this discussion to standardize our code. To guide it, I'd like to start with what I think is the main topic:
- Should we use a facade to "commons.lang"? Which are the pros and cons, according to your perspective?
Best regards,
Daniel.
Re: [Discussion] String libs
Posted by Rohit Yadav <ro...@shapeblue.com>.
I don't have any specific inclination, I would use whatever becomes a standard.
However, I prefer the readability of a utility method that is readable and easy to understand such as isNullOrEmpty (which suggests it's doing a null check) versus isEmpty.
I suppose a refactoring exercise can be done by picking whatever favourite dependency community consensus is built for (if at all) and then write a utility method in something like StringsUtil in cloud-utils and use it throughout the codebase so in future if we want to move to something else - all you do is replace your favourite dependency with something new only in StringsUtils of cloud-utils.
... and update the cloudstack-checkstyle to enforce the new agreed upon rule and also update - https://cwiki.apache.org/confluence/display/CLOUDSTACK/Coding+conventions
Regards.
________________________________
From: Daniel Augusto Veronezi Salvador <gu...@apache.org>
Sent: Tuesday, September 7, 2021 04:37
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: [Discussion] String libs
Hi all,
Currently, the main String libs we are using are "commons.lang" and "commons.lang3" (either directly or by our facade, "com.cloud.utils"). We have a current discussion about using them directly or via a facade (such as "com.cloud.utils"); however, a third implementation has been added (google.common.base), which adds more to the discussion. "commons.lang" already implement all we need; therefore, adding a third one does not seem to add/improve/help with anything, but adding more moving parts and libraries that we need to watch out for (managing versions, checking for security issues, and so on).
I created a PR (https://github.com/apache/cloudstack/pull/5386) to replace "google.common.base" with "commons.lang3". However, and as Daan suggested too, I'd like to go forward and revisit this discussion to standardize our code. To guide it, I'd like to start with what I think is the main topic:
- Should we use a facade to "commons.lang"? Which are the pros and cons, according to your perspective?
Best regards,
Daniel.