Re: [COLLECTIONS] Test failures on Windows

[Bruno P. Kinoshita]

Still investigating. Trying to isolate the problem 
https://github.com/kinow/commons-collections/tree/COLLECTIONS-661-1

No luck so far. I have an environment where it happens over 90% of the time. 
Tried debugging a few times, adding some sysout statements to see if there was 
anything suspect... yesterday enabled findbugs in test to look for any issue in 
the test classes. Nothing yet.

Bruno

  From: Gary Gregory 
 To: Commons Developers List  
 Sent: Wednesday, 11 October 2017 12:13 PM
 Subject: Re: [COLLECTIONS] Test failures on Windows
   
Where are we on this one?

Gary

On Mon, Oct 2, 2017 at 3:34 AM, Pascal Schumacher 
wrote:

> Looks like the random failures are not limited to window. The travis build
> (ubuntu), just failed with 44 failures, e.g.
>
> AbstractMultiValuedMapTest$TestMultiValuedMapAsMap>AbstractM
> apTest.testMapToString:745->AbstractMapTest.verify:1947->AbstractMapTest.verifyMap:1958
> hashCodes should be the same expected:<205172737> but was:<9372706>
>
>
> see: https://travis-ci.org/apache/commons-collections/jobs/282169803
>
>
> Am 28.09.2017 um 20:23 schrieb Andreas Kuhtz:
>
>> Hi,
>>
>> 2017-09-27 22:28 GMT+02:00 Bruno P. Kinoshita :
>>
>> Forgot to mention something important. When I was debugging the hash
>>> tests, they would pretty much always pass.
>>>
>>> But if I ran the tests normally in maven or eclipse they would always
>>> fail.
>>>
>>> Debugging adds a small overhead I think, that could be slowing down some
>>> part of the code with a concurrency issue?
>>>
>>> That's an explanation. If I start a Virtualbox instance that prepares
>> some
>> load I can see the tests pass under Java 9 ... I had the Virtualbox
>> running
>> yesterday when the tests passed.
>>
>>
>> Just in case it helps...
>>>
>>> Interesting this surefire configuration Andreas. Do you have more
>>> information about it? Is it something we may have to worry about in
>>> components that use locale and jvm 9?
>>>
>>> I ran into an issue with the language selection dialog of izpack and
>> found
>> that this configuration solved the problem there.
>> It's noted in the release notes of Java 9:
>> http://www.oracle.com/technetwork/java/javase/9-relnote-
>> issues-3704069.html#JDK-8008577
>>
>> Cheers,
>> Andreas
>>
>>
>> Cheers
>>> Bruno
>>>
>>> Sent from Yahoo Mail on Android
>>> 
>>>
>>> On Thu, 28 Sep 2017 at 4:45, Andreas Kuhtz
>>>  wrote:
>>> Hi,
>>>
>>> I'm running Win7 and with "mvn clean verify". Checkout master.
>>>
>>> I got the hash code errors, too. But sometimes the tests pass, the next
>>> time they failed with 44 failures (the hash code verification).
>>>
>>> As I'm not sure if my antivirus kicks in and keep some files in the
>>> target
>>> dir, I ran "mvn clean" and after that "mvn clean verify".
>>> But now I have the 44 failures with jdk-1.7.0_67, jdk-1.8.0_131 and 9+181
>>>
>>> Gary:
>>> To get around the issue with ServiceConfiguration sun.util.locale...  I
>>> added the following profile to the pom.xml. After that I only got the 44
>>> errors (hash code) as with Java 7 and 8.
>>>
>>>      
>>>        jdk9-build
>>>        
>>>          9
>>>        
>>>        
>>>          
>>>            
>>>              maven-surefire-plugin
>>>              
>>>                -Djava.locale.providers=COMPAT
>>>              
>>>            
>>>          
>>>        
>>>      
>>>
>>> I'm not sure if I can help more, but if you need more info just let me
>>> know.
>>>
>>> Andreas
>>>
>>> 2017-09-27 19:10 GMT+02:00 Gary Gregory :
>>>
>>> Using git master and 'mvn clean verify', on Windows 10, with Java 7, I

