Re: [collections] bloom filters comments

[Gary Gregory]

On Fri, Dec 27, 2019 at 11:36 AM Claude Warren  wrote:

> On Fri, Dec 27, 2019 at 1:02 AM Gary Gregory 
> wrote:
>
> > Hi Claude and all:
> >
> > Here are a couple of comments on the bloom filter PR.
> >
> > 10,100 ft level comment we do not have to worry about today: Before the
> > release, we might want to split Commons Collection into a multi-module
> > project and have the BF code in it own module. The _main_ reason for this
> > is that it will allow the dependency on Commons Codecis be a non-optional
> > dependency. Optional dependency are a a bit of a pain IMO, especially
> when
> > you deal with large stacks. You end up sucking in everything that is
> > optional when you deliver an app because you do not know for certain
> what's
> > really required at runtime.
> >
> > Closer to the ground: I would make BloomFilter an interface and rename
> > the current BloomFilter class AbstractBloomFilter implements BloomFilter.
> > This will allow the user and maintainer to see what is truly public.
> >
>
> I have done this (not checked in) but the net effect is that all the public
> methods in the AbstractBloomFilter class are reflected in the BloomFilter
> interface and the Shape class has moved to the Interface as well.
>

OK, I think I like BloomFilter as an interface especially since it is used
as an argument in methods. I'll leave it to you as to whether Shape needs
to be folded in. I did notice that Shape is an argument in a few places.
Might we loose some focus and abstraction by folding Shape into the
BloomFilter interface?


> I can remove several methods from BloomFilter that are not strictly
> necessary for this code to function.  I am and have been reticent to do so
> since there are a number of home-grown libraries used by various
> researchers that provide these functions.  But if that is what it takes to
> get this out the door it will be done.
>

Once you have BloomFilter as an interface with an implementing class, it
might make it much clearer as to what really belongs in the interface. The
handy methods can stay in the abstract class of course.


>
> > Since this is a first cut for Commons Collection, I would consider only
> > making APIs public that must be public. Once released, we MUST maintain
> > binary compatibility within minor releases. Major releases allow us to
> > break this compatibility but these do not happen very often. I do not
> know
> > what this means yet for BF but it's a thought to consider. This kind of
> > work is made harder due to the current packaging of the BF code.
> >
> > We could consider putting it all in one package if that helps reduce the
> > public API footprint.
> >
>
> I think that putting all the pieces into a single package will muddy the
> waters a bit.  The classes in o.a.c.c.bloomfilter are high level classes
> and used wherever the Bloom filter code is used.  Objects in the
> o.a.c.c.bloomfilter.hasher classes are Hashers and are really only selected
> when the application developer determines which hasher is best suited for
> the environment.  Finally o.a.c.c.bloomfilter.hasher.function are
> HasherFunction implementations.  These can be used or special cases built
> by the implementer as necessary.  Perhaps I am being a bit too pedantic but
> I do not think it makes sense to merge them into a single package.
>

Let's leave it as is then.

Side note: I'll need to release Commons Codec 1.14 before we can bring in
this PR. I hope to do this after Commons VFS has gone through its own
release cycle (which should be done in 48 hours or so if all goes well.)
Well, we could bring in the PR but depending on a SNAPSHOT build is usually
not a good idea unless it is truly short term.

Thank you,
Gary


>
>
> >
> > Q: All the code in main's
> > org.apache.commons.collections4.bloomfilter.hasher.function is only
> called
> > from test code. Why is that?
> >
>
> They are pluggable modules.  When a developer uses them they an instance is
> created and it is passed to the BloomFilter.Shape() constructor as well as
> to the various Hasher constructors.  For example:
>
> HashFunction hashFunction = new Murmur128x86Cyclic();
> Shape bloomFilterConfig = new Shape( hashFunction, 3, 1.0 / 10);
>
>
> >
> > Nit: Some odd formatting like spaces after open parens: 'toUpperCase(
> > Locale.ROOT)' should be  'toUpperCase(Locale.ROOT)'
> >
> > Gary
> >
>
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren
>

Re: [commons-codec] branch master updated: Change AssertionError to IllegalStateException

[Gary Gregory]

