Re: [CRYPTO] Progress with macOS and Windows

[sebb]

On Mon, 4 Jul 2022 at 17:20, sebb  wrote:
>
> The JNA code should now be able to support all combinations of methods.
>
> Also JNA supports the property jna.library.path when loading the crypto 
> library.
> This allows one to override the default which may not be the same as
> the default OpenSSL version. e.g. the GH action builds default to
> OpenSSL 1.1.1, but the default crypto library is LibreSSL 2.x.
>
> The override works fine on macOS, but I have yet to find the correct
> value on Windows.
>
> JNI works OK on all OSes, but the default crypto library it uses may
> be different from the OpenSSL version. So far have not found out how
> to override the default successfully when the Commons native code is
> invoked as part of a Java app. It looks like the environment variables
> that work for non-Java apps are not passed to the native code.

Turns out that macOS System Integrity Protection [1] purges the
environment variables that can be used to affect the dynamic loader.
It seems the only way to override the default is to provide the path to dlopen.

Unfortunately there are 3 separate files that contain the dlopen code.

> Sebb

[1] 
https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html

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

Re: [numbers][gsoc] GSoC 2022 - NUMBERS-186 Proposal

[Sumanth Rajkumar]

Thanks Alex for PR feedback.
I have incorporated the majority of the requested changes to the PR.

I would like to discuss the remaining points here.

> In
commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/ComplexUnaryOperator.java:
> Note that by making this a default that creates an instance of Complex
you impose memory allocation overhead to any call site that just has the
real and imaginary parts (e.g. a structure storing a list of complex
numbers using primitive arrays).
> The ComplexDouble apply(ComplexDouble in,
ComplexConstructor out) method should be a default that
calls this function using the real and imaginary parts.

The existing unit test for Complex Projection (proj) is expecting the
returned result to be the same as the passed input Complex instance except
for the isInfinite edge case.
This was the main reason for making the functional interface accept a
ComplexDouble instead of primitive real and imaginary parts.

The additional memory allocation for the input can be eliminated (for the
example of primitive array backed lists), by combining it with the
constructed result object.
We had decided to incur the overhead for the complex Constructor
result object in the context of functional compositions and thread safety
discussion before.
So, passing in a cursor iterator item (that captures the index) as both
ComplexDouble input and ComplexResult constructor should avoid any
additional overhead?

If we decide to use primitive types for the functional interface, then we
cannot use it for the projection method.


> @FunctionalInterface
>  public interface ComplexScalarFunction {
>
> ComplexDouble apply(ComplexDouble c, double f,
ComplexConstructor result);
>
> }
> This interface should be typed: the result is accepted by the
ComplexConstructor and this can be typed.


By typed, did you mean to make this a generic interface
ComplexScalarFunction
?
ComplexUnaryOperator and ComplexBinaryOperator are not generic and
constrained to ComplexDouble types


> It may be wise to update the test suite to ensure that all tests
currently applied to Complex are applied to ComplexFunctions using a
ComplexConstructor other than Complex, for example using a dummy
implementation:
>
> class ComplexNumber implements ComplexConstructor {
>// (r, i) members
>
>@Override
>public ComplexNumber apply(double r, double i) {
>// store (r, i) ...
>return this;
>}
> }
>
>This will detect the edge cases all pass through to the input constructor
to create the result. The test should assert the ComplexConstructor
received the expected values.

For now, shall I copy all the tests from the CStandardTest, CReferenceTest
and ComplexEdgeCaseTest to ComplexFunctionsTest and modify it to use a
dummy constructor?
Also please note as mentioned above for the complex.proj method, currently
we are not invoking the complex constructor for normal cases.

Re: [collections] JMH results for IndexedLinkedList

[Matt Juntunen]

Thanks, rodde! I should have some time this week to take a closer
look. I plan on playing with the benchmarks a bit on my own. I'll let
you know what I find.

Regards,
Matt J

