[jira] [Commented] (COLLECTIONS-662) Build failures when building with Java 9

2017-10-11 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201417#comment-16201417
 ] 

ASF GitHub Bot commented on COLLECTIONS-662:


Github user coveralls commented on the issue:

https://github.com/apache/commons-collections/pull/30
  

[![Coverage 
Status](https://coveralls.io/builds/13681730/badge)](https://coveralls.io/builds/13681730)

Coverage remained the same at 86.616% when pulling 
**627b825a24eb03fb5d29f2eb5243034bafc12d94 on vamsi-kavuri:java9_compat** into 
**07de4dd578727555bb94ed421498f455838b317d on apache:master**.



> Build failures when building with Java 9
> 
>
> Key: COLLECTIONS-662
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-662
> Project: Commons Collections
>  Issue Type: Bug
>Reporter: Vamsi
>
> *mvn clean test* fails with following errors when using with java-9
> {code:java}
> Tests in error: 
>   MapUtilsTest.testgetByteValue:1051 » ServiceConfiguration 
> sun.util.locale.prov...
>   MapUtilsTest.testgetDoubleValue:956 » ServiceConfiguration 
> sun.util.locale.pro...
>   MapUtilsTest.testgetFloatValue:974 » ServiceConfiguration 
> sun.util.locale.prov...
>   MapUtilsTest.testgetIntValue:1012 » ServiceConfiguration 
> sun.util.locale.provi...
>   MapUtilsTest.testgetLongValue:992 » ServiceConfiguration 
> sun.util.locale.provi...
>   MapUtilsTest.testgetShortValue:1031 » ServiceConfiguration 
> sun.util.locale.pro...
>   ListIteratorWrapperTest.testRemove:116 » ServiceConfiguration 
> sun.util.locale
> Tests run: 16088, Failures: 0, Errors: 7, Skipped: 0
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COLLECTIONS-662) Build failures when building with Java 9

2017-10-11 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201416#comment-16201416
 ] 

ASF GitHub Bot commented on COLLECTIONS-662:


GitHub user vamsi-kavuri opened a pull request:

https://github.com/apache/commons-collections/pull/30

 COLLECTIONS-662 : Override Jacoco version for Java9 compatibility

Overriding Jacoco version fixed the failures in Java 9.

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

$ git pull https://github.com/vamsi-kavuri/commons-collections java9_compat

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

https://github.com/apache/commons-collections/pull/30.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 #30


commit 191826a52a3d77a821d3715cc4074ed6348b6e0a
Author: Kavuri, Vamsi 
Date:   2017-10-12T04:04:10Z

override jacoco version for java9 compatibiltiy

commit 627b825a24eb03fb5d29f2eb5243034bafc12d94
Author: Vamsi 
Date:   2017-10-12T04:05:46Z

Update pom.xml




> Build failures when building with Java 9
> 
>
> Key: COLLECTIONS-662
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-662
> Project: Commons Collections
>  Issue Type: Bug
>Reporter: Vamsi
>
> *mvn clean test* fails with following errors when using with java-9
> {code:java}
> Tests in error: 
>   MapUtilsTest.testgetByteValue:1051 » ServiceConfiguration 
> sun.util.locale.prov...
>   MapUtilsTest.testgetDoubleValue:956 » ServiceConfiguration 
> sun.util.locale.pro...
>   MapUtilsTest.testgetFloatValue:974 » ServiceConfiguration 
> sun.util.locale.prov...
>   MapUtilsTest.testgetIntValue:1012 » ServiceConfiguration 
> sun.util.locale.provi...
>   MapUtilsTest.testgetLongValue:992 » ServiceConfiguration 
> sun.util.locale.provi...
>   MapUtilsTest.testgetShortValue:1031 » ServiceConfiguration 
> sun.util.locale.pro...
>   ListIteratorWrapperTest.testRemove:116 » ServiceConfiguration 
> sun.util.locale
> Tests run: 16088, Failures: 0, Errors: 7, Skipped: 0
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COLLECTIONS-662) Build failures when building with Java 9

2017-10-11 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201415#comment-16201415
 ] 