On Fri, Dec 27, 2019 at 8:17 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> aherbert pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-codec.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 1cf4d19  Change AssertionError to IllegalStateException
> 1cf4d19 is described below
>
> commit 1cf4d19069c64d0493f8b92178ffdb728c0c0ac2
> Author: Alex Herbert 
> AuthorDate: Sat Dec 28 01:17:17 2019 +
>
> Change AssertionError to IllegalStateException
> ---
>  src/main/java/org/apache/commons/codec/digest/MurmurHash3.java | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java
> b/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java
> index d4a95ea..5d9aa9d 100644
> --- a/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java
> +++ b/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java
> @@ -1054,7 +1054,7 @@ public final class MurmurHash3 {
>  k = orBytes(unprocessed[0], unprocessed[1],
> unprocessed[2], data[offset]);
>  break;
>  default:
> -throw new AssertionError("Unprocessed length should
> be 1, 2, or 3: " + unprocessedLength);
> +throw new IllegalStateException("Unprocessed length
> should be 1, 2, or 3: " + unprocessedLength);
>  }
>  hash = mix32(k, hash);
>  // Update the offset and length
>

That seems clearer, thanks.

This seems like the kind of code we might want fuzz test. It seems
quite unlikely otherwise we'd hit this case. I also wonder if

Thoughts?

I see in several places:

// Note: This fails to apply masking using 0xL to the seed.

Shouldn't this be in the Javadoc?

Gary

Re: [codec] release soon

[Gary Gregory]

On Fri, Dec 27, 2019 at 3:18 PM Alex Herbert 
wrote:

>
>
> > On 27 Dec 2019, at 16:35, Gary Gregory  wrote:
> >
> > Great, TY. Feel free to add more tests if need be. Edge cases and so on.
> >
> > Gary
>
> If you look at the Jacoco report for MurmurHash3 the only line missing
> execution is the throwing of an AssertionError in a default block of a
> switch statement for a line that should not be possible to reach (line
> 1057).
>
> So it is missing coverage of unreachable code.
>
> This is part of the original code that I did not update. I can rewrite it
> to drop the unreachable code but as it stands it is self documenting.
>
> My preference would be to drop the unreachable code. It is not there
> because it needs to be, for example a catch block to handle a declared
> exception that you never expect. It seems to be to add a default block for
> the switch statement.
>

I'm OK to drop the code, or replace the AssewrtionError with an
IllegalStateException? If any kind of code remains, the exception message
and/or comment should state "this should not happen" but I can imagine it
could if someone put this through some fuzzer.

Gary


> WDYT?
>
> Alex
>
>
> >
> > On Fri, Dec 27, 2019 at 10:54 AM Alex Herbert 
> > wrote:
> >
> >> I'll have a look at this since I rewrote the code and all the tests to
> fix
> >> the hash implementation.
> >>
> >> Alex
> >>
> >> On Fri, 27 Dec 2019, 15:18 Gary Gregory, 
> wrote:
> >>
> >>> Hi Claude,
> >>>
> >>> Is there any way we could get 100% code coverage
> >>> on MurmurHash3$IncrementalHash32x86 ? There is a corner case left
> >> untested.
> >>>
> >>> To see the code coverage, look at the JaCoCo report in
> >>> target\site\index.html under 'Project Reports' after running 'mvn clean
> >>> package site -P jacoco -P japicmp'
> >>>
> >>> Gary
> >>>
> >>> On Thu, Dec 26, 2019 at 5:03 PM Claude Warren 
> wrote:
> >>>
>  For the contributions and issues I was involved in, the javadoc appear
> >> to
>  be correct.
> 
>  Claude
> 
>  On Thu, Dec 26, 2019 at 1:30 PM Gary Gregory 
>  wrote:
> 
> > It looks like we will need a new version of Commons Codec out before
> >> we
>  can
> > use new code there from Commons Collections. So now's the time to
> >>> polish,
> > PR, and so on.
> >
> > If you've contributed code to Codec, please make sure the Javadoc are
> > helpful and the site up to date.
> >
> > Thank you!
> > Gary
> >
> 
> 
>  --
>  I like: Like Like - The likeliest place on the web
>  
>  LinkedIn: http://www.linkedin.com/in/claudewarren
> 
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [codec] release soon

[Alex Herbert]

> On 27 Dec 2019, at 16:35, Gary Gregory  wrote:
> 
> Great, TY. Feel free to add more tests if need be. Edge cases and so on.
> 
> Gary

If you look at the Jacoco report for MurmurHash3 the only line missing 
execution is the throwing of an AssertionError in a default block of a switch 
statement for a line that should not be possible to reach (line 1057).

So it is missing coverage of unreachable code.

This is part of the original code that I did not update. I can rewrite it to 
drop the unreachable code but as it stands it is self documenting. 

My preference would be to drop the unreachable code. It is not there because it 
needs to be, for example a catch block to handle a declared exception that you 
never expect. It seems to be to add a default block for the switch statement.

WDYT?

Alex


> 
> On Fri, Dec 27, 2019 at 10:54 AM Alex Herbert 
> wrote:
> 
>> I'll have a look at this since I rewrote the code and all the tests to fix
>> the hash implementation.
>> 
>> Alex
>> 
>> On Fri, 27 Dec 2019, 15:18 Gary Gregory,  wrote:
>> 
>>> Hi Claude,
>>> 
>>> Is there any way we could get 100% code coverage
>>> on MurmurHash3$IncrementalHash32x86 ? There is a corner case left
>> untested.
>>> 
>>> To see the code coverage, look at the JaCoCo report in
>>> target\site\index.html under 'Project Reports' after running 'mvn clean
>>> package site -P jacoco -P japicmp'
>>> 
>>> Gary
>>> 
>>> On Thu, Dec 26, 2019 at 5:03 PM Claude Warren  wrote:
>>> 
 For the contributions and issues I was involved in, the javadoc appear
>> to
 be correct.
 
 Claude
 
 On Thu, Dec 26, 2019 at 1:30 PM Gary Gregory 
 wrote:
 
> It looks like we will need a new version of Commons Codec out before
>> we
 can
> use new code there from Commons Collections. So now's the time to
>>> polish,
> PR, and so on.
> 
> If you've contributed code to Codec, please make sure the Javadoc are
> helpful and the site up to date.
> 
> Thank you!
> Gary
> 
 
 
 --
 I like: Like Like - The likeliest place on the web
 
 LinkedIn: http://www.linkedin.com/in/claudewarren
 
>>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-lang] branch master updated: Use Collection#toArray(new T[0]) instead of a presized array as it is faster on modern JVMs.

[Matt Sicker]

It's somewhat logical, though, that T[0] is faster than T[size]. In
both cases, the given array is checked to see if it's large enough to
fit the collection contents. If it isn't, then a new array is
allocated. By deferring the new array allocation operation to the
toArray() method call, you avoid two array length checks.

TL;DR: this is probably a spurious micro-optimization.

On Fri, 27 Dec 2019 at 08:48, Gary Gregory  wrote:
>
> I wonder where this should be documented. We could add a // comment to each
> call site, that seems the simplest. Adding a package or component level
> documentation in the style guideline for example could easily be overlooked
> by someone in a debugger for example. So each call site would be best IMO
> something like
> // Using an empty array can be faster
> I don't really want a link to an external random blog in the source.
>
> Thoughts?
>
> Then we can consider doing it throughout Commons.
>
> Gary
>
> On Fri, Dec 27, 2019 at 7:23 AM Pascal Schumacher 
> wrote:
>
> > Feel free to revert the changes.
> >
> > I would revert my changes, but Garry did some follow-up changes so these
> > would to be reverted first.
> >
> > Am 27.12.2019 um 12:33 schrieb sebb:
> > > As that article says in conclusion, T[0] seems currently faster, but that
> > > may not always be the case with future VMs.
> > >
> > > Also it says that IntelliJ IDEA and PMD recommend using T[size] rather
> > than
> > > T[0].
> > > If we release code with T[0], I suspect we will get complaints that the
> > > code is not efficient according to x, y and z.
> > >
> > > I'm not convinced that the change is worth it, but if it is agreed the
> > code
> > > must be thoroughly documented to try and forestall complaints.
> > > According to the article, using a constant empty array is faster, but
> > only
> > > marginally. If there is a constant available it would probably make sense
> > > to use it.
> > > This should also be documented, as it affects the return value for the
> > > empty case.
> > >
> > > S.
> > > On Fri, 27 Dec 2019 at 09:28, Pascal Schumacher <
> > pascalschumac...@gmx.net>
> > > wrote:
> > >
> > >> see https://shipilev.net/blog/2016/arrays-wisdom-ancients/
> > >>
> > >> Am 27.12.2019 um 01:24 schrieb sebb:
> > >>> Also, where is it documented that modern JVMs are faster?
> > >>> To which JVMs does this apply?
> > >>>
> > >>> S.
> > >>>
> > >>> On Thu, 26 Dec 2019 at 22:08, Gary Gregory 
> > >> wrote:
> >  Please do not cause garbage to apparently be generated all over the
> > >> place
> >  by creating new empty arrays all the time. Use the constants Commons
> > >> Lang
> >  constants already defines; see ArrayUtils.
> > 
> >  Gary
> > 
> >  On Thu, Dec 26, 2019 at 4:48 PM  wrote:
> > 
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > pascalschumacher pushed a commit to branch master
> > > in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/master by this push:
> > >new 84668a2  Use Collection#toArray(new T[0]) instead of a
> > >> presized
> > > array as it is faster on modern JVMs.
> > > 84668a2 is described below
> > >
> > > commit 84668a2d980316a580030fd64764cb072b520b09
> > > Author: pascalschumacher 
> > > AuthorDate: Thu Dec 26 22:48:12 2019 +0100
> > >
> > >   Use Collection#toArray(new T[0]) instead of a presized array as
> > >> it is
> > > faster on modern JVMs.
> > > ---
> > >src/main/java/org/apache/commons/lang3/CharSet.java|
> > 2
> > >> +-
> > >src/main/java/org/apache/commons/lang3/StringUtils.java|
> > 10
> > > +-
> > >.../org/apache/commons/lang3/exception/ExceptionUtils.java |
> > 6
> >  +++---
> > >src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java |
> > 4
> > >> ++--
> > >.../java/org/apache/commons/lang3/reflect/MethodUtils.java |
> > 2
> > >> +-
> > >src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java  |
> > 2
> > >> +-
> > >src/main/java/org/apache/commons/lang3/text/StrTokenizer.java  |
> > 4
> > >> ++--
> > >.../org/apache/commons/lang3/time/DurationFormatUtils.java |
> > 2
> > >> +-
> > >.../java/org/apache/commons/lang3/time/FastDatePrinter.java|
> > 2
> > >> +-
> > >.../commons/lang3/concurrent/EventCountCircuitBreakerTest.java |
> > 2
> > >> +-
> > >10 files changed, 18 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/src/main/java/org/apache/commons/lang3/CharSet.java
> > > b/src/main/java/org/apache/commons/lang3/CharSet.java
> > > index 3fdfd07..7955115 100644
> > > --- a/src/main/java/org/apache/commons/lang3/CharSet.java
> > > +++ b/src/main/java/org/apache/commons/lang3/CharSet.java
> > > @@ -225,7 +225,7 @@ public class CharSet implements Serializab

Re: [codec] release soon

[Gary Gregory]

Great, TY. Feel free to add more tests if need be. Edge cases and so on.

Gary

On Fri, Dec 27, 2019 at 10:54 AM Alex Herbert 
wrote:

> I'll have a look at this since I rewrote the code and all the tests to fix
> the hash implementation.
>
> Alex
>
> On Fri, 27 Dec 2019, 15:18 Gary Gregory,  wrote:
>
> > Hi Claude,
> >
> > Is there any way we could get 100% code coverage
> > on MurmurHash3$IncrementalHash32x86 ? There is a corner case left
> untested.
> >
> > To see the code coverage, look at the JaCoCo report in
> > target\site\index.html under 'Project Reports' after running 'mvn clean
> > package site -P jacoco -P japicmp'
> >
> > Gary
> >
> > On Thu, Dec 26, 2019 at 5:03 PM Claude Warren  wrote:
> >
> > > For the contributions and issues I was involved in, the javadoc appear
> to
> > > be correct.
> > >
> > > Claude
> > >
> > > On Thu, Dec 26, 2019 at 1:30 PM Gary Gregory 
> > > wrote:
> > >
> > > > It looks like we will need a new version of Commons Codec out before
> we
> > > can
> > > > use new code there from Commons Collections. So now's the time to
> > polish,
> > > > PR, and so on.
> > > >
> > > > If you've contributed code to Codec, please make sure the Javadoc are
> > > > helpful and the site up to date.
> > > >
> > > > Thank you!
> > > > Gary
> > > >
> > >
> > >
> > > --
> > > I like: Like Like - The likeliest place on the web
> > > 
> > > LinkedIn: http://www.linkedin.com/in/claudewarren
> > >
> >
>

Re: [collections] bloom filters comments

[Claude Warren]

On Fri, Dec 27, 2019 at 1:02 AM Gary Gregory  wrote:

> Hi Claude and all:
>
> Here are a couple of comments on the bloom filter PR.
>
> 10,100 ft level comment we do not have to worry about today: Before the
> release, we might want to split Commons Collection into a multi-module
> project and have the BF code in it own module. The _main_ reason for this
> is that it will allow the dependency on Commons Codecis be a non-optional
> dependency. Optional dependency are a a bit of a pain IMO, especially when
> you deal with large stacks. You end up sucking in everything that is
> optional when you deliver an app because you do not know for certain what's
> really required at runtime.
>
> Closer to the ground: I would make BloomFilter an interface and rename
> the current BloomFilter class AbstractBloomFilter implements BloomFilter.
> This will allow the user and maintainer to see what is truly public.
>

I have done this (not checked in) but the net effect is that all the public
methods in the AbstractBloomFilter class are reflected in the BloomFilter
interface and the Shape class has moved to the Interface as well.

I can remove several methods from BloomFilter that are not strictly
necessary for this code to function.  I am and have been reticent to do so
since there are a number of home-grown libraries used by various
researchers that provide these functions.  But if that is what it takes to
get this out the door it will be done.


> Since this is a first cut for Commons Collection, I would consider only
> making APIs public that must be public. Once released, we MUST maintain
> binary compatibility within minor releases. Major releases allow us to
> break this compatibility but these do not happen very often. I do not know
> what this means yet for BF but it's a thought to consider. This kind of
> work is made harder due to the current packaging of the BF code.
>
> We could consider putting it all in one package if that helps reduce the
> public API footprint.
>

I think that putting all the pieces into a single package will muddy the
waters a bit.  The classes in o.a.c.c.bloomfilter are high level classes
and used wherever the Bloom filter code is used.  Objects in the
o.a.c.c.bloomfilter.hasher classes are Hashers and are really only selected
when the application developer determines which hasher is best suited for
the environment.  Finally o.a.c.c.bloomfilter.hasher.function are
HasherFunction implementations.  These can be used or special cases built
by the implementer as necessary.  Perhaps I am being a bit too pedantic but
I do not think it makes sense to merge them into a single package.


>
> Q: All the code in main's
> org.apache.commons.collections4.bloomfilter.hasher.function is only called
> from test code. Why is that?
>

They are pluggable modules.  When a developer uses them they an instance is
created and it is passed to the BloomFilter.Shape() constructor as well as
to the various Hasher constructors.  For example:

HashFunction hashFunction = new Murmur128x86Cyclic();
Shape bloomFilterConfig = new Shape( hashFunction, 3, 1.0 / 10);


>
> Nit: Some odd formatting like spaces after open parens: 'toUpperCase(
> Locale.ROOT)' should be  'toUpperCase(Locale.ROOT)'
>
> Gary
>


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [codec] release soon

