New java.util.Strings class

[Raffaello Giulietti]

Hi Alberto,

there's an understandable tendency to wish to add convenience/utility 
methods like the ones you are proposing. Often, however, the perceived 
benefits are not assessed accurately. In other words, convenience 
methods in core libraries must be of real general interest.

Coming to your class, it exposes the constant EMPTY_STRING for "". Now, 
this is 12 characters (or even more if you don't use static imports) 
against 2 for nothing in exchange: "" is very readable, is not a magic 
constant that would deserve a global name, is interned and comes exactly 
to the point. Finding/replacing all occurrences of "" in a code base, if 
so needed, is easy even with the most elementary tools.

Some methods are there just to come around null strings. Now, a properly 
written application rarely uses null strings and if that happens it is 
mostly because of logical errors. The proposed methods hide them instead 
of pointing at their cause by throwing, so would even be harmful if used 
there. Thus, the general usefulness of such methods is probably more 
limited than intended by the proposal.

Other methods are focused on empty strings or strings of whitespaces. 
Agreed, some business logic would have to treat them specially and could 
benefit, but what's so outstanding with them to deserve API points in a 
core lib? In addition, some methods invoke String::strip() just to test 
whether a string is whitespaces.

This is not to say that your methods are not useful, only that they are 
probably not *that* useful to be included as a core lib.

A great post about the tension between the desire to add convenience 
methods to the core libs and try to refrain from doing so:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077103.html


Greetings
Raffaello


On 2021-05-21 11:11, Alberto Otero Rodríguez wrote:
> Hi,
> 
> I have made other changes to the Strings class I proposed in my previous messages.
> 
> The changes are:
> 
>    *   Added the new methods compareTo and compareToIgnoreCase
>    *   Changed WhiteSpace for Whitespace
> 
> You can see the new code here:
> https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
> 
> With those changes, the annotations suggested in the previous message should change to:
> - @NonNullNorWhitespace
> - @NonNullNorWhitespaceElse(defaultValue)
> - @NonNullNorWhitespaceElseGet(class::supplierMethod)
> 
> Regards,
> 
> Alberto Otero Rodríguez.
> ________________________________
> De: Alberto Otero Rodríguez <albest512 at hotmail.com>
> Enviado: miércoles, 19 de mayo de 2021 11:36
> Para: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
> Asunto: RE: New java.util.Strings class
> 
> Hi,
> 
> I have made some changes to the Strings class I proposed in my previous message.
> 
> The changes are:
> 
>    *   Use str.isEmpty() instead of EMPTY_STRING.equals(str)
>    *   Create methods using str.strip() to check a String is not Whitespace
> 
> You can see the new code here:
> https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
> 
> With those changes, the following annotations could also be created for method arguments and return types:
> - @NonNullNorWhiteSpace
> - @NonNullNorWhiteSpaceElse(defaultValue)
> - @NonNullNorWhiteSpaceElseGet(class::supplierMethod)
> 
> I didn't have any response to the previous message.
> 
> Please, take this one in consideration.
> 
> Regards,
> 
> Alberto Otero Rodríguez.
> 
> ________________________________
> De: Alberto Otero Rodríguez
> Enviado: lunes, 17 de mayo de 2021 14:58
> Para: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
> Asunto: New java.util.Strings class
> 
> Hi, members of the core-libs developers of OpenJDK.
> 
> I think Java needs a Strings class similar to the java.util.Objects class of Java 16 to be used in method arguments, return types and Stream filters.
> 
> I have coded it myself here based on the Objects implementation of Java 16 (please have a look):
> https://github.com/Aliuken/Java-Strings/blob/main/Strings.java
> 
> In fact, I think it would be useful also adding annotations for method arguments and return types such as:
> - @NonNull
> - @NonNullElse(defaultValue)
> - @NonNullElseGet(class::supplierMethod)
> - @NonNullNorEmpty
> - @NonNullNorEmptyElse(defaultValue)
> - @NonNullNorEmptyElseGet(class::supplierMethod)
> 
> With that kind of annotations, you could assume thinks like:
> - an argument or return type cannot have value null, but an Exception
> - an argument or return type cannot have value null, but a default value
> 
> What do you think?
> 
> Waiting for your response.
> 
> PS: I am sending this email repeated. I have sended it yesterday with my other email account (alber84ou at gmail.com), but I wasn't a member of this mailing list. Now I have become a member with this other email account.
> 
> Regards,
> 
> Alberto Otero Rodríguez.
>