On Mon, Jul 4, 2022 at 4:53 AM Rodion Efremov  wrote:
>
> Hi Matt and community,
>
> I have compiled the benchmark result data into 3 tables [1] (three
> different load sizes) [2]. If nothing else, IndexedLiinkedList (called
> RoddeList in output) is faster than both java.util.LinkedList and TreeList.
>
> If, for further discussion, you require something else, please let me know.
>
> Best regards,
> rodde
>
> [1] https://github.com/coderodde/indexedLinkedList/#benchmark-with-jmh
> [2]
> https://github.com/coderodde/IndexedLinkedListBenchmark/blob/main/src/main/java/com/coderodde/IndexedLinkedListPerformance.java
>
> On Fri, Jul 1, 2022 at 6:11 AM Matt Juntunen 
> wrote:
>
> > Hello rodde,
> >
> > Thank you for sending me a reminder on this. Unfortunately, I haven't
> > had time to look at the code yet. Gilles suggestions are something I
> > would like to see as well. Having tables of JMH results for the
> > different algorithms at different sizes would be very helpful.
> >
> > Regards,
> > Matt J
> >
> > On Thu, Jun 30, 2022 at 11:34 AM Gilles Sadowski 
> > wrote:
> > >
> > > Hello.
> > >
> > > Le jeu. 30 juin 2022 à 07:54, Rodion Efremov  a
> > écrit :
> > > >
> > > > Hi Matt and community,
> > > >
> > > > Have you take a look at my work? If so, what do you think?
> > >
> > > Perhaps you missed that feedback:
> > >   https://markmail.org/message/y3tozjdke2ivz3dr
> > >
> > > >
> > > > Best regards,
> > > > rodde
> > > >
> > > > to 23.6.2022 klo 19.06 Matt Juntunen 
> > kirjoitti:
> > > >
> > > > > Hello,
> > > > >
> > > > > Thanks for providing the data here. I will hopefully have time to
> > take
> > > > > a look at this over the weekend. Send me a ping here on the dev list
> > > > > if you don't hear back from me (or someone else) within a week.
> > > > >
> > > > > Regards,
> > > > > Matt J
> > > > >
> > > > > On Tue, Jun 21, 2022 at 7:22 AM Rodion Efremov 
> > > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Data structure: IndexedLinkedList
> > > > > > 
> > > > > > Benchmark: IndexedLinkedListBenchmark
> > > > > > 
> > > > > >
> > > > > > Benchmark output:
> > > > > > https://github.com/coderodde/indexedLinkedList/#benchmark-output
> > > > > >
> > > > > > From the benchmark output, we can judge that IndexedLinkedList
> > > > > outperforms
> > > > > > both java.util.LinkedList and the Apache Commons Collections
> > TreeList.
> > > > > It,
> > > > > > however, does not seem to supersede the java.util.ArrayList.
> > > > > >
> > > > > > Basically, I would expect the IndexedLinkedList to beat the
> > ArrayList
> > > > > where
> > > > > > we have a lot of following operations:
> > > > > >
> > > > > >- addFirst(E)
> > > > > >- add(int, E)
> > > > > >- remove(int)
> > > > > >
> > > > > > So, what do you think? I am getting anywhere with that?
> > > > > >
> > > > > > Best regards,
> > > > > > rodde
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

[CRYPTO] Progress with macOS and Windows

[sebb]

The JNA code should now be able to support all combinations of methods.

Also JNA supports the property jna.library.path when loading the crypto library.
This allows one to override the default which may not be the same as
the default OpenSSL version. e.g. the GH action builds default to
OpenSSL 1.1.1, but the default crypto library is LibreSSL 2.x.

The override works fine on macOS, but I have yet to find the correct
value on Windows.

JNI works OK on all OSes, but the default crypto library it uses may
be different from the OpenSSL version. So far have not found out how
to override the default successfully when the Commons native code is
invoked as part of a Java app. It looks like the environment variables
that work for non-Java apps are not passed to the native code.

Sebb

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

[ANNOUNCEMENT] Apache Commons Configuration Version 2.8.0 Released

[Matt Juntunen]

The Apache Commons Team is pleased to announce the availability of
version 2.8.0 of "Apache Commons Configuration".

Apache Commons Configuration contains tools to assist in the reading of
configuration/preferences files in various formats.

Changes in this version include:

New features:
o Implement Iterable in ImmutableNode #74. Thanks to SethiPandi.
o Add PropertiesConfigurationLayout.getBlankLinesBefore() and deprecate
  getBlancLinesBefore(). Thanks to Gary Gregory.