[Alex Herbert]

I'll have a look at this since I rewrote the code and all the tests to fix
the hash implementation.

Alex

On Fri, 27 Dec 2019, 15:18 Gary Gregory,  wrote:

> Hi Claude,
>
> Is there any way we could get 100% code coverage
> on MurmurHash3$IncrementalHash32x86 ? There is a corner case left untested.
>
> To see the code coverage, look at the JaCoCo report in
> target\site\index.html under 'Project Reports' after running 'mvn clean
> package site -P jacoco -P japicmp'
>
> Gary
>
> On Thu, Dec 26, 2019 at 5:03 PM Claude Warren  wrote:
>
> > For the contributions and issues I was involved in, the javadoc appear to
> > be correct.
> >
> > Claude
> >
> > On Thu, Dec 26, 2019 at 1:30 PM Gary Gregory 
> > wrote:
> >
> > > It looks like we will need a new version of Commons Codec out before we
> > can
> > > use new code there from Commons Collections. So now's the time to
> polish,
> > > PR, and so on.
> > >
> > > If you've contributed code to Codec, please make sure the Javadoc are
> > > helpful and the site up to date.
> > >
> > > Thank you!
> > > Gary
> > >
> >
> >
> > --
> > I like: Like Like - The likeliest place on the web
> > 
> > LinkedIn: http://www.linkedin.com/in/claudewarren
> >
>