>>> get
>>>
 44 failures, and I think this is all/mostly hash code problems.

 With Java 8, all tests pass.

 With Java 9, I get ONE failure: ListIteratorWrapperTest.testRemove:116
 ╗
 ServiceConfiguration sun.util.locale

 If I checkout the 4.1 tag and use Java 7, I get 44 failures. ARG! What

>>> the
>>>
 heck?

 Gary



 On Mon, Sep 25, 2017 at 12:02 PM, Benedikt Ritter 
 wrote:

 Hi,
>
> who can help with the test failures on Windows? I’d like to push out
>
 the
>>>
 next release soon to get Collections Java 9 ready. I don’t have access
>
 to a

> Windows installation and I don’t feel like debugging inside a VM :o)
>
> Regards,
> Benedikt
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
>
>>>
>

   

Re: [COLLECTIONS] Test failures on Windows

[Gary Gregory]

Where are we on this one?

Gary

On Mon, Oct 2, 2017 at 3:34 AM, Pascal Schumacher 
wrote:

> Looks like the random failures are not limited to window. The travis build
> (ubuntu), just failed with 44 failures, e.g.
>
> AbstractMultiValuedMapTest$TestMultiValuedMapAsMap>AbstractM
> apTest.testMapToString:745->AbstractMapTest.verify:1947->AbstractMapTest.verifyMap:1958
> hashCodes should be the same expected:<205172737> but was:<9372706>
>
>
> see: https://travis-ci.org/apache/commons-collections/jobs/282169803
>
>
> Am 28.09.2017 um 20:23 schrieb Andreas Kuhtz:
>
>> Hi,
>>
>> 2017-09-27 22:28 GMT+02:00 Bruno P. Kinoshita :
>>
>> Forgot to mention something important. When I was debugging the hash
>>> tests, they would pretty much always pass.
>>>
>>> But if I ran the tests normally in maven or eclipse they would always
>>> fail.
>>>
>>> Debugging adds a small overhead I think, that could be slowing down some
>>> part of the code with a concurrency issue?
>>>
>>> That's an explanation. If I start a Virtualbox instance that prepares
>> some
>> load I can see the tests pass under Java 9 ... I had the Virtualbox
>> running
>> yesterday when the tests passed.
>>
>>
>> Just in case it helps...
>>>
>>> Interesting this surefire configuration Andreas. Do you have more
>>> information about it? Is it something we may have to worry about in
>>> components that use locale and jvm 9?
>>>
>>> I ran into an issue with the language selection dialog of izpack and
>> found
>> that this configuration solved the problem there.
>> It's noted in the release notes of Java 9:
>> http://www.oracle.com/technetwork/java/javase/9-relnote-
>> issues-3704069.html#JDK-8008577
>>
>> Cheers,
>> Andreas
>>
>>
>> Cheers
>>> Bruno
>>>
>>> Sent from Yahoo Mail on Android
>>> 
>>>
>>> On Thu, 28 Sep 2017 at 4:45, Andreas Kuhtz
>>>  wrote:
>>> Hi,
>>>
>>> I'm running Win7 and with "mvn clean verify". Checkout master.
>>>
>>> I got the hash code errors, too. But sometimes the tests pass, the next
>>> time they failed with 44 failures (the hash code verification).
>>>
>>> As I'm not sure if my antivirus kicks in and keep some files in the
>>> target
>>> dir, I ran "mvn clean" and after that "mvn clean verify".
>>> But now I have the 44 failures with jdk-1.7.0_67, jdk-1.8.0_131 and 9+181
>>>
>>> Gary:
>>> To get around the issue with ServiceConfiguration sun.util.locale...  I
>>> added the following profile to the pom.xml. After that I only got the 44
>>> errors (hash code) as with Java 7 and 8.
>>>
>>>  
>>>jdk9-build
>>>
>>>  9
>>>
>>>
>>>  
>>>
>>>  maven-surefire-plugin
>>>  
>>>-Djava.locale.providers=COMPAT
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>> I'm not sure if I can help more, but if you need more info just let me
>>> know.
>>>
>>> Andreas
>>>
>>> 2017-09-27 19:10 GMT+02:00 Gary Gregory :
>>>
>>> Using git master and 'mvn clean verify', on Windows 10, with Java 7, I

