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 <albest...@hotmail.com>
Enviado: miércoles, 19 de mayo de 2021 11:36
Para: core-libs-dev@openjdk.java.net <core-libs-dev@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@openjdk.java.net <core-libs-dev@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 (alber8...@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.
