RE: New java.util.Strings class
Hi Tagir, several things I want to talk about: 1) In Guava already existed an Objects class before Java created its own Objects class. So, I don't see any problem in creating now a Strings class. 2) The idea of creating the class in Java is to use a better or more performant implementation. For example, nowadays is better using strip() instead of trim(). 3) As far as I know, string.isBlank() is equivalent to string().trim().isEmpty(), but I'm not sure if it is equivalent to string.strip().isEmpty(). Regards, Alberto. De: Tagir Valeev Enviado: domingo, 23 de mayo de 2021 14:14 Para: Alberto Otero Rodríguez Cc: core-libs-dev@openjdk.java.net Asunto: Re: New java.util.Strings class Hello! > 1) I based my code in the current java.util.Objects class of Java 16. I don't > know why the Objects class was a good idea, but the Strings class is not. Because Objects class is applicable to any objects (including strings) while Strings is applicable to strings only which greatly narrows its domain. > 2) It's not just treating with nulls, but also with empty strings and > whitespaces. If Java doesn't have this utilities, people will have to use > external libraries like Guava or Apache Commons. People already use Guava and Apache Commons and I see nothing wrong with this. The strong point of Java is the huge third-party libraries ecosystem and easiness of using them in your projects. Sometimes, adding methods to the JDK directly makes the code more concise and more performant, compared to third-party library. For example, String::repeat was available in many third-party libraries but instance method in java.lang.String makes the code shorter and the ability to use internal APIs (e.g., to encode compact-string) makes it more performant, compared to third-party implementation. However, in your case, adding these methods to a standard library doesn't have these advantages, compared to using a third-party library. Moreover, it will add confusion and inconvenience for Guava users, as there's already Strings class in Guava, so it will be hard to use both Guava Strings and JDK Strings. Btw, if I understand correctly, string.strip().isEmpty() could be replaced with a more performant string.isBlank() call. With best regards, Tagir Valeev > > 3) I don't think (when developing a programming language) it is a good idea > to just think in what nowadays you think is a "properly written application". > Java should be prepared for applications programmed in completely different > ways. > > Regards, > > Alberto. > > > De: Raffaello Giulietti > Enviado: sábado, 22 de mayo de 2021 13:22 > Para: core-libs-dev@openjdk.java.net ; > Alberto Otero Rodríguez > Asunto: Re: New java.util.Strings class > > 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
Re: New java.util.Strings class
Hello! > 1) I based my code in the current java.util.Objects class of Java 16. I don't > know why the Objects class was a good idea, but the Strings class is not. Because Objects class is applicable to any objects (including strings) while Strings is applicable to strings only which greatly narrows its domain. > 2) It's not just treating with nulls, but also with empty strings and > whitespaces. If Java doesn't have this utilities, people will have to use > external libraries like Guava or Apache Commons. People already use Guava and Apache Commons and I see nothing wrong with this. The strong point of Java is the huge third-party libraries ecosystem and easiness of using them in your projects. Sometimes, adding methods to the JDK directly makes the code more concise and more performant, compared to third-party library. For example, String::repeat was available in many third-party libraries but instance method in java.lang.String makes the code shorter and the ability to use internal APIs (e.g., to encode compact-string) makes it more performant, compared to third-party implementation. However, in your case, adding these methods to a standard library doesn't have these advantages, compared to using a third-party library. Moreover, it will add confusion and inconvenience for Guava users, as there's already Strings class in Guava, so it will be hard to use both Guava Strings and JDK Strings. Btw, if I understand correctly, string.strip().isEmpty() could be replaced with a more performant string.isBlank() call. With best regards, Tagir Valeev > > 3) I don't think (when developing a programming language) it is a good idea > to just think in what nowadays you think is a "properly written application". > Java should be prepared for applications programmed in completely different > ways. > > Regards, > > Alberto. > > > De: Raffaello Giulietti > Enviado: sábado, 22 de mayo de 2021 13:22 > Para: core-libs-dev@openjdk.java.net ; > Alberto Otero Rodríguez > Asunto: Re: New java.util.Strings class > > 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, > > > > A
RE: New java.util.Strings class
Hi Raffaello, I undestand what you said. However: 1) I based my code in the current java.util.Objects class of Java 16. I don't know why the Objects class was a good idea, but the Strings class is not. 2) It's not just treating with nulls, but also with empty strings and whitespaces. If Java doesn't have this utilities, people will have to use external libraries like Guava or Apache Commons. 3) I don't think (when developing a programming language) it is a good idea to just think in what nowadays you think is a "properly written application". Java should be prepared for applications programmed in completely different ways. Regards, Alberto. De: Raffaello Giulietti Enviado: sábado, 22 de mayo de 2021 13:22 Para: core-libs-dev@openjdk.java.net ; Alberto Otero Rodríguez Asunto: Re: New java.util.Strings class 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 > Enviado: miércoles, 19 de mayo de 2021 11:36 > Para: 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 > 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 > (p
Re: New java.util.Strings class
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 Enviado: miércoles, 19 de mayo de 2021 11:36 Para: 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 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.
RE: New java.util.Strings class
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 Enviado: miércoles, 19 de mayo de 2021 11:36 Para: 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 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.
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 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.
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.