>>> get
>>>
 44 failures, and I think this is all/mostly hash code problems.

 With Java 8, all tests pass.

 With Java 9, I get ONE failure: ListIteratorWrapperTest.testRemove:116
 ╗
 ServiceConfiguration sun.util.locale

 If I checkout the 4.1 tag and use Java 7, I get 44 failures. ARG! What

>>> the
>>>
 heck?

 Gary



 On Mon, Sep 25, 2017 at 12:02 PM, Benedikt Ritter 
 wrote:

 Hi,
>
> who can help with the test failures on Windows? I’d like to push out
>
 the
>>>
 next release soon to get Collections Java 9 ready. I don’t have access
>
 to a

> Windows installation and I don’t feel like debugging inside a VM :o)
>
> Regards,
> Benedikt
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
>
>>>
>

[GitHub] commons-rng issue #5: Feature rng 37

[cur4so]

Github user cur4so commented on the issue:

https://github.com/apache/commons-rng/pull/5
  
now it's more clear @kinow :) Fixed. And rephrased the git commit message 
as Gilles suggested


---

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

[GitHub] commons-dbutils issue #3: Fixes a thread safety problem introduced by DBUTIL...

[garydgregory]

Github user garydgregory commented on the issue:

https://github.com/apache/commons-dbutils/pull/3
  
I created https://issues.apache.org/jira/browse/DBUTILS-135 to track this 
fix. Committed to git master.


---

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

[GitHub] commons-rng pull request #5: Feature rng 37

[kinow]

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-rng/pull/5#discussion_r143869091
  
--- Diff: 
commons-rng-sampling/src/main/java/org/apache/commons/rng/sampling/distribution/ZigguratGaussianSampler.java
 ---
