On Tue, May 28, 2019 at 5:04 PM Mark Dacek <m...@syberion.com> wrote:
> I’m a bit curious on the desire to split it out. I’m not hard opposed but > also don’t know that it would save much time or clarify things for most. I > wouldn’t want to say that this is a critical reason for keeping things as > they are, but I’d imagine that your typical dev doesn’t use StringUtils for > abbreviate or getLevenshteinDistance style-features nearly as often as they > do for length and indexOf to avoid onerous unit tests. > The immediate motivation is that StringUtils does not have a null-safe version of String#getBytes(String). It does have null-safe versions of a _few_ methods from for Strings and CharSequences. Instead of making StringUtils even larger and more unwieldy, I was thinking that having class more focused on "I want to call String methods in a null safe way" as opposed to "I want to perform non-JRE-standard operation on Strings" The obvious drawback is that you now have two classes to mine for functionality instead of one, so typing StringUtils in your IDE will not present the new methods in the NullSafeStrings, you'd have to remember/know what belongs where; IOW you'd have to know what belongs in String vs. not. It was just an idea. For now, I am happy to just add a null safe String#getBytes(String) to StringUtils. Gary > On Tue, May 28, 2019 at 7:53 AM Gary Gregory <garydgreg...@gmail.com> > wrote: > > > Hi All: > > > > Right now we have a giant class called StringUtils. I have code that in > my > > own library that has at least one null-safe API that for Strings. For > > example a String.getBytes(String, Charset) that returns a null byte[] if > > the input String is null. > > > > I'd like to propose a new class called NullSafeStrings, that covers all > > String APIs (there aren't that many) for null-safe String input. If some > of > > these APIs are already in StringUtils, those would be deprecated and > point > > to NullSafeStrings. > > > > Note that I am not using the "Utils" postfix on purpose since I find it > > meaning less and the JRE now uses the plural form for this kind of code; > > see Files and Paths. > > > > Thoughts? > > > > Gary > > >
