Re: [Discussion] String libs

Mon, 13 Sep 2021 07:41:24 -0700 

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 <gabrasc...@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.anapa...@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" <gabrasc...@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.hoogl...@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.vazq...@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 <rohit.ya...@shapeblue.com>
     > > Sent: Wednesday, September 8, 2021 5:05 AM
     > > To: dev@cloudstack.apache.org <dev@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 <gutoveron...@apache.org>
     > > Sent: Tuesday, September 7, 2021 04:37
     > > To: dev@cloudstack.apache.org <dev@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
     >

Reply via email to