o Add PropertiesConfigurationLayout.setBlankLinesBefore() and deprecate
  setBlancLinesBefore(). Thanks to Gary Gregory.
o Add PropertiesConfigurationLayout.PropertyLayoutData.getBlankLines() and
  deprecate getBlancLines(). Thanks to Gary Gregory.
o Add PropertiesConfigurationLayout.PropertyLayoutData.setBlankLines() and
  deprecate setBlancLines(). Thanks to Gary Gregory.
o CONFIGURATION-789:  Add ImmutableConfiguration.getEnum() methods. Thanks to
  Gary Gregory.
o CONFIGURATION-789:  Add ImmutableConfiguration.getDuration() methods. Thanks
  to Gary Gregory.

Fixed Bugs:
o CONFIGURATION-753:  Make interpolation of collections and arrays in
  ConfigurationInterpolator consistent with behavior of
  DefaultConversionHandler. Add ConfigurationInterpolator.setStringConverter to
  allow customized string conversion behavior.
o CONFIGURATION-795:  Computation of blank lines after header comment #82.
  Thanks to dpeger.
o CONFIGURATION-801:  Remove redundant initializer #110. Thanks to
  Arturo Bernal.
o CONFIGURATION-802:  Use final #111. Thanks to Arturo Bernal.
o CONFIGURATION-803:  Java 8 lambda improvements and more #112. Thanks to
  Arturo Bernal.
o CONFIGURATION-804:  Redundant local variable #113. Thanks to Arturo Bernal.
o CONFIGURATION-805:  Use try with resource #114. Thanks to Arturo Bernal.
o CONFIGURATION-805:  [Javadoc] Specify that typed getList returns null for
  missing key #100. Thanks to Roman Zaynetdinov.
o Mention EnvironmentConfiguration in the list of configuration sources #45.
  Thanks to Oliver B. Fischer.
o CONFIGURATION-808:  DefaultListDelimiterHandler.escapeList working only for
  List>String< #137. Thanks to cigaly.
o Use final #141. Thanks to Arturo Bernal.
o Replace test asserts by simpler but equivalent calls. #139 Thanks to
  Arturo Bernal.
o CONFIGURATION-764:  Single Variable Interpolation #182. Thanks to Ning Zhang,
  Matt Juntunen, Bruno P. Kinoshita, Gary Gregory.
o Implement proper concurrency in ConstantLookup. Thanks to Gary Gregory.
o CONFIGURATION-813:  Support new namespace jakarta.mail.* used by javamail 2.0+
  (first release October 2020) #186. Thanks to Dependabot.

Changes:
o Unclosed file handle when reading config from JAR file URL. Add and use
  FileBasedBuilderProperties.setURL(URL, URLConnectionOptions). Thanks to
  Robin Jansohn, Gary Gregory, Rob Spoor.
o Make default interpolation prefix lookups configurable via system property.
  Remove dns, url, and script lookups from defaults. If these lookups are
  required for use in AbstractConfiguration subclasses, they must be enabled
  via system property. See ConfigurationInterpolator.getDefaultPrefixLookups()
  for details.
o Bump actions/cache from 2 to 3.0.4 #99, #151, #169. Thanks to Dependabot,
  Gary Gregory.
o Bump actions/checkout from 1 to 3 #47, #62, #70, #85, #150, #163. Thanks to
  Dependabot.
o Bump actions/setup-java from 1.4.0 to 3 #63, #65, #73, #174. Thanks to
  Dependabot, Gary Gregory.
o Bump codeql-action from v1 to v2. Thanks to Dependabot, Matt Juntunen.
o Bump Spring dependency versions:
org.springframework:spring-beans 4.3.26.RELEASE -> 5.3.21
org.springframework:spring-context 4.3.26.RELEASE -> 5.3.21
org.springframework:spring-core 4.3.26.RELEASE -> 5.3.21
org.springframework:spring-test 4.3.26.RELEASE -> 5.3.21
#165, #172 Thanks to Dependabot, Matt Juntunen, kinow, Gary Gregory.
o Bump commons-parent from 52 to 53. Thanks to Dependabot, Matt Juntunen.
o CONFIGURATION-787:  Bump Apache Commons Lang from 3.9 to 3.12.0. Thanks to
  Gary Gregory.