Re: [codec] release soon

[Gary Gregory]

Hi Claude,

Is there any way we could get 100% code coverage
on MurmurHash3$IncrementalHash32x86 ? There is a corner case left untested.

To see the code coverage, look at the JaCoCo report in
target\site\index.html under 'Project Reports' after running 'mvn clean
package site -P jacoco -P japicmp'

Gary

On Thu, Dec 26, 2019 at 5:03 PM Claude Warren  wrote:

> For the contributions and issues I was involved in, the javadoc appear to
> be correct.
>
> Claude
>
> On Thu, Dec 26, 2019 at 1:30 PM Gary Gregory 
> wrote:
>
> > It looks like we will need a new version of Commons Codec out before we
> can
> > use new code there from Commons Collections. So now's the time to polish,
> > PR, and so on.
> >
> > If you've contributed code to Codec, please make sure the Javadoc are
> > helpful and the site up to date.
> >
> > Thank you!
> > Gary
> >
>
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren
>

Re: [VOTE] Release Apache Commons VFS Project 2.5.0 based on RC1

[Gary Gregory]

I used Java 8. Using Java >= 9 runs the risk of binding to the wrong
ByteBuffer APIs and causing problems at runtime on Java < 9.

Gary

On Thu, Dec 26, 2019 at 12:38 PM Rob Tompkins  wrote:

> +1
>
> I couldn’t get java 11 to fully build the site. I recall that being an
> ongoing problem with VFS, but the main run does indeed work with java 11 so
> the package runs effectively on java 11. The rest of everything checks out
> appropriately, signatures, rat, reports.
>
> -Rob
>
> > On Dec 25, 2019, at 3:32 PM, Gary Gregory  wrote:
> >
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons VFS 2.4.1 was released, so I would like to release
> > Apache Commons VFS Project 2.5.0.
> >
> > Apache Commons VFS Project 2.5.0 RC1 is available for review here:
> >https://dist.apache.org/repos/dist/dev/commons/vfs/2.5.0-RC1 (svn
> > revision 37359)
> >
> > The Git tag commons-vfs-2.5.0-RC1 commit for this RC is
> > 7e093083ee20956a0367137f98b9beb12622e0d7 which you can browse here:
> >
> >
> https://gitbox.apache.org/repos/asf?p=commons-vfs.git;a=commit;h=7e093083ee20956a0367137f98b9beb12622e0d7
> > You may checkout this tag using:
> >git clone https://gitbox.apache.org/repos/asf/commons-vfs.git
> --branch
> > commons-vfs-2.5.0-RC1 commons-vfs-2.5.0-RC1
> >
> > Maven artifacts are here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1482/org/apache/commons/
> >
> > These are the artifacts and their hashes:
> >
> >
> /org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0.jar
> > (SHA1: 6d6f7cca0670b390e98f9698561a79f3902670d8)
> >
> /org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0-sources.jar
> > (SHA1: b7767f2f579c91b091de6078f8d6f0b5e22b486a)
> >
> /org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0-test-sources.jar
> > (SHA1: e96e7d66ee99b62eba3f996d519d3441446f736a)
> >
> /org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0-javadoc.jar
> > (SHA1: 57095c16529baa6fccde11a4ed35be2baf706906)
> >
> /org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0-tests.jar
> > (SHA1: a15454f59add9be4ac8696433cbe4ec9d34967d8)
> >
> /org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0.pom
> > (SHA1: 03d6cee3cbd51d3a7344a4bb806d39ffd4578efa)
> >
> /org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0.jar.asc
> > (SHA1: 9f295f456665ec6a72875c0416ae39ece6037778)
> >
> /org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0-test-sources.jar
> > (SHA1: fce878fdf26a9190437f1246ab1f848e858b58b6)
> >
> /org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0-sources.jar
> > (SHA1: 495a0f4d1db066882df7033ac107841f28d90b62)
> >
> /org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0.pom
> > (SHA1: eb7d91205e065bc31b8f1465ed9170bc4725b6dc)
> >
> /org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0.jar
> > (SHA1: f58fb2fa00843aaa4cb69c7db46b44fe7299006b)
> >
> /org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0-javadoc.jar
> > (SHA1: 8be8d2b6e485b35d52de1a4beca9c8f532b7daa0)
> >
> /org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0-test-sources.jar.asc
> > (SHA1: 76f8ef9180fc0aceea2fc63ddd81f103f409a322)
> >
> /org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0-tests.jar
> > (SHA1: 65cdbb7babbf6ed014aff4f858d8fd1268ec4a65)
> >
> /org/apache/commons/commons-vfs2-distribution/2.5.0/commons-vfs2-distribution-2.5.0.pom
> > (SHA1: e760f854c22e200acf36bba281d22ed9c7c0ef4a)
> > /org/apache/commons/commons-vfs2/2.5.0/commons-vfs2-2.5.0-javadoc.jar
> > (SHA1: 53cb47e9af18a3cb00ee03d47f53b3cb99dc977c)
> > /org/apache/commons/commons-vfs2/2.5.0/commons-vfs2-2.5.0-sources.jar
> > (SHA1: 4f41fb7956ca972094987e2a4774b15d32126767)
> > /org/apache/commons/commons-vfs2/2.5.0/commons-vfs2-2.5.0-tests.jar
> > (SHA1: a1ce843cd2de5d7848eb683ac731adaa53bac9ed)
> > /org/apache/commons/commons-vfs2/2.5.0/commons-vfs2-2.5.0.jar
> > (SHA1: c3c68acdc39943b830eb691069e5570f09586173)
> > /org/apache/commons/commons-vfs2/2.5.0/commons-vfs2-2.5.0.pom
> > (SHA1: 5eda2e90c21b4435e5b365836098830eadbdad2e)
> >
> /org/apache/commons/commons-vfs2/2.5.0/commons-vfs2-2.5.0-test-sources.jar
> > (SHA1: 99710f56b7112879e90ca2ee8d4c455a98ab1a5f)
> >
> /org/apache/commons/commons-vfs2-project/2.5.0/commons-vfs2-project-2.5.0.pom
> > (SHA1: 278484a5f55f63de7056449a319a78c35ff95e4b)
> >
> /org/apache/commons/commons-vfs2-project/2.5.0/commons-vfs2-project-2.5.0-site.xml
> > (SHA1: b364640391ebedadd05f7371806938f947df3acb)
> >
> /org/apache/commons/commons-vfs2-examples/2.5.0/commons-vfs2-examples-2.5.0-javadoc.jar
> > (SHA1: 46a5716f6bd6aeff21d0c119e9114e8cbdfeedce)
> >
> /org/apache/commons/commons-vfs2-examples/2.