@@ -0,0 +1,161 @@
+/*
+ * 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.rng.sampling.distribution;
+
+import org.apache.commons.rng.UniformRandomProvider;
+
+/**
+ * Gaussian Sampling by
+ * https://en.wikipedia.org/wiki/Ziggurat_algorithm;>Ziggurat 
algorithm
+ *
+ * Based on
+ * "The Ziggurat Method for Generating Random Variables"
+ * by George Marsaglia and Wai Wan Tsang
+ *
+ * @see http://www.jstatsoft.org/article/view/v005i08/ziggurat.pdf;>Ziggurat 
Method for Generating Random Variables
+ *
+ * @since 1.1
+ */
+
+public class ZigguratGaussianSampler
+extends SamplerBase
+implements NormalizedGaussianSampler {
+
+/**
+ * Generates values from Gaussian (normal) probability distribution
+ * It uses two tables, integers KN and reals WN. Some 99% of the time,
+ * the required x is produced by:
+ * generate a random 32-bit integer j and let i be the index formed 
from
+ * the rightmost 8 bits of j. If j < k_i return x = j * w_i.
+ */
+
+/* @param KN - an auxiliary table of integers, k_i = 
2^32*(x_{i-1}/x_i) */
+private static final int[] KN = new int[128];
+/* @param WN - table of doubles, w_i = x_i/2^32 */
+private static final double[] WN = new double[128];
+/**
+ * This is a Javadoc. @param FN - the function values table
+ * (normalized gaussian in this implementation)
+ * f_i(x_i) = exp(-x_i^2/2)
+ */
+private static final double[] FN = new double[128];
--- End diff --

Oh, sorry, I think that was a bad example. What I meant to say, is that 
your comments had to be something like this:

```
/** An auxiliary table of integers, k_i = 2^32*(x_{i-1}/x_i) */
private static final int[] KN = new int[128];
/** Table of doubles, w_i = x_i/2^32 */
private static final double[] WN = new double[128];
/** The function values table (normalized gaussian in this 
implementation) f_i(x_i) = exp(-x_i^2/2) */
private static final double[] FN = new double[128];
```

It is the double * after the / character that marks the comment as Javadoc 
or not. And the param annotation is necessary only for method parameters.


---

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

[GitHub] commons-rng issue #5: Feature rng 37

[cur4so]

Github user cur4so commented on the issue:

https://github.com/apache/commons-rng/pull/5
  
fixed


---

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

[GitHub] commons-rng pull request #5: Feature rng 37

[kinow]

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-rng/pull/5#discussion_r143859435
  
--- Diff: 
commons-rng-sampling/src/main/java/org/apache/commons/rng/sampling/distribution/ZigguratGaussianSampler.java
 ---
@@ -0,0 +1,159 @@
+/*
+ * 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.rng.sampling.distribution;
+
+import org.apache.commons.rng.UniformRandomProvider;
+
+/**
+ * Gaussian Sampling by
+ * https://en.wikipedia.org/wiki/Ziggurat_algorithm;>Ziggurat 
algorithm
+ *
+ * Based on
+ * "The Ziggurat Method for Generating Random Variables"
+ * by George Marsaglia and Wai Wan Tsang
+ *
+ * @see http://www.jstatsoft.org/article/view/v005i08/ziggurat.pdf;>Ziggurat 
Method for Generating Random Variables
+ *
+ * @since 1.1
+ */
+
+public class ZigguratGaussianSampler
+extends SamplerBase
+implements NormalizedGaussianSampler {
+
+/**
+ * Generates values from Gaussian (normal) probability distribution
+ * It uses two tables, integers KN and reals WN. Some 99% of the time,
+ * the required x is produced by:
+ * generate a random 32-bit integer j and let i be the index formed 
from
+ * the rightmost 8 bits of j. If j < k_i return x = j * w_i.
+ */
+
+/* @param KN - an auxiliary table of integers, k_i = 
2^32*(x_{i-1}/x_i) */
+private static final int[] KN = new int[128];
+/* @param WN - table of doubles, w_i = x_i/2^32 */
+private static final double[] WN = new double[128];
+/* @param FN - the function values table (normalized gaussian in this 
implementation)
+ * f_i(x_i) = exp(-x_i^2/2)
+ */
--- End diff --

This is almost fixed. What you added were multiline comments, ignored by 
javadoc. You have to use

```
/**
 * This is a Javadoc. Here goes your text...
 */
```

Instead of

```

/**
 * This is a multi-line comment. Here goes your text...
 */
```

Site reports still have issues with these comments above.


---

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

Re: [DISCUSS] Move commons-proxy to dormant?

[Gary Gregory]

On Oct 10, 2017 14:18, "Pascal Schumacher"  wrote:

I think we should make it clear to our users which components are actively
developed/supported and for which not to expect enhancements/bugfixes.

I don't think long abandoned components are good for motivating folks to
contribute. Potential contributors just get frustrated if they get no
feedback on patches/pull request, because there is nobody there to review.
Just take a look a the pull requests for components with much more recent
releases. A lot are going unanswered because we lack the time to review and
provided adequate feedback.


Sounds good.

Gary



Am 10.10.2017 um 20:38 schrieb Gary Gregory:

> Sure, why not. In general, I'd rather leave components as they to give
> folks the opportunity to contribute, but I won't stand in your way ;-)
>
> Gary
>
> On Sat, Oct 7, 2017 at 4:48 AM, Pascal Schumacher <
> pascalschumac...@gmx.net>
> wrote:
>
> Hello everybody,
>>
>> the last release of Proxy is from 2008.
>>
>> I looks like attempts to release a 2.0 version were abandoned three and a
>> half year ago.
>>
>> Maybe it is time to move the component to dormant?
>>
>> What do you think?
>>
>> -Pascal
>>
>>
>>
>>
>> -
>> 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

[GitHub] commons-rng issue #5: Feature rng 37

[cur4so]

Github user cur4so commented on the issue:

https://github.com/apache/commons-rng/pull/5
  
thanks @kinow for your suggestions and patience. I've implemented them in 
the last commit


---

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

Re: [DISCUSS] Move commons-proxy to dormant?

[Pascal Schumacher]

I think we should make it clear to our users which components are 
actively developed/supported and for which not to expect 
enhancements/bugfixes.


I don't think long abandoned components are good for motivating folks to 
contribute. Potential contributors just get frustrated if they get no 
feedback on patches/pull request, because there is nobody there to 
review. Just take a look a the pull requests for components with much 
more recent releases. A lot are going unanswered because we lack the 
time to review and provided adequate feedback.


Am 10.10.2017 um 20:38 schrieb Gary Gregory:

Sure, why not. In general, I'd rather leave components as they to give
folks the opportunity to contribute, but I won't stand in your way ;-)

Gary

On Sat, Oct 7, 2017 at 4:48 AM, Pascal Schumacher 
wrote:


Hello everybody,

the last release of Proxy is from 2008.

I looks like attempts to release a 2.0 version were abandoned three and a
half year ago.

Maybe it is time to move the component to dormant?

What do you think?

-Pascal




-
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

[GitHub] commons-dbutils pull request #3: Fixes a thread safety problem introduced by...

[hdevalke]

Github user hdevalke commented on a diff in the pull request:

https://github.com/apache/commons-dbutils/pull/3#discussion_r143833029
  
--- Diff: src/main/java/org/apache/commons/dbutils/BeanProcessor.java ---
@@ -65,19 +65,21 @@
  */
 private static final Map primitiveDefaults = new 
HashMap();
 
-/**
- * ServiceLoader to find ColumnHandler implementations on 
the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader columnHandlers = 
ServiceLoader.load(ColumnHandler.class);
+private static final List columnHandlers = new 
ArrayList();
 
-/**
- * ServiceLoader to find PropertyHandler implementations 
on the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader propertyHandlers = 
ServiceLoader.load(PropertyHandler.class);
+static{
+for (ColumnHandler h : ServiceLoader.load(ColumnHandler.class)) {
+columnHandlers.add(h);
+}
+}
+
+private static final List propertyHandlers = new 
ArrayList();
+
+static {
+for (PropertyHandler h : 
ServiceLoader.load(PropertyHandler.class)) {
+propertyHandlers.add(h);
--- End diff --

I didn't see there was already a static block initializing 
`primitiveDefaults`. I find it more readable initializing each static variable 
in their own block. I did an update and put all in one static block.


---

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

[GitHub] commons-dbutils pull request #3: Fixes a thread safety problem introduced by...

[garydgregory]

Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/commons-dbutils/pull/3#discussion_r143822953
  
--- Diff: src/main/java/org/apache/commons/dbutils/BeanProcessor.java ---
@@ -65,19 +65,21 @@
  */
 private static final Map primitiveDefaults = new 
HashMap();
 
-/**
- * ServiceLoader to find ColumnHandler implementations on 
the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader columnHandlers = 
ServiceLoader.load(ColumnHandler.class);
+private static final List columnHandlers = new 
ArrayList();
 
-/**
- * ServiceLoader to find PropertyHandler implementations 
on the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader propertyHandlers = 
ServiceLoader.load(PropertyHandler.class);
+static{
+for (ColumnHandler h : ServiceLoader.load(ColumnHandler.class)) {
+columnHandlers.add(h);
+}
+}
+
+private static final List propertyHandlers = new 
ArrayList();
+
+static {
+for (PropertyHandler h : 
ServiceLoader.load(PropertyHandler.class)) {
+propertyHandlers.add(h);
--- End diff --

I think of it the other way around: Why use two blocks when you could use 
one?


---

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

[GitHub] commons-dbutils pull request #3: Fixes a thread safety problem introduced by...

[hdevalke]

Github user hdevalke commented on a diff in the pull request:

https://github.com/apache/commons-dbutils/pull/3#discussion_r143818665
  
--- Diff: src/main/java/org/apache/commons/dbutils/BeanProcessor.java ---
@@ -65,19 +65,21 @@
  */
 private static final Map primitiveDefaults = new 
HashMap();
 
-/**
- * ServiceLoader to find ColumnHandler implementations on 
the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader columnHandlers = 
ServiceLoader.load(ColumnHandler.class);
+private static final List columnHandlers = new 
ArrayList();
 
-/**
- * ServiceLoader to find PropertyHandler implementations 
on the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader propertyHandlers = 
ServiceLoader.load(PropertyHandler.class);
+static{
+for (ColumnHandler h : ServiceLoader.load(ColumnHandler.class)) {
+columnHandlers.add(h);
+}
+}
+
+private static final List propertyHandlers = new 
ArrayList();
+
+static {
+for (PropertyHandler h : 
ServiceLoader.load(PropertyHandler.class)) {
+propertyHandlers.add(h);
--- End diff --

Can you explain why that is problematic?


---

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

Re: [DISCUSS] Move commons-proxy to dormant?

[Gary Gregory]

Sure, why not. In general, I'd rather leave components as they to give
folks the opportunity to contribute, but I won't stand in your way ;-)

Gary

On Sat, Oct 7, 2017 at 4:48 AM, Pascal Schumacher 
wrote:

> Hello everybody,
>
> the last release of Proxy is from 2008.
>
> I looks like attempts to release a 2.0 version were abandoned three and a
> half year ago.
>
> Maybe it is time to move the component to dormant?
>
> What do you think?
>
> -Pascal
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[GitHub] commons-dbutils pull request #3: Fixes a thread safety problem introduced by...

[garydgregory]

Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/commons-dbutils/pull/3#discussion_r143814271
  
--- Diff: src/main/java/org/apache/commons/dbutils/BeanProcessor.java ---
@@ -65,19 +65,21 @@
  */
 private static final Map primitiveDefaults = new 
HashMap();
 
-/**
- * ServiceLoader to find ColumnHandler implementations on 
the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader columnHandlers = 
ServiceLoader.load(ColumnHandler.class);
+private static final List columnHandlers = new 
ArrayList();
 
-/**
- * ServiceLoader to find PropertyHandler implementations 
on the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader propertyHandlers = 
ServiceLoader.load(PropertyHandler.class);
+static{
+for (ColumnHandler h : ServiceLoader.load(ColumnHandler.class)) {
+columnHandlers.add(h);
+}
+}
+
+private static final List propertyHandlers = new 
ArrayList();
+
+static {
+for (PropertyHandler h : 
ServiceLoader.load(PropertyHandler.class)) {
+propertyHandlers.add(h);
--- End diff --

What not use a single static block?


---

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

[GitHub] commons-dbutils issue #3: Fixes a thread safety problem introduced by DBUTIL...

[thecarlhall]

Github user thecarlhall commented on the issue:

https://github.com/apache/commons-dbutils/pull/3
  
Thanks, @hdevalke!  Nice catch.  I totally missed that `ServiceLoader` 
isn't thread safe.  I'll work to get this merged into master and cut a new 
release as soon as I can.


---

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

[GitHub] commons-text pull request #68: TEXT-74 Introduced new StrSubstitutor attribu...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/68


---

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

Re: [lang] Commons Lang 2.x release for Java 9

[Emmanuel Bourg]

Le 9/10/2017 à 18:32, Gary Gregory a écrit :
> Can you please update the Javadocs on the various methods that show Java
> versions with examples up to Java 9 to make it clear that the Java 9 use
> case is handled?

Good idea, I added some examples to the public methods.

Emmanuel Bourg

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

[GitHub] commons-text issue #68: TEXT-74 Introduced new StrSubstitutor attribute to d...

[sermojohn]

Github user sermojohn commented on the issue:

https://github.com/apache/commons-text/pull/68
  
For backwards compatibility, it needs to be off by default, so recursive 
substitution applies by default.


---

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

[GitHub] commons-text issue #68: TEXT-74 Introduced new StrSubstitutor attribute to d...

[chtompki]

Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/68
  
Do we want it to be off by default?


---

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

[GitHub] commons-text issue #68: TEXT-74 Introduced new StrSubstitutor attribute to d...

[chtompki]

Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/68
  
Seems reasonable to me.


---

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

Re: [VOTE] Release Commons Configuration 2.2 based on RC1

[Rob Tompkins]

+1. Java 7, 8. Signatures, rat, clirr all check out. 

-Rob

> On Oct 8, 2017, at 4:24 PM, Oliver Heger  wrote:
> 
> Hi all,
> 
> there was a request for a new release on the ML, so here we go.
> 
> Configuration 2.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration/ (rev. 22170)
> 
> The tag is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_2_RC1/
> (rev. 1811500)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1273/org/apache/commons/commons-configuration2/2.2/
> 
> Details of changes since 1.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt
>http://home.apache.org/~oheger/configuration-2.2-rc1/changes-report.html
> 
> Site:
>http://home.apache.org/~oheger/configuration-2.2-rc1/
>  (note some *relative* links are broken and the 1.2 directories are
>  not yet created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 2.1.1):
>http://home.apache.org/~oheger/configuration-2.2-rc1/clirr-report.html
> 
> RAT Report:
>http://home.apache.org/~oheger/configuration-2.2-rc1/rat-report.html
> 
> KEYS:
>  https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 22:00 UTC 11-October 2017
> 
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
> 
> Thanks!
> Oliver
> 
> 
> -
> 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: Java 8 curiousity

[Simon Spero]

Could be gc, could be hotspot compiler, or could be library

There was a massive improvement in the performance of the G1 GC in u60 when
dealing with "humongous"  objects; however I assume you wouldn't have been
using G1 before u60 for anything real (that was when it first became
usable.

If you attach visualvm and sample, you should get a better idea of were the
performance wins are coming from.

wrapping the app as a pseudo jmh benchmark and running using perfasm as the
profiler (needs hsdis, Linux, and perf) may be more precise (e.g. better
inlining, different instruction use, etc).

Simon

On Oct 9, 2017 5:21 PM, "Rob Tompkins"  wrote:

Hey all,

At my day job we saw a 60% performance improvement (cpu utilization)
between 1.8.0_40 and 1.8.0_121, and I was wondering if anyone else out
there has seen anything like that before or if anyone might know what could
cause that given that the release notes  don’t directly point to anything.

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

[GitHub] commons-dbutils pull request #3: Fixes a thread safety problem introduced by...

[hdevalke]

GitHub user hdevalke opened a pull request:

https://github.com/apache/commons-dbutils/pull/3

Fixes a thread safety problem introduced by DBUTILS-124.

ColumnHandlers and PropertyHandlers are preloaded in a list as the 
ServiceLoader instances are not thread safe

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hdevalke/commons-dbutils master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-dbutils/pull/3.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3


commit 59d114082708ade64c9f05b13128d0c0eb39bc7f
Author: Hannes De Valkeneer 
Date:   2017-10-05T14:05:18Z

Fixes a thread safety problem introduced by DBUTILS-124.

ColumnHandlers and PropertyHandlers are preloaded in a list as the 
ServiceLoader instances are not thread safe




---

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

Re: Java 8 curiousity

[John Patrick]

i've experience the same, a build about ~75 and another around ~95
introduced from the limited versions I've tested introduced some
dramatic performance and memory improvements

i think one was around streams and the other around lambdas

but that is also about u40 was April 14, 2015, and u121 was April 18,
2017, so you have 2 years of people using java 8 with real life
applications and feeding back those changes

John


On 10 October 2017 at 00:03, Ole Ersoy  wrote:
> Are you using streams?  A while back I experimented with matrix
> multiplication using streams and they can be very slow:
>
> https://stackoverflow.com/questions/35037893/java-8-stream-matrix-multiplication-10x-slower-than-for-loop
>
> So I would think that Java has a lot of performance tuning and optimization
> it could do in this space.
>
> Cheers,
>
> Ole
>
>
>
> On 10/09/2017 04:20 PM, Rob Tompkins wrote:
>>
>> Hey all,
>>
>> At my day job we saw a 60% performance improvement (cpu utilization)
>> between 1.8.0_40 and 1.8.0_121, and I was wondering if anyone else out there
>> has seen anything like that before or if anyone might know what could cause
>> that given that the release notes  don’t directly point to anything.
>>
>> Cheers,
>> -Rob
>> -
>> 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