o CONFIGURATION-790:  Bump com.fasterxml.jackson.core:jackson-databind
  from 2.10.3 to 2.13.3, #60. Thanks to Gary Gregory, Dependabot.
o Bump Slf4j test dependencies:
org.slf4j:slf4j-api 1.7.26 -> 1.7.33,
org.slf4j:slf4j-ext 1.7.26 -> 1.7.33,
org.slf4j:slf4j-log4j12 1.7.26 -> 1.7.33,
org.slf4j:slf4j-nop 1.7.26 -> 1.7.33. Thanks to Gary Gregory.
o Bump commons-parent from 50 to 52. Thanks to Dependabot.
o Bump mailapi from 1.6.4 to 1.6.7 #48. Thanks to Dependabot, Gary Gregory.
o Bump spotbugs-maven-plugin from 3.1.12.2 to 4.7.0.0, #55, #75, #79, #93, #116,
  #183. Thanks to Dependabot, Gary Gregory.
o Bump hsqldb from 2.5.0 to 2.5.2 #54, #128. Thanks to Dependabot.
o Bump commons-text from 1.8 to 1.9. Thanks to Gary Gregory.
o Bump servlet-api from 2.4 to 2.5 #58. Thanks to Gary Gregory.
o Bump maven-checkstyle-plugin from 3.1.0 to 3.1.2, #57, #97. Thanks to
  Gary Gregory.
o Bump commons-pool2 from 2.8.0 to 2.10.0, #61, #124. Thanks to 

Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3

[Matt Juntunen]

Hello Alex,

That would remove those files from the javadoc completely. As of now,
the generated files are included in the javadoc [1]. These files are
part of the public API (per previous releases) so I don't believe we
would want them undocumented.

Regards,
Matt J

[1] https://commons.apache.org/proper/commons-configuration/apidocs/index.html