Re: [commons-lang] branch master updated: Use Collection#toArray(new T[0]) instead of a presized array as it is faster on modern JVMs.

[Gary Gregory]

I wonder where this should be documented. We could add a // comment to each
call site, that seems the simplest. Adding a package or component level
documentation in the style guideline for example could easily be overlooked
by someone in a debugger for example. So each call site would be best IMO
something like
// Using an empty array can be faster
I don't really want a link to an external random blog in the source.

Thoughts?

Then we can consider doing it throughout Commons.

Gary

On Fri, Dec 27, 2019 at 7:23 AM Pascal Schumacher 
wrote:

> Feel free to revert the changes.
>
> I would revert my changes, but Garry did some follow-up changes so these
> would to be reverted first.
>
> Am 27.12.2019 um 12:33 schrieb sebb:
> > As that article says in conclusion, T[0] seems currently faster, but that
> > may not always be the case with future VMs.
> >
> > Also it says that IntelliJ IDEA and PMD recommend using T[size] rather
> than
> > T[0].
> > If we release code with T[0], I suspect we will get complaints that the
> > code is not efficient according to x, y and z.
> >
> > I'm not convinced that the change is worth it, but if it is agreed the
> code
> > must be thoroughly documented to try and forestall complaints.
> > According to the article, using a constant empty array is faster, but
> only
> > marginally. If there is a constant available it would probably make sense
> > to use it.
> > This should also be documented, as it affects the return value for the
> > empty case.
> >
> > S.
> > On Fri, 27 Dec 2019 at 09:28, Pascal Schumacher <
> pascalschumac...@gmx.net>
> > wrote:
> >
> >> see https://shipilev.net/blog/2016/arrays-wisdom-ancients/
> >>
> >> Am 27.12.2019 um 01:24 schrieb sebb:
> >>> Also, where is it documented that modern JVMs are faster?
> >>> To which JVMs does this apply?
> >>>
> >>> S.
> >>>
> >>> On Thu, 26 Dec 2019 at 22:08, Gary Gregory 
> >> wrote:
>  Please do not cause garbage to apparently be generated all over the
> >> place
>  by creating new empty arrays all the time. Use the constants Commons
> >> Lang
>  constants already defines; see ArrayUtils.
> 
>  Gary
> 
>  On Thu, Dec 26, 2019 at 4:48 PM  wrote:
> 
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > pascalschumacher pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >new 84668a2  Use Collection#toArray(new T[0]) instead of a
> >> presized
> > array as it is faster on modern JVMs.
> > 84668a2 is described below
> >
> > commit 84668a2d980316a580030fd64764cb072b520b09
> > Author: pascalschumacher 
> > AuthorDate: Thu Dec 26 22:48:12 2019 +0100
> >
> >   Use Collection#toArray(new T[0]) instead of a presized array as
> >> it is
> > faster on modern JVMs.
> > ---
> >src/main/java/org/apache/commons/lang3/CharSet.java|
> 2
> >> +-
> >src/main/java/org/apache/commons/lang3/StringUtils.java|
> 10
> > +-
> >.../org/apache/commons/lang3/exception/ExceptionUtils.java |
> 6
>  +++---
> >src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java |
> 4
> >> ++--
> >.../java/org/apache/commons/lang3/reflect/MethodUtils.java |
> 2
> >> +-
> >src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java  |
> 2
> >> +-
> >src/main/java/org/apache/commons/lang3/text/StrTokenizer.java  |
> 4
> >> ++--
> >.../org/apache/commons/lang3/time/DurationFormatUtils.java |
> 2
> >> +-
> >.../java/org/apache/commons/lang3/time/FastDatePrinter.java|
> 2
> >> +-
> >.../commons/lang3/concurrent/EventCountCircuitBreakerTest.java |
> 2
> >> +-
> >10 files changed, 18 insertions(+), 18 deletions(-)
> >
> > diff --git a/src/main/java/org/apache/commons/lang3/CharSet.java
> > b/src/main/java/org/apache/commons/lang3/CharSet.java
> > index 3fdfd07..7955115 100644
> > --- a/src/main/java/org/apache/commons/lang3/CharSet.java
> > +++ b/src/main/java/org/apache/commons/lang3/CharSet.java
> > @@ -225,7 +225,7 @@ public class CharSet implements Serializable {
> >// NOTE: This is no longer public as CharRange is no longer a
> public
> > class.
> >//   It may be replaced when CharSet moves to Range.
> >/*public*/ CharRange[] getCharRanges() {
> > -return set.toArray(new CharRange[set.size()]);
> > +return set.toArray(new CharRange[0]);
> >}
> >
> >
> >
> >>
> //---
> > diff --git a/src/main/java/org/apache/commons/lang3/StringUtils.java
> > b/src/main/java/org/apache/commons/lang3/StringUtils.java
> > index abde7ec..d629806 100644
> > --- a/src/main/java/org

Re: [commons-lang] branch master updated: Use Collection#toArray(new T[0]) instead of a presized array as it is faster on modern JVMs.

[Pascal Schumacher]

Feel free to revert the changes.

I would revert my changes, but Garry did some follow-up changes so these
would to be reverted first.

Am 27.12.2019 um 12:33 schrieb sebb:

As that article says in conclusion, T[0] seems currently faster, but that
may not always be the case with future VMs.

Also it says that IntelliJ IDEA and PMD recommend using T[size] rather than
T[0].
If we release code with T[0], I suspect we will get complaints that the
code is not efficient according to x, y and z.

I'm not convinced that the change is worth it, but if it is agreed the code
must be thoroughly documented to try and forestall complaints.
According to the article, using a constant empty array is faster, but only
marginally. If there is a constant available it would probably make sense
to use it.
This should also be documented, as it affects the return value for the
empty case.

S.
On Fri, 27 Dec 2019 at 09:28, Pascal Schumacher 
wrote:


see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

Am 27.12.2019 um 01:24 schrieb sebb:

Also, where is it documented that modern JVMs are faster?
To which JVMs does this apply?

S.

On Thu, 26 Dec 2019 at 22:08, Gary Gregory 

wrote:

Please do not cause garbage to apparently be generated all over the

place

by creating new empty arrays all the time. Use the constants Commons

Lang

constants already defines; see ArrayUtils.

Gary

On Thu, Dec 26, 2019 at 4:48 PM  wrote:


This is an automated email from the ASF dual-hosted git repository.

pascalschumacher pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-lang.git


The following commit(s) were added to refs/heads/master by this push:
   new 84668a2  Use Collection#toArray(new T[0]) instead of a

presized

array as it is faster on modern JVMs.
84668a2 is described below

commit 84668a2d980316a580030fd64764cb072b520b09
Author: pascalschumacher 
AuthorDate: Thu Dec 26 22:48:12 2019 +0100

  Use Collection#toArray(new T[0]) instead of a presized array as

it is

faster on modern JVMs.
---
   src/main/java/org/apache/commons/lang3/CharSet.java|  2

+-

   src/main/java/org/apache/commons/lang3/StringUtils.java| 10
+-
   .../org/apache/commons/lang3/exception/ExceptionUtils.java |  6

+++---

   src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java |  4

++--

   .../java/org/apache/commons/lang3/reflect/MethodUtils.java |  2

+-

   src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java  |  2

+-

   src/main/java/org/apache/commons/lang3/text/StrTokenizer.java  |  4

++--

   .../org/apache/commons/lang3/time/DurationFormatUtils.java |  2

+-

   .../java/org/apache/commons/lang3/time/FastDatePrinter.java|  2

+-

   .../commons/lang3/concurrent/EventCountCircuitBreakerTest.java |  2

+-

   10 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/src/main/java/org/apache/commons/lang3/CharSet.java
b/src/main/java/org/apache/commons/lang3/CharSet.java
index 3fdfd07..7955115 100644
--- a/src/main/java/org/apache/commons/lang3/CharSet.java
+++ b/src/main/java/org/apache/commons/lang3/CharSet.java
@@ -225,7 +225,7 @@ public class CharSet implements Serializable {
   // NOTE: This is no longer public as CharRange is no longer a public
class.
   //   It may be replaced when CharSet moves to Range.
   /*public*/ CharRange[] getCharRanges() {
-return set.toArray(new CharRange[set.size()]);
+return set.toArray(new CharRange[0]);
   }




//---

diff --git a/src/main/java/org/apache/commons/lang3/StringUtils.java
b/src/main/java/org/apache/commons/lang3/StringUtils.java
index abde7ec..d629806 100644
--- a/src/main/java/org/apache/commons/lang3/StringUtils.java
+++ b/src/main/java/org/apache/commons/lang3/StringUtils.java
@@ -7507,7 +7507,7 @@ public class StringUtils {
   currentType = type;
   }
   list.add(new String(c, tokenStart, c.length - tokenStart));
-return list.toArray(new String[list.size()]);
+return list.toArray(new String[0]);
   }

   /**
@@ -7735,7 +7735,7 @@ public class StringUtils {
   }
   }

-return substrings.toArray(new String[substrings.size()]);
+return substrings.toArray(new String[0]);
   }

   //
---
@@ -7923,7 +7923,7 @@ public class StringUtils {
   if (match || preserveAllTokens && lastMatch) {
   list.add(str.substring(start, i));
   }
-return list.toArray(new String[list.size()]);
+return list.toArray(new String[0]);
   }

   /**
@@ -8022,7 +8022,7 @@ public class StringUtils {
   if (match || preserveAllTokens && lastMatch) {
   list.add(str.substring(start, i));
   }
-return list.toArray(new String[list.size()]);
+return list.toArray(n

Re: [commons-lang] branch master updated: Use Collection#toArray(new T[0]) instead of a presized array as it is faster on modern JVMs.

[sebb]

As that article says in conclusion, T[0] seems currently faster, but that
may not always be the case with future VMs.

Also it says that IntelliJ IDEA and PMD recommend using T[size] rather than
T[0].
If we release code with T[0], I suspect we will get complaints that the
code is not efficient according to x, y and z.

I'm not convinced that the change is worth it, but if it is agreed the code
must be thoroughly documented to try and forestall complaints.
According to the article, using a constant empty array is faster, but only
marginally. If there is a constant available it would probably make sense
to use it.
This should also be documented, as it affects the return value for the
empty case.

S.
On Fri, 27 Dec 2019 at 09:28, Pascal Schumacher 
wrote:

> see https://shipilev.net/blog/2016/arrays-wisdom-ancients/
>
> Am 27.12.2019 um 01:24 schrieb sebb:
> > Also, where is it documented that modern JVMs are faster?
> > To which JVMs does this apply?
> >
> > S.
> >
> > On Thu, 26 Dec 2019 at 22:08, Gary Gregory 
> wrote:
> >
> >> Please do not cause garbage to apparently be generated all over the
> place
> >> by creating new empty arrays all the time. Use the constants Commons
> Lang
> >> constants already defines; see ArrayUtils.
> >>
> >> Gary
> >>
> >> On Thu, Dec 26, 2019 at 4:48 PM  wrote:
> >>
> >>> This is an automated email from the ASF dual-hosted git repository.
> >>>
> >>> pascalschumacher pushed a commit to branch master
> >>> in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> >>>
> >>>
> >>> The following commit(s) were added to refs/heads/master by this push:
> >>>   new 84668a2  Use Collection#toArray(new T[0]) instead of a
> presized
> >>> array as it is faster on modern JVMs.
> >>> 84668a2 is described below
> >>>
> >>> commit 84668a2d980316a580030fd64764cb072b520b09
> >>> Author: pascalschumacher 
> >>> AuthorDate: Thu Dec 26 22:48:12 2019 +0100
> >>>
> >>>  Use Collection#toArray(new T[0]) instead of a presized array as
> it is
> >>> faster on modern JVMs.
> >>> ---
> >>>   src/main/java/org/apache/commons/lang3/CharSet.java|  2
> +-
> >>>   src/main/java/org/apache/commons/lang3/StringUtils.java| 10
> >>> +-
> >>>   .../org/apache/commons/lang3/exception/ExceptionUtils.java |  6
> >> +++---
> >>>   src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java |  4
> ++--
> >>>   .../java/org/apache/commons/lang3/reflect/MethodUtils.java |  2
> +-
> >>>   src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java  |  2
> +-
> >>>   src/main/java/org/apache/commons/lang3/text/StrTokenizer.java  |  4
> ++--
> >>>   .../org/apache/commons/lang3/time/DurationFormatUtils.java |  2
> +-
> >>>   .../java/org/apache/commons/lang3/time/FastDatePrinter.java|  2
> +-
> >>>   .../commons/lang3/concurrent/EventCountCircuitBreakerTest.java |  2
> +-
> >>>   10 files changed, 18 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/src/main/java/org/apache/commons/lang3/CharSet.java
> >>> b/src/main/java/org/apache/commons/lang3/CharSet.java
> >>> index 3fdfd07..7955115 100644
> >>> --- a/src/main/java/org/apache/commons/lang3/CharSet.java
> >>> +++ b/src/main/java/org/apache/commons/lang3/CharSet.java
> >>> @@ -225,7 +225,7 @@ public class CharSet implements Serializable {
> >>>   // NOTE: This is no longer public as CharRange is no longer a public
> >>> class.
> >>>   //   It may be replaced when CharSet moves to Range.
> >>>   /*public*/ CharRange[] getCharRanges() {
> >>> -return set.toArray(new CharRange[set.size()]);
> >>> +return set.toArray(new CharRange[0]);
> >>>   }
> >>>
> >>>
> >>>
> >>
> //---
> >>> diff --git a/src/main/java/org/apache/commons/lang3/StringUtils.java
> >>> b/src/main/java/org/apache/commons/lang3/StringUtils.java
> >>> index abde7ec..d629806 100644
> >>> --- a/src/main/java/org/apache/commons/lang3/StringUtils.java
> >>> +++ b/src/main/java/org/apache/commons/lang3/StringUtils.java
> >>> @@ -7507,7 +7507,7 @@ public class StringUtils {
> >>>   currentType = type;
> >>>   }
> >>>   list.add(new String(c, tokenStart, c.length - tokenStart));
> >>> -return list.toArray(new String[list.size()]);
> >>> +return list.toArray(new String[0]);
> >>>   }
> >>>
> >>>   /**
> >>> @@ -7735,7 +7735,7 @@ public class StringUtils {
> >>>   }
> >>>   }
> >>>
> >>> -return substrings.toArray(new String[substrings.size()]);
> >>> +return substrings.toArray(new String[0]);
> >>>   }
> >>>
> >>>   //
> >>> ---
> >>> @@ -7923,7 +7923,7 @@ public class StringUtils {
> >>>   if (match || preserveAllTokens && lastMatch) {
> >>>   list.add(str.substring(start, i));
> >>>   }
> >>> -return list.toArray(new String[list.size()]);
> >>> + 

Re: [VOTE] Release Apache Commons VFS Project 2.5.0 based on RC1

[Bruno P. Kinoshita]

   [X] +1 Release these artifacts

Successfully built from tag, and from dist area source, using JDK8 on Ubuntu 
LTS.

Reports look good. Inspected a few files picked at random from maven staged 
repo and from dist area, all looks good.

Found nothing wrong looking at signatures from maven & dist. Thanks for RM'ing 
Gary.

Bruno

On Thursday, 26 December 2019, 9:32:36 am NZDT, Gary Gregory 
 wrote:  
 
 We have fixed quite a few bugs and added some significant enhancements
since Apache Commons VFS 2.4.1 was released, so I would like to release
Apache Commons VFS Project 2.5.0.

Apache Commons VFS Project 2.5.0 RC1 is available for review here:
    https://dist.apache.org/repos/dist/dev/commons/vfs/2.5.0-RC1 (svn
revision 37359)

The Git tag commons-vfs-2.5.0-RC1 commit for this RC is
7e093083ee20956a0367137f98b9beb12622e0d7 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-vfs.git;a=commit;h=7e093083ee20956a0367137f98b9beb12622e0d7
You may checkout this tag using:
    git clone https://gitbox.apache.org/repos/asf/commons-vfs.git --branch
commons-vfs-2.5.0-RC1 commons-vfs-2.5.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1482/org/apache/commons/

These are the artifacts and their hashes:

/org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0.jar
(SHA1: 6d6f7cca0670b390e98f9698561a79f3902670d8)
/org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0-sources.jar
(SHA1: b7767f2f579c91b091de6078f8d6f0b5e22b486a)
/org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0-test-sources.jar
(SHA1: e96e7d66ee99b62eba3f996d519d3441446f736a)
/org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0-javadoc.jar
(SHA1: 57095c16529baa6fccde11a4ed35be2baf706906)
/org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0-tests.jar
(SHA1: a15454f59add9be4ac8696433cbe4ec9d34967d8)
/org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0.pom
(SHA1: 03d6cee3cbd51d3a7344a4bb806d39ffd4578efa)
/org/apache/commons/commons-vfs2-jackrabbit2/2.5.0/commons-vfs2-jackrabbit2-2.5.0.jar.asc
(SHA1: 9f295f456665ec6a72875c0416ae39ece6037778)
/org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0-test-sources.jar
(SHA1: fce878fdf26a9190437f1246ab1f848e858b58b6)
/org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0-sources.jar
(SHA1: 495a0f4d1db066882df7033ac107841f28d90b62)
/org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0.pom
(SHA1: eb7d91205e065bc31b8f1465ed9170bc4725b6dc)
/org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0.jar
(SHA1: f58fb2fa00843aaa4cb69c7db46b44fe7299006b)
/org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0-javadoc.jar
(SHA1: 8be8d2b6e485b35d52de1a4beca9c8f532b7daa0)
/org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0-test-sources.jar.asc
(SHA1: 76f8ef9180fc0aceea2fc63ddd81f103f409a322)
/org/apache/commons/commons-vfs2-jackrabbit1/2.5.0/commons-vfs2-jackrabbit1-2.5.0-tests.jar
(SHA1: 65cdbb7babbf6ed014aff4f858d8fd1268ec4a65)
/org/apache/commons/commons-vfs2-distribution/2.5.0/commons-vfs2-distribution-2.5.0.pom
(SHA1: e760f854c22e200acf36bba281d22ed9c7c0ef4a)
/org/apache/commons/commons-vfs2/2.5.0/commons-vfs2-2.5.0-javadoc.jar
(SHA1: 53cb47e9af18a3cb00ee03d47f53b3cb99dc977c)
/org/apache/commons/commons-vfs2/2.5.0/commons-vfs2-2.5.0-sources.jar
(SHA1: 4f41fb7956ca972094987e2a4774b15d32126767)
/org/apache/commons/commons-vfs2/2.5.0/commons-vfs2-2.5.0-tests.jar
(SHA1: a1ce843cd2de5d7848eb683ac731adaa53bac9ed)
/org/apache/commons/commons-vfs2/2.5.0/commons-vfs2-2.5.0.jar
(SHA1: c3c68acdc39943b830eb691069e5570f09586173)
/org/apache/commons/commons-vfs2/2.5.0/commons-vfs2-2.5.0.pom
(SHA1: 5eda2e90c21b4435e5b365836098830eadbdad2e)
/org/apache/commons/commons-vfs2/2.5.0/commons-vfs2-2.5.0-test-sources.jar
(SHA1: 99710f56b7112879e90ca2ee8d4c455a98ab1a5f)
/org/apache/commons/commons-vfs2-project/2.5.0/commons-vfs2-project-2.5.0.pom
(SHA1: 278484a5f55f63de7056449a319a78c35ff95e4b)
/org/apache/commons/commons-vfs2-project/2.5.0/commons-vfs2-project-2.5.0-site.xml
(SHA1: b364640391ebedadd05f7371806938f947df3acb)
/org/apache/commons/commons-vfs2-examples/2.5.0/commons-vfs2-examples-2.5.0-javadoc.jar
(SHA1: 46a5716f6bd6aeff21d0c119e9114e8cbdfeedce)
/org/apache/commons/commons-vfs2-examples/2.5.0/commons-vfs2-examples-2.5.0.pom
(SHA1: 2c9ad0b45acdba127c2fdc381a78e9ed7539c2c0)
/org/apache/commons/commons-vfs2-examples/2.5.0/commons-vfs2-examples-2.5.0-sources.jar
(SHA1: 267ab8fa3f07479976fac056d140062aa0e7208b)
/org/apache/commons/commons-vfs2-examples/2.5.0/commons-vfs2-examples-2.5.0.jar
(SHA1: b8aec93cf4f17bd5481907176b3dfc80d8856adc)

I have tested this with:

mvn -V -Duser.name=%my_apache_id%
-Dcommons.release-plugin.version=%com

Re: [commons-lang] branch master updated: Use Collection#toArray(new T[0]) instead of a presized array as it is faster on modern JVMs.

[Pascal Schumacher]

see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

Am 27.12.2019 um 01:24 schrieb sebb:

Also, where is it documented that modern JVMs are faster?
To which JVMs does this apply?

S.

On Thu, 26 Dec 2019 at 22:08, Gary Gregory  wrote:


Please do not cause garbage to apparently be generated all over the place
by creating new empty arrays all the time. Use the constants Commons Lang
constants already defines; see ArrayUtils.

Gary

On Thu, Dec 26, 2019 at 4:48 PM  wrote:


This is an automated email from the ASF dual-hosted git repository.

pascalschumacher pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-lang.git


The following commit(s) were added to refs/heads/master by this push:
  new 84668a2  Use Collection#toArray(new T[0]) instead of a presized
array as it is faster on modern JVMs.
84668a2 is described below

commit 84668a2d980316a580030fd64764cb072b520b09
Author: pascalschumacher 
AuthorDate: Thu Dec 26 22:48:12 2019 +0100

 Use Collection#toArray(new T[0]) instead of a presized array as it is
faster on modern JVMs.
---
  src/main/java/org/apache/commons/lang3/CharSet.java|  2 +-
  src/main/java/org/apache/commons/lang3/StringUtils.java| 10
+-
  .../org/apache/commons/lang3/exception/ExceptionUtils.java |  6

+++---

  src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java |  4 ++--
  .../java/org/apache/commons/lang3/reflect/MethodUtils.java |  2 +-
  src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java  |  2 +-
  src/main/java/org/apache/commons/lang3/text/StrTokenizer.java  |  4 ++--
  .../org/apache/commons/lang3/time/DurationFormatUtils.java |  2 +-
  .../java/org/apache/commons/lang3/time/FastDatePrinter.java|  2 +-
  .../commons/lang3/concurrent/EventCountCircuitBreakerTest.java |  2 +-
  10 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/src/main/java/org/apache/commons/lang3/CharSet.java
b/src/main/java/org/apache/commons/lang3/CharSet.java
index 3fdfd07..7955115 100644
--- a/src/main/java/org/apache/commons/lang3/CharSet.java
+++ b/src/main/java/org/apache/commons/lang3/CharSet.java
@@ -225,7 +225,7 @@ public class CharSet implements Serializable {
  // NOTE: This is no longer public as CharRange is no longer a public
class.
  //   It may be replaced when CharSet moves to Range.
  /*public*/ CharRange[] getCharRanges() {
-return set.toArray(new CharRange[set.size()]);
+return set.toArray(new CharRange[0]);
  }