ASF GitHub Bot commented on COLLECTIONS-662:


GitHub user vamsi-kavuri opened a pull request:

https://github.com/apache/commons-collections/pull/30

 COLLECTIONS-662 : Override Jacoco version for Java9 compatibility

Overriding Jacoco version fixed the failures in Java 9.

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

$ git pull https://github.com/vamsi-kavuri/commons-collections java9_compat

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

https://github.com/apache/commons-collections/pull/30.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 #30


commit 191826a52a3d77a821d3715cc4074ed6348b6e0a
Author: Kavuri, Vamsi 
Date:   2017-10-12T04:04:10Z

override jacoco version for java9 compatibiltiy

commit 627b825a24eb03fb5d29f2eb5243034bafc12d94
Author: Vamsi 
Date:   2017-10-12T04:05:46Z

Update pom.xml




> Build failures when building with Java 9
> 
>
> Key: COLLECTIONS-662
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-662
> Project: Commons Collections
>  Issue Type: Bug
>Reporter: Vamsi
>
> *mvn clean test* fails with following errors when using with java-9
> {code:java}
> Tests in error: 
>   MapUtilsTest.testgetByteValue:1051 » ServiceConfiguration 
> sun.util.locale.prov...
>   MapUtilsTest.testgetDoubleValue:956 » ServiceConfiguration 
> sun.util.locale.pro...
>   MapUtilsTest.testgetFloatValue:974 » ServiceConfiguration 
> sun.util.locale.prov...
>   MapUtilsTest.testgetIntValue:1012 » ServiceConfiguration 
> sun.util.locale.provi...
>   MapUtilsTest.testgetLongValue:992 » ServiceConfiguration 
> sun.util.locale.provi...
>   MapUtilsTest.testgetShortValue:1031 » ServiceConfiguration 
> sun.util.locale.pro...
>   ListIteratorWrapperTest.testRemove:116 » ServiceConfiguration 
> sun.util.locale
> Tests run: 16088, Failures: 0, Errors: 7, Skipped: 0
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (COLLECTIONS-662) Build failures when building with Java 9

2017-10-11 Thread Vamsi (JIRA) 
Vamsi created COLLECTIONS-662:
-

 Summary: Build failures when building with Java 9
 Key: COLLECTIONS-662
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-662
 Project: Commons Collections
  Issue Type: Bug
Reporter: Vamsi


*mvn clean test* fails with following errors when using with java-9
{code:java}
Tests in error: 
  MapUtilsTest.testgetByteValue:1051 » ServiceConfiguration 
sun.util.locale.prov...
  MapUtilsTest.testgetDoubleValue:956 » ServiceConfiguration 
sun.util.locale.pro...
  MapUtilsTest.testgetFloatValue:974 » ServiceConfiguration 
sun.util.locale.prov...
  MapUtilsTest.testgetIntValue:1012 » ServiceConfiguration 
sun.util.locale.provi...
  MapUtilsTest.testgetLongValue:992 » ServiceConfiguration 
sun.util.locale.provi...
  MapUtilsTest.testgetShortValue:1031 » ServiceConfiguration 
sun.util.locale.pro...
  ListIteratorWrapperTest.testRemove:116 » ServiceConfiguration 
sun.util.locale

Tests run: 16088, Failures: 0, Errors: 7, Skipped: 0
{code}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CODEC-242) Add Automatic-Module-Name manifest entry for Java 9