On Mon, Jul 4, 2022 at 3:14 AM Alex Herbert  wrote:
>
> On Mon, 4 Jul 2022 at 03:41, Matt Juntunen 
> wrote:
>
> > I'm not sure what to do
> > about the javadoc warnings on the generated classes. From the comments
> > in the pom, this seems to have been an issue since v2.4.
> >
>
>   
> **/generated/*.java
>   
>
> Or whatever path is suitable [1].
>
> Alex
>
> [1]
> https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#sourceFileExcludes

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

Re: [commons-dbcp] branch master updated: org.apache.commons.dbcp2.datasources.UserPassKey should be Serializable (SpotBugs)

[Gary Gregory]

Could be, I see that my git autocrlf setting is false for that repo on my
Windows box.

Gary

On Mon, Jul 4, 2022, 05:32 Mark Thomas  wrote:

> Gary,
>
> A couple of your DBCP commits seem to be much bigger than they should
> be. Is there some sort of line ending issue going on?
>
> Mark
>
>
>
> On 02/07/2022 14:39, ggreg...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ggregory pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-dbcp.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >   new 20b0c930 org.apache.commons.dbcp2.datasources.UserPassKey
> should be Serializable (SpotBugs)
> > 20b0c930 is described below
> >
> > commit 20b0c930e2e329dfb9e318499a7b39dc931cdb9e
> > Author: Gary Gregory 
> > AuthorDate: Sat Jul 2 09:39:30 2022 -0400
> >
> >  org.apache.commons.dbcp2.datasources.UserPassKey should be
> Serializable
> >  (SpotBugs)
> > ---
> >   src/changes/changes.xml|   3 +
> >   .../commons/dbcp2/datasources/CharArray.java   |   5 +-
> >   .../commons/dbcp2/datasources/TestUserPassKey.java | 150
> +++--
> >   3 files changed, 85 insertions(+), 73 deletions(-)
> >
> > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > index 858bc0d7..d3971a98 100644
> > --- a/src/changes/changes.xml
> > +++ b/src/changes/changes.xml
> > @@ -83,6 +83,9 @@ The  type attribute can be
> add,update,fix,remove.
> > 
> >   Connection level JMX queries result in concurrent access to
> connection objects, causing errors #179
> > 
> > +  
> > +UserPassKey should be Serializable.
> > +  
> > 
> > 
> >   Add and use AbandonedTrace#setLastUsed(Instant).
> > diff --git
> a/src/main/java/org/apache/commons/dbcp2/datasources/CharArray.java
> b/src/main/java/org/apache/commons/dbcp2/datasources/CharArray.java
> > index f1d9c2aa..6581232e 100644
> > --- a/src/main/java/org/apache/commons/dbcp2/datasources/CharArray.java
> > +++ b/src/main/java/org/apache/commons/dbcp2/datasources/CharArray.java
> > @@ -17,6 +17,7 @@
> >
> >   package org.apache.commons.dbcp2.datasources;
> >
> > +import java.io.Serializable;
> >   import java.util.Arrays;
> >
> >   import org.apache.commons.dbcp2.Utils;
> > @@ -29,7 +30,9 @@ import org.apache.commons.dbcp2.Utils;
> >*
> >* @since 2.9.0
> >*/
> > -final class CharArray {
> > +final class CharArray implements Serializable {
> > +
> > +private static final long serialVersionUID = 1L;
> >
> >   static final CharArray NULL = new CharArray((char[]) null);
> >
> > diff --git
> a/src/test/java/org/apache/commons/dbcp2/datasources/TestUserPassKey.java
> b/src/test/java/org/apache/commons/dbcp2/datasources/TestUserPassKey.java
> > index 899510f2..c8b8555e 100644
> > ---
> a/src/test/java/org/apache/commons/dbcp2/datasources/TestUserPassKey.java
> > +++
> b/src/test/java/org/apache/commons/dbcp2/datasources/TestUserPassKey.java
> > @@ -1,72 +1,78 @@
> > -/*
> > - * Licensed to the Apache Software Foundation (ASF) under one or more
> > - * contributor license agreements.  See the NOTICE file distributed with
> > - * this work for additional information regarding copyright ownership.
> > - * The ASF licenses this file to You under the Apache License, Version
> 2.0
> > - * (the "License"); you may not use this file except in compliance with
> > - * the License.  You may obtain a copy of the License at
> > - *
> > - *  http://www.apache.org/licenses/LICENSE-2.0
> > - *
> > - * Unless required by applicable law or agreed to in writing, software
> > - * distributed under the License is distributed on an "AS IS" BASIS,
> > - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> > - * See the License for the specific language governing permissions and
> > - * limitations under the License.
> > - */
> > -
> > -package org.apache.commons.dbcp2.datasources;
> > -
> > -import static org.junit.jupiter.api.Assertions.assertArrayEquals;
> > -import static org.junit.jupiter.api.Assertions.assertEquals;
> > -import static org.junit.jupiter.api.Assertions.assertNotEquals;
> > -
> > -import org.apache.commons.dbcp2.Utils;
> > -import org.junit.jupiter.api.BeforeEach;
> > -import org.junit.jupiter.api.Test;
> > -
> > -/**
> > - * Tests for UserPassKey.
> > - * @since 2.5.0
> > - */
> > -public class TestUserPassKey {
> > -
> > -private UserPassKey userPassKey;
> > -private UserPassKey anotherUserPassKey;
> > -
> > -@BeforeEach
> > -public void setUp() {
> > -userPassKey = new UserPassKey("user", "pass");
> > -anotherUserPassKey = new UserPassKey((String) null, "");
> > -}
> > -
> > -@Test
> > -public void testEquals() {
> > -assertEquals(new UserPassKey("user"), new UserPassKey("user",
> (char[]) null));
> > -assertEquals(userPassKey, userPassKey);
> > - 

Re: [commons-dbcp] branch master updated: LifetimeExceededException should extend SQLException.

[Gary Gregory]

Fixed, TY!

Gary

On Mon, Jul 4, 2022, 06:05 Mark Thomas  wrote:

> On 03/07/2022 15:37, ggreg...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ggregory pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-dbcp.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >   new 09677c3e LifetimeExceededException should extend SQLException.
> > 09677c3e is described below
> >
> > commit 09677c3e674894cffe2f9ebeaa7e562792f658a4
> > Author: Gary Gregory 
> > AuthorDate: Sun Jul 3 10:37:23 2022 -0400
> >
> >  LifetimeExceededException should extend SQLException.
> > ---
> >   src/changes/changes.xml|  1 +
> >   .../commons/dbcp2/LifetimeExceededException.java   | 88
> +++---
> >   2 files changed, 46 insertions(+), 43 deletions(-)
> >
> > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > index 117256bf..73226f9c 100644
> > --- a/src/changes/changes.xml
> > +++ b/src/changes/changes.xml
> > @@ -86,6 +86,7 @@ The  type attribute can be
> add,update,fix,remove.
> > 
> >   UserPassKey should be Serializable.
> > 
> > +LifetimeExceededException should extend SQLException.
>
> Gary,
>
> This breaks the XML. You need to add the tags.
>
> Mark
>

Re: [collections] JMH results for IndexedLinkedList

[Rodion Efremov]

Hi Matt and community,

I have compiled the benchmark result data into 3 tables [1] (three
different load sizes) [2]. If nothing else, IndexedLiinkedList (called
RoddeList in output) is faster than both java.util.LinkedList and TreeList.

If, for further discussion, you require something else, please let me know.

Best regards,
rodde

[1] https://github.com/coderodde/indexedLinkedList/#benchmark-with-jmh
[2]
https://github.com/coderodde/IndexedLinkedListBenchmark/blob/main/src/main/java/com/coderodde/IndexedLinkedListPerformance.java

On Fri, Jul 1, 2022 at 6:11 AM Matt Juntunen 
wrote:

> Hello rodde,
>
> Thank you for sending me a reminder on this. Unfortunately, I haven't
> had time to look at the code yet. Gilles suggestions are something I
> would like to see as well. Having tables of JMH results for the
> different algorithms at different sizes would be very helpful.
>
> Regards,
> Matt J
>
> On Thu, Jun 30, 2022 at 11:34 AM Gilles Sadowski 
> wrote:
> >
> > Hello.
> >
> > Le jeu. 30 juin 2022 à 07:54, Rodion Efremov  a
> écrit :
> > >
> > > Hi Matt and community,
> > >
> > > Have you take a look at my work? If so, what do you think?
> >
> > Perhaps you missed that feedback:
> >   https://markmail.org/message/y3tozjdke2ivz3dr
> >
> > >
> > > Best regards,
> > > rodde
> > >
> > > to 23.6.2022 klo 19.06 Matt Juntunen 
> kirjoitti:
> > >
> > > > Hello,
> > > >
> > > > Thanks for providing the data here. I will hopefully have time to
> take
> > > > a look at this over the weekend. Send me a ping here on the dev list
> > > > if you don't hear back from me (or someone else) within a week.
> > > >
> > > > Regards,
> > > > Matt J
> > > >
> > > > On Tue, Jun 21, 2022 at 7:22 AM Rodion Efremov 
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Data structure: IndexedLinkedList
> > > > > 
> > > > > Benchmark: IndexedLinkedListBenchmark
> > > > > 
> > > > >
> > > > > Benchmark output:
> > > > > https://github.com/coderodde/indexedLinkedList/#benchmark-output
> > > > >
> > > > > From the benchmark output, we can judge that IndexedLinkedList
> > > > outperforms
> > > > > both java.util.LinkedList and the Apache Commons Collections
> TreeList.
> > > > It,
> > > > > however, does not seem to supersede the java.util.ArrayList.
> > > > >
> > > > > Basically, I would expect the IndexedLinkedList to beat the
> ArrayList
> > > > where
> > > > > we have a lot of following operations:
> > > > >
> > > > >- addFirst(E)
> > > > >- add(int, E)
> > > > >- remove(int)
> > > > >
> > > > > So, what do you think? I am getting anywhere with that?
> > > > >
> > > > > Best regards,
> > > > > rodde
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons Configuration 2.8.0 based on RC3

[Alex Herbert]

On Mon, 4 Jul 2022 at 03:41, Matt Juntunen 
wrote:

> I'm not sure what to do
> about the javadoc warnings on the generated classes. From the comments
> in the pom, this seems to have been an issue since v2.4.
>

  
**/generated/*.java
  

Or whatever path is suitable [1].

Alex

[1]
https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#sourceFileExcludes