On Tue, Jun 4, 2019 at 1:07 PM Xeno Amess wrote:
>
> Then 10 years later JDK has its own Strings, and users get confused then.
If we (and the users) wouldn't be ready to accept that risk, then we
could forget the whole project.
Jochen
As a fact that class jdk.internal.joptsimple.internal.Strings does
exist, I don't think we shall add a class named Strings.
That will be misleading sometimes.
Matt Sicker 于2019年6月5日周三 上午12:32写道：
>
> The JDK is the only source allowed to modify java.lang.String, so
> they'd likely add static metho
The JDK is the only source allowed to modify java.lang.String, so
they'd likely add static methods to that directly like String.join()
and the others. The plural name thing was more of an issue with an
interface Thing and utility class Things. As of Java 8, there's
typically no need to have a Thing
Then 10 years later JDK has its own Strings, and users get confused then.
Emmanuel Bourg 于2019年6月4日周二 下午6:58写道：
> Le 28/05/2019 à 13:46, Gary Gregory a écrit :
>
> > Thoughts?
>
> Maybe we could make a more ambitious 'Strings' class with methods taken
> from StringUtils and refactored with a flu
Le 28/05/2019 à 13:46, Gary Gregory a écrit :
> Thoughts?
Maybe we could make a more ambitious 'Strings' class with methods taken
from StringUtils and refactored with a fluent API to avoid the
combinatorial explosion of StringUtils? Just a wild idea.
Emmanuel Bourg
-
On Wed, May 29, 2019 at 8:07 AM Gary Gregory wrote:
> On Tue, May 28, 2019 at 5:04 PM Mark Dacek 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 i
On Tue, May 28, 2019 at 5:04 PM Mark Dacek 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’
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
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 NullSa