2017-10-11 Thread Gary Gregory (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CODEC-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed CODEC-242.
--
   Resolution: Fixed
Fix Version/s: 1.11

In svn trunk.

> Add Automatic-Module-Name manifest entry for Java 9
> ---
>
> Key: CODEC-242
> URL: https://issues.apache.org/jira/browse/CODEC-242
> Project: Commons Codec
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.11
>
>
> Add {{Automatic-Module-Name}} manifest entry for Java 9: 
> {{org.apache.commons.codec}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CODEC-242) Add Automatic-Module-Name manifest entry for Java 9

2017-10-11 Thread Gary Gregory (JIRA) 
Gary Gregory created CODEC-242:
--

 Summary: Add Automatic-Module-Name manifest entry for Java 9
 Key: CODEC-242
 URL: https://issues.apache.org/jira/browse/CODEC-242
 Project: Commons Codec
  Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory


Add {{Automatic-Module-Name}} manifest entry for Java 9: 
{{org.apache.commons.codec}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #299: Add module-info for Java 9

2017-10-11 Thread stokito 
Github user stokito commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/299#discussion_r144134867
  
--- Diff: .travis.yml ---
@@ -17,12 +17,10 @@ language: java
 sudo: false
 
 jdk:
-  - openjdk7
--- End diff --

Sounds sad :( Especially because, I guess, jdk8 compiler willn't just 
ignore the `module-info.java`.
Maybe some other projects will even try to generate the `module-info.java`


---

[GitHub] commons-lang pull request #299: Add module-info for Java 9

2017-10-11 Thread jodastephen 
Github user jodastephen commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/299#discussion_r144119796
  
--- Diff: .travis.yml ---
@@ -17,12 +17,10 @@ language: java
 sudo: false
 
 jdk:
-  - openjdk7
--- End diff --

With the proposed change, the build can only occur on Java 9. (Java 9 is 
needed to compile `module-info.java`).


---

[jira] [Commented] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values

2017-10-11 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200543#comment-16200543
 ] 

ASF GitHub Bot commented on TEXT-74:


Github user arend-von-reinersdorff commented on the issue:

https://github.com/apache/commons-text/pull/68
  
@sermojohn Great, thanks :-)


> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Priority: Minor
>  Labels: features
> Fix For: 1.x
>
>
> StrSubstitutor replaces variables in values. And currently there's no way to 
> turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some 
> of the replacement values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$". 
> This is annoying. Especially as I use one template with variables as a value 
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints:
> {code}
> Hello Hamburg from Hamburg
> {code}
> The commented line is my suggestion for this feature. If it works, it should 
> print:
> {code}
> Hello ${city} from Hamburg
> {code}
> {code}
> // untrusted user input
> String userInputName = "${city}";
> String userInputCity = "Hamburg";
> Map valueMap = new HashMap<>();
> valueMap.put("name", userInputName);
> valueMap.put("city", userInputCity);
> String source = "Hello ${name} from ${city}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LANG-1354) FieldUtils should ignore any synthetic fields

2017-10-11 Thread Charles Honton (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LANG-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Charles Honton updated LANG-1354:
-
Assignee: (was: Charles Honton)

> FieldUtils should ignore any synthetic fields
> -
>
> Key: LANG-1354
> URL: https://issues.apache.org/jira/browse/LANG-1354
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Yegor Koldov
>Priority: Minor
>
> For my opinion [FieldUtils.getAllFieldsList | 
> https://github.com/apache/commons-lang/blob/release/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java#L212]
>  should ignore any synthetic fileds (Jacoco for ex.)
> If you agree with that, i could prepaire PR on github



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (LANG-1354) FieldUtils should ignore any synthetic fields

2017-10-11 Thread Charles Honton (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LANG-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Charles Honton reopened LANG-1354:
--

Synthetic fields are more prevalent than I realized.  To support this with 
backwards compatibility will require additional method.

Pull requests are welcome. 

> FieldUtils should ignore any synthetic fields
> -
>
> Key: LANG-1354
> URL: https://issues.apache.org/jira/browse/LANG-1354
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Yegor Koldov
>Assignee: Charles Honton
>Priority: Minor
>
> For my opinion [FieldUtils.getAllFieldsList | 
> https://github.com/apache/commons-lang/blob/release/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java#L212]
>  should ignore any synthetic fileds (Jacoco for ex.)
> If you agree with that, i could prepaire PR on github



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IO-328) FileUtils.listFilesAndDirs includes original dir in results even when it doesn't match filter

2017-10-11 Thread Thomas Hartwig (JIRA) 

[ 
https://issues.apache.org/jira/browse/IO-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200209#comment-16200209
 ] 

Thomas Hartwig commented on IO-328:
---

Hi, I can not see this is fixed in any way, nor it is mentioned in the Javadoc 
(version 2.4 here), nor something is changed in the code. More worse any filter 
specified as argument will not be applied to directories this is not the 
expected behaviour. Can you check please and open.

> FileUtils.listFilesAndDirs includes original dir in results even when it 
> doesn't match filter
> -
>
> Key: IO-328
> URL: https://issues.apache.org/jira/browse/IO-328
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Hoss Man
> Fix For: 2.5
>
> Attachments: IO-328.patch, IO-328.testcase.patch
>
>
> listFilesAndDirs seems to always include the "directory" passed as input in 
> it's resulting Collection.  This is unexpected given the docs for the 
> method...
> bq. Finds files within a given directory (and optionally its subdirectories). 
> All files found are filtered by an IOFileFilter. 
> * the "given directory" is not a subdirectory of itself
> * it is not subjected to the IOFileFilter dirFilter, it is always added.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (RNG-37) Ziggurat algorithm

2017-10-11 Thread Gilles (JIRA) 

[ 
https://issues.apache.org/jira/browse/RNG-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199972#comment-16199972
 ] 

Gilles commented on RNG-37:
---

Merged in "master" with minor changes.

> Ziggurat algorithm
> --
>
> Key: RNG-37
> URL: https://issues.apache.org/jira/browse/RNG-37
> Project: Commons RNG
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>
> Fast algorithm for sampling a Gaussian distribution: 
> https://en.wikipedia.org/wiki/Ziggurat_algorithm



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #:

2017-10-11 Thread PascalSchumacher 
Github user PascalSchumacher commented on the pull request:


https://github.com/apache/commons-lang/commit/c56b87d6efe530590b6d9a07e41ca00af208ce37#commitcomment-24901481
  
Travis build fails:

```
Failed tests: 

  FieldUtilsTest.testGetAllFields:167 array lengths differed, 
expected.length=12 actual.length=11

  FieldUtilsTest.testGetAllFieldsList:179 expected:<[public static final 
int java.lang.Integer.MIN_VALUE, public static final int 
java.lang.Integer.MAX_VALUE, public static final java.lang.Class 
java.lang.Integer.TYPE, static final char[] java.lang.Integer.digits, static 
final char[] java.lang.Integer.DigitTens, static final char[] 
java.lang.Integer.DigitOnes, static final int[] java.lang.Integer.sizeTable, 
private final int java.lang.Integer.value, public static final int 
java.lang.Integer.SIZE, private static final long 
java.lang.Integer.serialVersionUID, static final boolean 
java.lang.Integer.$assertionsDisabled, private static final long 
java.lang.Number.serialVersionUID]> but was:<[public static final int 
java.lang.Integer.MIN_VALUE, public static final int 
java.lang.Integer.MAX_VALUE, public static final java.lang.Class 
java.lang.Integer.TYPE, static final char[] java.lang.Integer.digits, static 
final char[] java.lang.Integer.DigitTens, static final char[] java.lang.Integer
 .DigitOnes, static final int[] java.lang.Integer.sizeTable, private final int 
java.lang.Integer.value, public static final int java.lang.Integer.SIZE, 
private static final long java.lang.Integer.serialVersionUID, private static 
final long java.lang.Number.serialVersionUID]>
```

see: https://travis-ci.org/apache/commons-lang/jobs/286344083


---

[jira] [Commented] (COLLECTIONS-661) Intermittent test failures in Windows for HashSetValuedHashMap

2017-10-11 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199917#comment-16199917
 ] 

ASF GitHub Bot commented on COLLECTIONS-661:


Github user coveralls commented on the issue:

https://github.com/apache/commons-collections/pull/28
  

[![Coverage 
Status](https://coveralls.io/builds/13663731/badge)](https://coveralls.io/builds/13663731)

Coverage increased (+0.008%) to 85.126% when pulling 
**6e8951ed0325abe3e07e32aded0b27aacdbc1011 on kinow:COLLECTIONS-661** into 
**1d21a49c27d9eab8d02785a783fcfba387a3e8e1 on apache:master**.



> Intermittent test failures in Windows for HashSetValuedHashMap
> --
>
> Key: COLLECTIONS-661
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-661
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Map
>Affects Versions: 4.1
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
> Fix For: 4.2
>
>
> The collection HashSetValuedHashMap was added in 4.1. On Windows, test 
> failures are not so common on JVM 8. But on Linux they are harder to happen 
> (but still do [1], [2]).
> When using Windows and JVM 8, running tests on Eclipse, or Maven fail. But 
> debugging on Windows with Eclipse sometimes work. Indicating it may be due to 
> a concurrency issue, where debugging adds some extra time hiding the real 
> issue.
> I have a few ideas of where/why it could be happening, but am without a 
> Windows box for a few days as I'm travelling. I'm reading the codebase in the 
> meantime, but if anybody feels like working on it, feel free to chime in and 
> suggest a fix/patch.
> [1] https://travis-ci.org/apache/commons-collections/jobs/282169803
> [2] http://markmail.org/thread/exwm7ggjtxzbtlkd



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COLLECTIONS-661) Intermittent test failures in Windows for HashSetValuedHashMap

2017-10-11 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199913#comment-16199913
 ] 

ASF GitHub Bot commented on COLLECTIONS-661:


GitHub user kinow opened a pull request:

https://github.com/apache/commons-collections/pull/28

COLLECTIONS-661: fix for concurrency issue in HashSetValuedHashMapTest

The `getMap()` method, when testing a `HashSetValuedHashMap`, would return 
an object of this type. Which is an instance of `SetValuedMap`.

Running it in debug mode would - most of the times - run the tests and 
succeed. Running normally - especially on Windows - would result in 
intermittent, but very frequent, failures.

The `getMap()` method sometimes, depending on the order and execution of 
tests, will be null. So the collection added to the map will be either a 
`Hashset`, or a `Arrays$ArrayList`. When the types are different, `hashCode()` 
and `equals()` calls return incorrect values, resulting in the errors we have 
seen in COLLECTIONS-661.

A good solution would be to re-design the tests. The 
`TestMultiValuedMapAsMap` is testing `MultiValuedMap`'s, which include 
`HashSetValuedHashMap`. However, some of its methods contain extra logic for 
when the type under test has some characteristics like being an instance of 
`SetValuedMap`.

It might be possible to come up with a better design, where there are 
multiple test classes, for `MultiValuedMap`'s that use `SetValuedMap`'s; 
`MultieValuedMap`'s that use `List`'s, and so it goes.

Or we could add a class to the parent class, with a flag defining the type 
under test. For now, I have used the `makeObject()` method, which returns the 
collection under test. Then I validate its instance type. There is also a 
comment above the code to indicate why we are using `makeObject()` and not 
`getMap()`.

It was a fun ticket. Happy to get feedback on better solutions, or feel 
free to edit this pull request if you have right to it, or merge if you are 
happy and it has gathered some consensus.

Cheers,
Bruno

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

$ git pull https://github.com/kinow/commons-collections COLLECTIONS-661

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

https://github.com/apache/commons-collections/pull/28.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 #28


commit 6e8951ed0325abe3e07e32aded0b27aacdbc1011
Author: Bruno P. Kinoshita 
Date:   2017-10-11T07:27:25Z

COLLECTIONS-661: fix for concurrency issue in HashSetValuedHashMapTest




> Intermittent test failures in Windows for HashSetValuedHashMap
> --
>
> Key: COLLECTIONS-661
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-661
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Map
>Affects Versions: 4.1
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
> Fix For: 4.2
>
>
> The collection HashSetValuedHashMap was added in 4.1. On Windows, test 
> failures are not so common on JVM 8. But on Linux they are harder to happen 
> (but still do [1], [2]).
> When using Windows and JVM 8, running tests on Eclipse, or Maven fail. But 
> debugging on Windows with Eclipse sometimes work. Indicating it may be due to 
> a concurrency issue, where debugging adds some extra time hiding the real 
> issue.
> I have a few ideas of where/why it could be happening, but am without a 
> Windows box for a few days as I'm travelling. I'm reading the codebase in the 
> meantime, but if anybody feels like working on it, feel free to chime in and 
> suggest a fix/patch.
> [1] https://travis-ci.org/apache/commons-collections/jobs/282169803
> [2] http://markmail.org/thread/exwm7ggjtxzbtlkd



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COLLECTIONS-661) Intermittent test failures in Windows for HashSetValuedHashMap

2017-10-11 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199914#comment-16199914
 ] 

ASF GitHub Bot commented on COLLECTIONS-661:


GitHub user kinow opened a pull request:

https://github.com/apache/commons-collections/pull/28

COLLECTIONS-661: fix for concurrency issue in HashSetValuedHashMapTest

The `getMap()` method, when testing a `HashSetValuedHashMap`, would return 
an object of this type. Which is an instance of `SetValuedMap`.

Running it in debug mode would - most of the times - run the tests and 
succeed. Running normally - especially on Windows - would result in 
intermittent, but very frequent, failures.

The `getMap()` method sometimes, depending on the order and execution of 
tests, will be null. So the collection added to the map will be either a 
`Hashset`, or a `Arrays$ArrayList`. When the types are different, `hashCode()` 
and `equals()` calls return incorrect values, resulting in the errors we have 
seen in COLLECTIONS-661.

A good solution would be to re-design the tests. The 
`TestMultiValuedMapAsMap` is testing `MultiValuedMap`'s, which include 
`HashSetValuedHashMap`. However, some of its methods contain extra logic for 
when the type under test has some characteristics like being an instance of 
`SetValuedMap`.

It might be possible to come up with a better design, where there are 
multiple test classes, for `MultiValuedMap`'s that use `SetValuedMap`'s; 
`MultieValuedMap`'s that use `List`'s, and so it goes.

Or we could add a class to the parent class, with a flag defining the type 
under test. For now, I have used the `makeObject()` method, which returns the 
collection under test. Then I validate its instance type. There is also a 
comment above the code to indicate why we are using `makeObject()` and not 
`getMap()`.

It was a fun ticket. Happy to get feedback on better solutions, or feel 
free to edit this pull request if you have right to it, or merge if you are 
happy and it has gathered some consensus.

Cheers,
Bruno

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

$ git pull https://github.com/kinow/commons-collections COLLECTIONS-661

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

https://github.com/apache/commons-collections/pull/28.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 #28


commit 6e8951ed0325abe3e07e32aded0b27aacdbc1011
Author: Bruno P. Kinoshita 
Date:   2017-10-11T07:27:25Z

COLLECTIONS-661: fix for concurrency issue in HashSetValuedHashMapTest




> Intermittent test failures in Windows for HashSetValuedHashMap
> --
>
> Key: COLLECTIONS-661
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-661
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Map
>Affects Versions: 4.1
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
> Fix For: 4.2
>
>
> The collection HashSetValuedHashMap was added in 4.1. On Windows, test 
> failures are not so common on JVM 8. But on Linux they are harder to happen 
> (but still do [1], [2]).
> When using Windows and JVM 8, running tests on Eclipse, or Maven fail. But 
> debugging on Windows with Eclipse sometimes work. Indicating it may be due to 
> a concurrency issue, where debugging adds some extra time hiding the real 
> issue.
> I have a few ideas of where/why it could be happening, but am without a 
> Windows box for a few days as I'm travelling. I'm reading the codebase in the 
> meantime, but if anybody feels like working on it, feel free to chime in and 
> suggest a fix/patch.
> [1] https://travis-ci.org/apache/commons-collections/jobs/282169803
> [2] http://markmail.org/thread/exwm7ggjtxzbtlkd



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCS-184) Unexpected dispose() in CompositeCacheManager.release()

2017-10-11 Thread avonthun (JIRA) 
avonthun created JCS-184:


 Summary: Unexpected dispose() in CompositeCacheManager.release()
 Key: JCS-184
 URL: https://issues.apache.org/jira/browse/JCS-184
 Project: Commons JCS
  Issue Type: Bug
  Components: Composite Cache
Affects Versions: jcs-2.2
Reporter: avonthun


If debug-logging is *not* enabled the return-statement is ignored and the code 
falls-through to cache.dispose().

See Line 739 in 
http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.2/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheManager.java?revision=1803806=markup



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)