The Apache Commons Lang team is pleased to announce the release of
Apache Commons Lang 3.18.0.
Commons Lang is a set of utility functions and reusable components
that should be useful in any Java environment.
Starting with Commons Lang 3.9, we target Java 8.
For advice on upgrading from 2.x to
t; - Reports good
>
> Thank you Gary for all you do!
>
> > On Jul 6, 2025, at 1:51 PM, Gary Gregory wrote:
> >
> > We have fixed a few bugs and added enhancements since Apache Commons
> > Lang 3.17.0 was released, so I would like to release Apache Commons
> &g
+1
- Site good
- Tests on java 8, 11, 17, 21
- Signatures good
- Reports good
Thank you Gary for all you do!
> On Jul 6, 2025, at 1:51 PM, Gary Gregory wrote:
>
> We have fixed a few bugs and added enhancements since Apache Commons
> Lang 3.17.0 was released, so I would lik
My +1
Gary
On Sun, Jul 6, 2025, 13:51 Gary Gregory wrote:
> We have fixed a few bugs and added enhancements since Apache Commons
> Lang 3.17.0 was released, so I would like to release Apache Commons
> Lang 3.18.0.
>
> Apache Commons Lang 3.18.0 RC2 is available for review he
this release because...
+1 (binding), release the artifacts.
I have reviewed the release candidate available at:
https://dist.apache.org/repos/dist/dev/commons/lang/3.18.0-RC2/source
I performed the following checks:
- Verified checksums and signatures.
- Successfully rebuilt the source release a
We have fixed a few bugs and added enhancements since Apache Commons
Lang 3.17.0 was released, so I would like to release Apache Commons
Lang 3.18.0.
Apache Commons Lang 3.18.0 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/lang/3.18.0-RC2
(svn revision 77972
; #Fri Jul 04 18:23:38 EDT 2025
> artifactId=commons-lang3
> groupId=org.apache.commons
> m2e.projectLocation=/Users/garygregory/git/commons-lang
> m2e.projectName=commons-lang3
> version=3.18.0
>
> * META-INF/MANIFEST.MF contains:
>
> Build-Jdk-Spec: 23
>
> This line appears to
r Eclipse
#Fri Jul 04 18:23:38 EDT 2025
artifactId=commons-lang3
groupId=org.apache.commons
m2e.projectLocation=/Users/garygregory/git/commons-lang
m2e.projectName=commons-lang3
version=3.18.0
* META-INF/MANIFEST.MF contains:
Build-Jdk-Spec: 23
This line appears to have been added by Eclipse and
Matt,
A vote to publish a release candidate is in progress started yesterday.
Gary
On Fri, Jun 20, 2025 at 9:11 AM Gary Gregory wrote:
>
>
> -- Forwarded message -
> From: Gary Gregory
> Date: Fri, Jun 20, 2025, 09:11
> Subject: Re: [LANG] [Question] Antici
We have fixed a few bugs and added enhancements since Apache Commons
Lang 3.17.0 was released, so I would like to release Apache Commons
Lang 3.18.0.
Apache Commons Lang 3.18.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/lang/3.18.0-RC1
(svn revision 77960
I reverted the change before you sent this email out.
-Rob
> On Apr 25, 2025, at 10:46 AM, Gary Gregory wrote:
>
> Rob,
>
> Please run a local build before such a change, the build is failing.
>
> I'll adjust the parent pom to pick an old spotbugs version to run on Java 8...
>
> Gary
>
> On
Rob,
Please run a local build before such a change, the build is failing.
I'll adjust the parent pom to pick an old spotbugs version to run on Java 8...
Gary
On Fri, Apr 25, 2025 at 10:38 AM wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> chtompki pushed a co
e a unit test with the expected behavior? The example
> you gave has console output and assertions commented out, both of
> which are undesirable. Instead of me guessing, I'd rather you manage
> expectations and provide a failing/passing set of assertions.
>
> TY!
>
n Sun, Apr 13, 2025 at 7:45 PM Gary Gregory wrote:
>
> I created https://issues.apache.org/jira/browse/LANG-1770 to track this
> report.
>
> Gary
>
> On Fri, Apr 11, 2025 at 10:15 AM Carsten Kirschner
> wrote:
> >
> > Hello,
> >
> > The
I created https://issues.apache.org/jira/browse/LANG-1770 to track this report.
Gary
On Fri, Apr 11, 2025 at 10:15 AM Carsten Kirschner
wrote:
>
> Hello,
>
> The current commons lang3 StringUtils.abbreviate (3.17.0) implementation will
> destroy 4 byte emoji characters and
Hello,
The current commons lang3 StringUtils.abbreviate (3.17.0) implementation will
destroy 4 byte emoji characters and larger grapheme clusters. I know that
handling grapheme correctly before java 20 is not possible, but at least a
codepoint aware solution with String.offsetByCodPoints could
Hello,
Thank you for a great product. I just wanted to notify you that the code
example shown in the DiffBuilder documentation (
https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/DiffBuilder.html)
for the DiffBuilder deprecation is syntactically incorrect
; > time zone experts.
> > It's probably time to deprecate FastDateFormat in favor of java.time.
>
> +1 (even if just to reduce bloat).
>
> Given the purpose and scope of [Lang], it's on those who would be against
> this proposal t
tDateFormat in favor of java.time.
+1 (even if just to reduce bloat).
Given the purpose and scope of [Lang], it's on those who would be against
this proposal to justify their position.
[But please start a new threa
I am not surprised you've found issues with FastDateFormat. I'd be
more surprised if you didn't. Handling time zones is *hard* and almost
everyone gets it wrong, at least at first. In 2025 I wouldn't use
either SimpleDateFormat or FastDateFormat. Use java.time and
java.time.formatter instead. These
I started using FastDateFormat.parser() while expanding some internal tests
of an old custom date parser, and killing usages of
SimpleDateFormat.parse(). Since FastDateFormat uses Calendar internally to
keep state, I was surprised that I got unexpected results when using
"generic" timezones. Gene
tionEquals` on the elements of an
> internal list field?
Because the javaDoc says exactly that:
https://github.com/apache/commons-lang/blob/95d3485cd4312d8e1a846887b0b555eec4f7417b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java#L199
> IMHO, if you run `reflectionEquals` on
Hi Mark,
On 9.12.2024 17:37, Mark Struberg wrote:
c) try using this on a class which contains e.g. an ArrayList, a Set or a Map.
It will e.g. use List#equals() which also does equals() on it's items (btw, I
explained this to you already...). Which is NOT what users expect. Instead it
should i
Hi!
I created a PR which aims to fix commons-lang behaviour which is broken since
quite a few years. To be more precise: commons-lang doesn't fully support
anything beyond Java8 due to not acknowledging the java module system (leading
to InaccessibleObjectException). And no, adding --add-
Le lun. 9 déc. 2024 à 16:36, sebb a écrit :
>
> On Mon, 9 Dec 2024 at 15:19, Gilles Sadowski wrote:
> >
> > Hi.
> >
> > Following up here on the question on GH:
> >
> > > why is this disussion again NOT happening on any ASF list but here where
> > > it does not get reflected to any ASF list afai
On Mon, 9 Dec 2024 at 15:19, Gilles Sadowski wrote:
>
> Hi.
>
> Following up here on the question on GH:
>
> > why is this disussion again NOT happening on any ASF list but here where it
> > does not get reflected to any ASF list afaict?
>
> As Sebb wrote (below), the discussion is sent to "issue
Hi.
Following up here on the question on GH:
> why is this disussion again NOT happening on any ASF list but here where it
> does not get reflected to any ASF list afaict?
As Sebb wrote (below), the discussion is sent to "issues@". Subscribed
people can see what is discussed on GH but their ev
jects out there. In the last few months even the oldest
> >> projects started moving away from Java8. And so should we imo. So please
> >> folks, stop adding --add-opens all over the place.
> >>
> >> txs and LieGrue,
> >> strub
> >>
> &g
there. In the last few months even the oldest
>> projects started moving away from Java8. And so should we imo. So please
>> folks, stop adding --add-opens all over the place.
>>
>> txs and LieGrue,
>> strub
>>
>>
>>
>>> Am 06.12.2024 um 13:59 schri
t; folks, stop adding --add-opens all over the place.
>
> txs and LieGrue,
> strub
>
>
>
> > Am 06.12.2024 um 13:59 schrieb Gilles Sadowski :
> >
> > Hi.
> >
> > Le ven. 6 déc. 2024 à 13:41, struberg (via GitHub) a
> > écrit :
> >>
>
gt; Hi.
>
> Le ven. 6 déc. 2024 à 13:41, struberg (via GitHub) a écrit :
>>
>>
>> struberg commented on PR #1328:
>> URL: https://github.com/apache/commons-lang/pull/1328#issuecomment-2523134541
>>
>> Btw, I'm looking for another method name
Hi.
Le ven. 6 déc. 2024 à 13:41, struberg (via GitHub) a écrit :
>
>
> struberg commented on PR #1328:
> URL: https://github.com/apache/commons-lang/pull/1328#issuecomment-2523134541
>
>Btw, I'm looking for another method name for `isJavaInternalClass()`. It
> shou
Hi Gary,
On 4.12.2024 12:44, Gary Gregory wrote:
The StringUtils methods return a mix of null and "" for each method on null
input. Each method does one of the following:
- null out for null in
- "" out for null in
- null for null and "" for ""
- throw an NPE
We definitively need to put some
Hi,
In my opinion it would be nice if all the methods do the same for the same
null or empty string input and would be consistent, but...
I won't change the existing API in the current 3.x version.
So I think we should fix them only in 4.0.
However, we should fix it in the Strings class, before it
Hi all,
The StringUtils methods return a mix of null and "" for each method on null
input. Each method does one of the following:
- null out for null in
- "" out for null in
- null for null and "" for ""
- throw an NPE
The newer class Strings does the same as it backs StringUtils.
Should we:
-
On Sun, 1 Dec 2024 at 14:35, Piotr P. Karwasz wrote:
>
> Hi sebb,
>
> On 1.12.2024 12:27, sebb wrote:
> > It's not clear to me that this belongs in LANG.
>
> I tend to agree with you. Since the purpose of containers is to run
> applications the same way they would
Hi sebb,
On 1.12.2024 12:27, sebb wrote:
It's not clear to me that this belongs in LANG.
I tend to agree with you. Since the purpose of containers is to run
applications the same way they would run on the host system, I don't
believe this method belongs to any Java library.
Unf
iced the RuntimeEnvironment class.
>
> It's not clear to me that this belongs in LANG.
>
> Assuming it does, I have doubts about how accurate it is.
> I just looked in a couple of Docker containers, and neither contained
> the expected entry in /proc/1/cgroup.
> At the very le
Just noticed the RuntimeEnvironment class.
It's not clear to me that this belongs in LANG.
Assuming it does, I have doubts about how accurate it is.
I just looked in a couple of Docker containers, and neither contained
the expected entry in /proc/1/cgroup.
At the very least there need to be
Hi All,
Following up on this as LANG-1172 changed the previously declared contract of
this method.
Prior to 2.13, the logic and javadocs clearly stated that the separator must be
underscore, but with this change it now also excepts dash.
Javadocs from 2.12:
"This method validates the
Hi All,
I'd like to settle on the implementation of LocaleUtils.toLocale() one way or
another and clearly document expectations.
What should we do?
Please see:
- https://issues.apache.org/jira/browse/LANG-1172
- https://github.com/apache/commons-lang/pull/766
- https://github.com/a
The Apache Commons team is pleased to announce Apache Commons Lang
Version 3.17.0.
Commons Lang is a set of utility functions and reusable components
that should be useful in any Java environment.
Starting with Commons Lang 3.9, we target Java 8, using those features.
For advice on upgrading
e have fixed a few bugs and added enhancements since Apache Commons Lang
> > 3.16.0 was released, so I would like to release Apache Commons Lang 3.17.0.
> >
> > Apache Commons Lang 3.17.0 RC1 is available for review here:
> >https://dist.apache.org/repos/dist/dev/commons/l
+1
> On Aug 24, 2024, at 3:21 PM, Gary Gregory wrote:
>
> We have fixed a few bugs and added enhancements since Apache Commons Lang
> 3.16.0 was released, so I would like to release Apache Commons Lang 3.17.0.
>
> Apache Commons Lang 3.17.0 RC1 is available for revie
[ +1 ]
Build & tests ok, javadoc ok, reports look good (nice coverage), site looks
nice.
Built using: mvn clean install site -s "$HOME/.m2/commons-settings.xml"
On: Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8
My +1
Gary
On Sat, Aug 24, 2024 at 3:21 PM Gary Gregory wrote:
> We have fixed a few bugs and added enhancements since Apache Commons Lang
> 3.16.0 was released, so I would like to release Apache Commons Lang 3.17.0.
>
> Apache Commons Lang 3.17.0 RC1 is available for review here:
We have fixed a few bugs and added enhancements since Apache Commons Lang
3.16.0 was released, so I would like to release Apache Commons Lang 3.17.0.
Apache Commons Lang 3.17.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/lang/3.17.0-RC1 (svn
revision 71083
ctions to
> use a single, overloaded name, e.g. StopWatch::timed(...) or
> StopWatch::withTiming(...)
>
> /peter
>
> On Fri, Aug 16, 2024, 10:50 PM Gary Gregory
> wrote:
>
> > Hi all,
> >
> > Please provide any feedback on
> > - LANG-1747: Measure
his.)
I'd propose renaming all of the functional interface-wrapping functions to
use a single, overloaded name, e.g. StopWatch::timed(...) or
StopWatch::withTiming(...)
/peter
On Fri, Aug 16, 2024, 10:50 PM Gary Gregory wrote:
> Hi all,
>
> Please provide any feedback on
> - LANG-
Hi all,
Please provide any feedback on
- LANG-1747: Measure the execution time of functional interfaces #1254
- https://github.com/apache/commons-lang/pull/1254/
TY!
Gary
-
To unsubscribe, e-mail: dev-unsubscr
Hi All,
I'd like some thoughts on merging
https://github.com/apache/commons-lang/pull/1227
It seems OK to me.
Anyone else?
TY!
Gary
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e
The Apache Commons team is pleased to announce Apache Commons Lang
Version 3.16.0.
Commons Lang is a set of utility functions and reusable components
that should be useful in any Java environment.
Starting with Commons Lang 3.9, we target Java 8, using those features.
For advice on upgrading
;, family: "unix"
>
> Thanks!!!
>
> On 2024/08/01 12:34:55 Gary Gregory wrote:
> > We have fixed a few bugs and added enhancements since Apache Commons
> > Lang 3.15.0 was released, so I would like to release Apache Commons
> > Lang 3.16.0.
> >
> >
family: "unix"
Thanks!!!
On 2024/08/01 12:34:55 Gary Gregory wrote:
> We have fixed a few bugs and added enhancements since Apache Commons
> Lang 3.15.0 was released, so I would like to release Apache Commons
> Lang 3.16.0.
>
> Apache Commons Lang 3.16.0 RC1 is available fo
My +1
Gary
On Fri, Aug 2, 2024 at 11:17 AM Rob Tompkins wrote:
>
> +1 all looks good to me.
>
> Thanks Gary!
>
> -Rob
>
> > On Aug 1, 2024, at 8:34 AM, Gary Gregory wrote:
> >
> > We have fixed a few bugs and added enhancements since Apache Commons
> &
[+1]
Thank you!
Tomas Lanik
On Thu, Aug 1, 2024, 14:35 Gary Gregory wrote:
> We have fixed a few bugs and added enhancements since Apache Commons
> Lang 3.15.0 was released, so I would like to release Apache Commons
> Lang 3.16.0.
>
> Apache Commons Lang 3.16.0 RC1 is avail
+1 all looks good to me.
Thanks Gary!
-Rob
> On Aug 1, 2024, at 8:34 AM, Gary Gregory wrote:
>
> We have fixed a few bugs and added enhancements since Apache Commons
> Lang 3.15.0 was released, so I would like to release Apache Commons
> Lang 3.16.0.
>
> Apache Commo
We have fixed a few bugs and added enhancements since Apache Commons
Lang 3.15.0 was released, so I would like to release Apache Commons
Lang 3.16.0.
Apache Commons Lang 3.16.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/lang/3.16.0-RC1
(svn revision 70651
The Apache Commons team is pleased to announce Apache Commons Lang
Version 3.15.0.
Commons Lang is a set of utility functions and reusable components
that should be useful in any Java environment.
Starting with Commons Lang 3.9, we target Java 8, using those features.
For advice on upgrading
This vote passes with the following votes:
- Gary Gregory (ggregory, binding)
- Tomas Lanik (non-binding)
- Rob Tompkins (chtompki, binding)
- Henri Biestro (henrib, binding)
Gary
On Wed, Jul 17, 2024 at 2:17 PM Henri Biestro wrote:
>
> [ +1 ]
>
> Builds and tests ok; site and Javadoc look good
[ +1 ]
Builds and tests ok; site and Javadoc look good, reports are ok (commendable
coverage btw, nit JIRA report with no version and Tag List report shows a lot
of todo/fixme/etc).
Built using: mvn -P jacoco -P japicmp clean install site -s
~/.m2/commons-settings.xml
With JDK:
openjdk version
+1 all looks good. Signatures, site release notes, builds java 11, 17, 21.
Thank you Gary!!!
-Rob
> On Jul 13, 2024, at 7:08 PM, Gary Gregory wrote:
>
> We have fixed a few bugs and added enhancements since Apache Commons
> Lang 3.14.0 was released, so I would like to release Ap
Tomas,
What did you do to review the release candidate?
TY,
Gary
On 2024/07/15 06:47:37 Tomas Lanik wrote:
> My +1
>
> Tomas Lanik
>
> On Sun, Jul 14, 2024, 01:09 Gary Gregory wrote:
>
> > We have fixed a few bugs and added enhancements since Apache Commons
> >
My +1
Tomas Lanik
On Sun, Jul 14, 2024, 01:09 Gary Gregory wrote:
> We have fixed a few bugs and added enhancements since Apache Commons
> Lang 3.14.0 was released, so I would like to release Apache Commons
> Lang 3.15.0.
>
> Apache Commons Lang 3.15.0 RC2 is available
My +1
Gary
On Sat, Jul 13, 2024, 7:08 PM Gary Gregory wrote:
> We have fixed a few bugs and added enhancements since Apache Commons
> Lang 3.14.0 was released, so I would like to release Apache Commons
> Lang 3.15.0.
>
> Apache Commons Lang 3.15.0 RC2 is available for review he
ry
> >
> > On Sat, Jul 13, 2024 at 5:04 PM Gilles Sadowski wrote:
> > >
> > > Le sam. 13 juil. 2024 à 17:13, Gary Gregory a
écrit :
> > > >
> > > > We have fixed a few bugs and added enhancements since Apache Commons
> > > > Lang 3.14.0 was
We have fixed a few bugs and added enhancements since Apache Commons
Lang 3.14.0 was released, so I would like to release Apache Commons
Lang 3.15.0.
Apache Commons Lang 3.15.0 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC2
(svn revision 70292
Gary Gregory a écrit :
> > >
> > > We have fixed a few bugs and added enhancements since Apache Commons
> > > Lang 3.14.0 was released, so I would like to release Apache Commons
> > > Lang 3.15.0.
> > >
> >
>
Good catch! I'll spin another RC.
Gary
Gary
On Sat, Jul 13, 2024 at 5:04 PM Gilles Sadowski wrote:
>
> Le sam. 13 juil. 2024 à 17:13, Gary Gregory a écrit :
> >
> > We have fixed a few bugs and added enhancements since Apache Commons
> > Lang 3.14.0 was release
Le sam. 13 juil. 2024 à 17:13, Gary Gregory a écrit :
>
> We have fixed a few bugs and added enhancements since Apache Commons
> Lang 3.14.0 was released, so I would like to release Apache Commons
> Lang 3.15.0.
>
What about point (2) in
https://lists.ap
We have fixed a few bugs and added enhancements since Apache Commons
Lang 3.14.0 was released, so I would like to release Apache Commons
Lang 3.15.0.
Apache Commons Lang 3.15.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/lang/3.15.0-RC1
(svn revision 70284
> there.
>
> To address the point "1) gen time performance cost", I’ve written some
> optimizations on top of the current PR: garydgregory#2
> <https://github.com/garydgregory/commons-lang/pull/2>
>
> Benchmarking using JMH with JDK 8 on an AWS c6a.xlarge instanc
!isAnyBlank(css);
> > > > > }
> > > > >
> > > > > public static boolean isNoneEmpty(final CharSequence... css) {
> > > > > return !isAnyEmpty(css);
> > > > > }
> > > > >
> > > >
gt;
> > > > So it is not without precedent to add more methods that are simple
> > > > negations. However we have to consider if this is code bloat, or if the
> > > > addition of simple negation methods is so useful that it warrants
> > > >
he
> > > addition of simple negation methods is so useful that it warrants
> > > inclusion. I would currently consider this as redundant given the lack
> of
> > > actual logic in the methods.
> > >
> > > Alex
> > >
> > >
> > >
lack of
> > actual logic in the methods.
> >
> > Alex
> >
> >
> > >
> > > On Wed, 12 Jun 2024 at 22:29, Department 8
> > > wrote:
> > >
> > > > I just realized the subject name is bad. But here are the two small
> >
; On Wed, 12 Jun 2024 at 22:29, Department 8
> > wrote:
> >
> > > I just realized the subject name is bad. But here are the two small
> > > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
> > >
> > > Please find the pull request as here:
> > &
subject name is bad. But here are the two small
> > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
> >
> > Please find the pull request as here:
> > https://github.com/apache/commons-lang/pull/1234
> >
> > On Wed, 12 Jun 2024 at 21:52, Department 8
tEmpty*.
>
> Please find the pull request as here:
> https://github.com/apache/commons-lang/pull/1234
>
> On Wed, 12 Jun 2024 at 21:52, Department 8
> wrote:
>
>> Hey!
>>
>> Recently when using StringUtils in one of our projects I had felt the
>> urgent
I just realized the subject name is bad. But here are the two small methods
I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
Please find the pull request as here:
https://github.com/apache/commons-lang/pull/1234
On Wed, 12 Jun 2024 at 21:52, Department 8 wrote:
> Hey!
>
> Recently w
Hi,
On Wed, 12 Jun 2024 at 17:23, Department 8 wrote:
> Hey!
>
> Recently when using StringUtils in one of our projects I had felt the
> urgent need to have a utility method like => isAnyNotBlank.
>
> I was able to achieve this using the negation of isAllBlank, so I am
> thinking of introducing
e to do to
support single quotes, and I can imagine use cases for both.
On Thu, May 30, 2024 at 2:48 PM Gary D. Gregory wrote:
> I'm OK with Sebb's solution [1]
>
> Any further thoughts here?
>
> Gary
> [1] https://github.com/apache/commons-lang/pull/1227
>
> On 202
I'm OK with Sebb's solution [1]
Any further thoughts here?
Gary
[1] https://github.com/apache/commons-lang/pull/1227
On 2024/05/29 13:37:40 Mike Drob wrote:
> On Wed, May 29, 2024 at 8:17 AM Gary Gregory wrote:
>
> > (Sorry for the top post, phone)
> >
>
ew assertions indeed fail
> > when interpreting the duplicate single quote as an escaped quote instead
> of
> > a closing and opening quote. In particular, "y' ''years' M 'months'" is
> > interpreted as "4 'years 0 months&qu
7; ''years' M 'months'" is
> interpreted as "4 'years 0 months" while the expected text lacks the quote
> before "years". Same for "hello''world": it's interpreted as "hello'world"
> instead of &q
lo''world": it's interpreted as "hello'world"
> > instead of "helloworld".
>
> Please see https://github.com/apache/commons-lang/pull/1227 for an
> alternate solution.
> This does not cause issues with any existing tests.
>
>
x27; ''years' M 'months'" is
> interpreted as "4 'years 0 months" while the expected text lacks the quote
> before "years". Same for "hello''world": it's interpreted as "hello'world"
> instead
esitate to contact me.
Best regards,
Laertes
On 2024/05/25 13:47:23 Gary Gregory wrote:
> Hello Laertes,
>
> Thank you for your interest in improving Apache Commons Lang :-)
>
> Do you foresee any compatibility issues for existing call sites and
Hello Laertes,
Thank you for your interest in improving Apache Commons Lang :-)
Do you foresee any compatibility issues for existing call sites and
format strings?
For example, can you make your use cases work and still support:
https://github.com/apache/commons-lang/blob
The build is broken.
This maybe should have been a git revert instead of a plain commit.
Gary
On Wed, May 22, 2024, 2:00 PM wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> jochen pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/a
On Fri, 17 May 2024 at 00:11, Gary Gregory wrote:
>
> Can we PLEASE not do this unless we know what the plan is for Commons
> overall? I really don't want to have this stuff copied in all Commons
> Components because I doubt we will want to add Commons Lang as a dependency
&g
Can we PLEASE not do this unless we know what the plan is for Commons
overall? I really don't want to have this stuff copied in all Commons
Components because I doubt we will want to add Commons Lang as a dependency
in all Components. So, what's the plan? Do you plan on copying this stuf
I meant I'll only change the Suppliers to Strings. The deprecations are fine
IMO. This is how I see it:
- Stock system property access is done through SystemProperties (you get
Strings)
- More advanced services that require conversions like getting a Stream of
Paths for a java.class.path is don
Hello Elliotte,
OK, I'll use String defaults instead of Suppliers.
Gary
On 2024/05/02 16:48:48 Elliotte Rusty Harold wrote:
> I'm OK with preferring SystemProperties though I'm not sure that
> alpine justifies a new method and deprecation.
>
> I second the opinion that a literal string is stron
Hi Bernd,
Sounds reasonable. I'll revert the deprecation and use String defaults instead
of Suppliers.
Gary
On 2024/05/01 17:56:34 Bernd Eckenfels wrote:
> Hi Gregory,
>
> What’s the idea behind that deprecation? The implementation is robust and
> simple and easy to use. I would guess most us
I'm OK with preferring SystemProperties though I'm not sure that
alpine justifies a new method and deprecation.
I second the opinion that a literal string is strongly preferable to a
Supplier here. Pick the simplest thing that could possibly work. As
Knuth warned us, premature optimization is the
It feels like the supplier version is much better to avoid the use case of
building the string in place.
I would also like to centralize all things related directly to sys props in
the SysProp class. This way, you know to look in one place instead of
sometimes here and sometimes there.
Do you thi
Hi Gregory,
What’s the idea behind that deprecation? The implementation is robust and
simple and easy to use. I would guess most user rather want to specify a
literal fallback than a supplier.
Gruss
Bernd
ggreg...@apache.org wrote on 1. May 2024 16:07 (GMT +02:00):
> This is an automated emai
>>> +++
>> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>>>>>> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final
>> Object lhs, final Object rhs) {
>>>>>> if (bypassReflectionClasses != null
>>>>>&
;if (bypassReflectionClasses != null
> >>>>&& (bypassReflectionClasses.contains(lhsClass) ||
> bypassReflectionClasses.contains(rhsClass))) {
> >>>>isEquals = lhs.equals(rhs);
> >>>> +
1 - 100 of 1041 matches
Mail list logo