//---

diff --git a/src/main/java/org/apache/commons/lang3/StringUtils.java
b/src/main/java/org/apache/commons/lang3/StringUtils.java
index abde7ec..d629806 100644
--- a/src/main/java/org/apache/commons/lang3/StringUtils.java
+++ b/src/main/java/org/apache/commons/lang3/StringUtils.java
@@ -7507,7 +7507,7 @@ public class StringUtils {
  currentType = type;
  }
  list.add(new String(c, tokenStart, c.length - tokenStart));
-return list.toArray(new String[list.size()]);
+return list.toArray(new String[0]);
  }

  /**
@@ -7735,7 +7735,7 @@ public class StringUtils {
  }
  }

-return substrings.toArray(new String[substrings.size()]);
+return substrings.toArray(new String[0]);
  }

  //
---
@@ -7923,7 +7923,7 @@ public class StringUtils {
  if (match || preserveAllTokens && lastMatch) {
  list.add(str.substring(start, i));
  }
-return list.toArray(new String[list.size()]);
+return list.toArray(new String[0]);
  }

  /**
@@ -8022,7 +8022,7 @@ public class StringUtils {
  if (match || preserveAllTokens && lastMatch) {
  list.add(str.substring(start, i));
  }
-return list.toArray(new String[list.size()]);
+return list.toArray(new String[0]);
  }

  /**
@@ -8835,7 +8835,7 @@ public class StringUtils {
  if (list.isEmpty()) {
  return null;
  }
-return list.toArray(new String[list.size()]);
+return list.toArray(new String[0]);
  }

  /**
diff --git
a/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java
b/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java
index 5969614..dd154e3 100644
---

a/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java

+++

b/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java

@@ -274,7 +274,7 @@ public class ExceptionUtils {
  }
  frames.addAll(trace);
  }
-return frames.toArray(new String[frames.size()]);
+return frames.toArray(new String[0]);
  }

  /**
@@ -325,7 +325,7 @@ public class ExceptionUtils {
  while (frames.hasMoreTokens()) {
  list.add(frames.nextToken());
  }