[GitHub] commons-lang issue #376: Test cleanup
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/376 Thanks! ð ---
[GitHub] commons-lang pull request #376: Test cleanup
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/376 ---
[GitHub] commons-lang issue #376: Test cleanup
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/376 [](https://coveralls.io/builds/19506146) Coverage decreased (-0.02%) to 95.233% when pulling **142a40b9188b3710a4a15298f82460ab51bc90dd on mureinik:test-cleanup** into **46ea7e5e963b09b63d6a54cddd7fe391d0d5b6f4 on apache:master**. ---
[GitHub] commons-lang issue #376: Test cleanup
Github user mureinik commented on the issue: https://github.com/apache/commons-lang/pull/376 > Looks great, thank you very much! ð > > There are just some checkstyle errors related to unused imports left to fix (see failed travis build). Missed a couple of unused import statements after I cleaned up the usages of `assertTrue` and `assertFalse`. I removed them, and the build should pass now. ---
[GitHub] commons-lang issue #376: Test cleanup
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/376 Looks great, thank you very much! ð There are just some checkstyle errors related to unused imports left to fix (see failed travis build). ---
[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[
https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649052#comment-16649052
]
Gary Gregory commented on BEANUTILS-509:
Here is something handy, in the {{pom.xml}}, I updated the Surefire argline
from 56 megabytes to 256 MB:
{code:xml}
-Xmx256M
{code}
and now I get:
{noformat}
[INFO] Running org.apache.commons.beanutils2.bugs.Jira509TestCase
[ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 111.811
s <<< FAILURE! - in org.apache.commons.beanutils2.bugs.Jira509TestCase
[ERROR] org.apache.commons.beanutils2.bugs.Jira509TestCase Time elapsed:
111.076 s <<< ERROR!
java.lang.OutOfMemoryError: GC overhead limit exceeded
{noformat}
Clearly, suing a synchronized map here is wreaking some havoc...
> WeakHashmap enters into infinite loop in WrapDynaClass.java
> ---
>
> Key: BEANUTILS-509
> URL: https://issues.apache.org/jira/browse/BEANUTILS-509
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: DynaBean
>Affects Versions: 1.8.2
>Reporter: sunil
>Priority: Major
> Attachments: 2018-10-13T11-43-27_961-jvmRun1.dump,
> 2018-10-13T11-43-27_961.dumpstream, BEANUTILS-509.diff, WrapDynaCache.patch,
> WrapDynaCache_after_svn_commit.patch, console.log.backup
>
>
> We noticed that our application was using too much of CPU , all the 6 cores
> were used.
> On capturing the thread dump we saw that large number of threads were in the
> running state and in :
> at java.util.WeakHashMap.get(WeakHashMap.java:403)
> at
> org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425)
>
> So we are suspecting that the thread has entered into indefinite while loop
> and hogging all the CPU resources.
> I have attached the thread dump for reference.
>
> what is the solution for this issue?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang pull request #376: Test cleanup
GitHub user mureinik opened a pull request: https://github.com/apache/commons-lang/pull/376 Test cleanup Following up after the migration of the test suite to JUnit Jupiter, some test code could be cleaned up to make it clearer and easier to maintain. This PR contains several patches around that area: General fixes: - In order to test an expected exception, `assertThrows` was used instead of a cumbersome `if`-`fail`-`catch` construct. - In order to fail a test on an unexpected exception, the exception is thrown outside the method, instead of the cumbersome construct of catching it and calling `fail` - Redundant `throws` clauses were removed - `assertEquals`, `assertNotEquals`, `assertSame`, `assertNotSame`, `assertNull` and `assertNotNull` were used instead of reimplementing them with conditions in `if` statements or `assertTrue`s. Specific improvements: - `ConverstionTest#assertBinaryEquals` was removed in favor of the built-in `Assertions#assertArraysEquals(boolean[], boolean[])`. - `LocaleUtilsTest#parseAllLocales` was rewritten as a parameterized test instead of implementing it manually with a loop. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mureinik/commons-lang test-cleanup Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/376.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 #376 commit c9ee985fce7d14d673d9b6bace824560eb4d40fc Author: Allon Mureinik Date: 2018-10-12T15:12:34Z Remove ConversionTest#assertBinaryEquals JUnit Jupiter's Assertions has an assertArraysEuqals(boolean[], boolean[]) method, so there's no longer a need for the assertBinaryEquals method. commit cf44c603b105f154b6b57604fe9abd589b7dbd2b Author: Allon Mureinik Date: 2018-10-12T16:14:01Z Make LocaleUtilsTest#parseAllLocales parameterized This patch converts testParseAllLocales to a @ParameterizedTest instead of iterating over the locales inside the method's body. This changes allows using standard asserts for each case individually instead of having to count failures and print the problematic locales to System.out. commit 15daf92088ad6d8868cd157ca9666721a59ce705 Author: Allon Mureinik Date: 2018-10-13T14:16:54Z Remove double stop() test in StopWatchTest StopWatchTest#testBadStates has the same block of code testing StopWatch#stop copy-pasted. This patch cleans it up by removing one of those blocks. commit 8507e5c81a8d3fedc655c02c93d4cf9dd4418ff6 Author: Allon Mureinik Date: 2018-10-13T14:08:48Z Clean up testing of exceptions Now that the entire project is ported to JUnit Jupiter, there are more elegant ways to test for exceptions, which this patch applies throughtout the code base. If throwing an exception is supposed to fail a test, just throwing it outside of the method cleans up the code and makes it more elegant, instead of catching it and calling Assertions#fail. If an exception is supposed to be thrown, calling Assertions#assertThrows is a more elegant option than calling Assertions#fail in the try block and then catching and ignoring the expected exception. Note that assertThrows uses a lambda block, so the variables inside it should be final or effectively final. Reusing variables is a common practice in the tests, so where needed new final variables were introduced, or the variables used were inlined. commit 3c6141d401233176d2e424640bffe0369592349e Author: Allon Mureinik Date: 2018-10-13T16:38:01Z Use assertTrue/assertFalse instead of reimplementing them Use assertTrue and assertFalse instead of reimplemeting their logic by having an if statement conditionalling call fail. commit 8ee1a558b821f28313b8b538b5d4b0de1b0e7044 Author: Allon Mureinik Date: 2018-10-13T16:49:52Z Clean up redundant throws clauses commit 591bebc111bca4f0681560b70fcc3d20cda40577 Author: Allon Mureinik Date: 2018-10-13T17:05:40Z Clean up assertions Use built-in assertion methods provides by org.junit.jupiter.api.Assertions instead of reimplementing the same logic with assertTrue and assertFalse. Note that JUnit Jupiter 5.3.1 does not support deltas of 0 for assertEquals(double, double, double) and assertEquals(float, float, float), so these usages of assertTrue were left untouched, and will be addressed when JUnit Jupiter 5.4, that addresses this isssue, will be available (see https://github.com/junit-team/junit5/pull/1613 for details). ---
[jira] [Comment Edited] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[
https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649046#comment-16649046
]
Gary Gregory edited comment on BEANUTILS-509 at 10/13/18 5:53 PM:
--
For now, I can see that wrapping the weak map into a synchronized map may help
but this causes the build to fail, not because any unit tests fail, but because
the Maven Surefire plugin that runs the tests blows up:
{noformat}
[WARNING] Tests run: 1279, Failures: 0, Errors: 0, Skipped: 3
[INFO]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 06:15 min
[INFO] Finished at: 2018-10-13T11:28:38-06:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test (default-test) on
project commons-beanutils2: There are test failures.
[ERROR]
[ERROR] Please refer to
C:\vcs\svn\apache\commons\trunks-proper\beanutils\target\surefire-reports for
the individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump,
[date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] ExecutionException The forked VM terminated without properly saying
goodbye. VM crash or System.exit called?
[ERROR] Command was cmd.exe /X /C ""C:\Program
Files\Java\jdk1.8.0_181\jre\bin\java" -Xmx56M
-javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.2\\org.jacoco.agent-0.8.2-runtime.jar=destfile=C:\\vcs\\svn\\apache\\commons\\trunks-proper\\beanutils\\target\\jacoco.exec
-jar
C:\Users\ggregory\AppData\Local\Temp\surefire4491303226062350457\surefirebooter7341664506376672162.jar
C:\Users\ggregory\AppData\Local\Temp\surefire4491303226062350457
2018-10-13T11-22-41_548-jvmRun1 surefire7040480156590727732tmp
surefire_356812217102022201471tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException:
ExecutionException The forked VM terminated without properly saying goodbye. VM
crash or System.exit called?
[ERROR] Command was cmd.exe /X /C ""C:\Program
Files\Java\jdk1.8.0_181\jre\bin\java" -Xmx56M
-javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.2\\org.jacoco.agent-0.8.2-runtime.jar=destfile=C:\\vcs\\svn\\apache\\commons\\trunks-proper\\beanutils\\target\\jacoco.exec
-jar
C:\Users\ggregory\AppData\Local\Temp\surefire4491303226062350457\surefirebooter7341664506376672162.jar
C:\Users\ggregory\AppData\Local\Temp\surefire4491303226062350457
2018-10-13T11-22-41_548-jvmRun1 surefire7040480156590727732tmp
surefire_356812217102022201471tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:510)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:457)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:298)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
[ERROR] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR] at
[jira] [Updated] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated BEANUTILS-509: --- Attachment: 2018-10-13T11-43-27_961-jvmRun1.dump 2018-10-13T11-43-27_961.dumpstream > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: 2018-10-13T11-43-27_961-jvmRun1.dump, > 2018-10-13T11-43-27_961.dumpstream, BEANUTILS-509.diff, WrapDynaCache.patch, > WrapDynaCache_after_svn_commit.patch, console.log.backup > > > We noticed that our application was using too much of CPU , all the 6 cores > were used. > On capturing the thread dump we saw that large number of threads were in the > running state and in : > at java.util.WeakHashMap.get(WeakHashMap.java:403) > at > org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425) > > So we are suspecting that the thread has entered into indefinite while loop > and hogging all the CPU resources. > I have attached the thread dump for reference. > > what is the solution for this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated BEANUTILS-509: --- Attachment: BEANUTILS-509.diff > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: 2018-10-13T11-43-27_961-jvmRun1.dump, > 2018-10-13T11-43-27_961.dumpstream, BEANUTILS-509.diff, WrapDynaCache.patch, > WrapDynaCache_after_svn_commit.patch, console.log.backup > > > We noticed that our application was using too much of CPU , all the 6 cores > were used. > On capturing the thread dump we saw that large number of threads were in the > running state and in : > at java.util.WeakHashMap.get(WeakHashMap.java:403) > at > org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425) > > So we are suspecting that the thread has entered into indefinite while loop > and hogging all the CPU resources. > I have attached the thread dump for reference. > > what is the solution for this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[
https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649046#comment-16649046
]
Gary Gregory commented on BEANUTILS-509:
For now, I can see that wrapping the weak map into a synchronized map may help
but this causes the build to fail, not because any unit tests fail, but because
the Maven Surefire plugin that runs the tests blows up:
{noformat}
[WARNING] Tests run: 1279, Failures: 0, Errors: 0, Skipped: 3
[INFO]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 06:15 min
[INFO] Finished at: 2018-10-13T11:28:38-06:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test (default-test) on
project commons-beanutils2: There are test failures.
[ERROR]
[ERROR] Please refer to
C:\vcs\svn\apache\commons\trunks-proper\beanutils\target\surefire-reports for
the individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump,
[date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] ExecutionException The forked VM terminated without properly saying
goodbye. VM crash or System.exit called?
[ERROR] Command was cmd.exe /X /C ""C:\Program
Files\Java\jdk1.8.0_181\jre\bin\java" -Xmx56M
-javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.2\\org.jacoco.agent-0.8.2-runtime.jar=destfile=C:\\vcs\\svn\\apache\\commons\\trunks-proper\\beanutils\\target\\jacoco.exec
-jar
C:\Users\ggregory\AppData\Local\Temp\surefire4491303226062350457\surefirebooter7341664506376672162.jar
C:\Users\ggregory\AppData\Local\Temp\surefire4491303226062350457
2018-10-13T11-22-41_548-jvmRun1 surefire7040480156590727732tmp
surefire_356812217102022201471tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException:
ExecutionException The forked VM terminated without properly saying goodbye. VM
crash or System.exit called?
[ERROR] Command was cmd.exe /X /C ""C:\Program
Files\Java\jdk1.8.0_181\jre\bin\java" -Xmx56M
-javaagent:C:\\Users\\ggregory\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.2\\org.jacoco.agent-0.8.2-runtime.jar=destfile=C:\\vcs\\svn\\apache\\commons\\trunks-proper\\beanutils\\target\\jacoco.exec
-jar
C:\Users\ggregory\AppData\Local\Temp\surefire4491303226062350457\surefirebooter7341664506376672162.jar
C:\Users\ggregory\AppData\Local\Temp\surefire4491303226062350457
2018-10-13T11-22-41_548-jvmRun1 surefire7040480156590727732tmp
surefire_356812217102022201471tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:510)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:457)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:298)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
[ERROR] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
[ERROR]
[jira] [Updated] (COLLECTIONS-700) Add a ConcurrentWeakHashMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated COLLECTIONS-700:
-
Description:
Add a {{ConcurrentWeakHashMap}}: A concurrent
{{[WeakHashMap|https://docs.oracle.com/javase/8/docs/api/java/util/WeakHashMap.html]]}}.
A need for this was found to best support BeanUtils's BEANUTILS-509
This issue is looking for a volunteer.
was:Add a {{ConcurrentWeakHashMap}}: A concurrent
{{[WeakHashMap|https://docs.oracle.com/javase/8/docs/api/java/util/WeakHashMap.html]]}}.
A need for this was found to best support BeanUtils's BEANUTILS-509
> Add a ConcurrentWeakHashMap
> ---
>
> Key: COLLECTIONS-700
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-700
> Project: Commons Collections
> Issue Type: New Feature
> Components: Map
>Reporter: Gary Gregory
>Priority: Major
>
> Add a {{ConcurrentWeakHashMap}}: A concurrent
> {{[WeakHashMap|https://docs.oracle.com/javase/8/docs/api/java/util/WeakHashMap.html]]}}.
> A need for this was found to best support BeanUtils's BEANUTILS-509
> This issue is looking for a volunteer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (COLLECTIONS-700) Add a ConcurrentWeakHashMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated COLLECTIONS-700:
-
Description:
Add a {{ConcurrentWeakHashMap}}: A concurrent
{{[WeakHashMap|https://docs.oracle.com/javase/8/docs/api/java/util/WeakHashMap.html]}}.
A need for this was found to best support BeanUtils's BEANUTILS-509
This issue is looking for a volunteer.
was:
Add a {{ConcurrentWeakHashMap}}: A concurrent
{{[WeakHashMap|https://docs.oracle.com/javase/8/docs/api/java/util/WeakHashMap.html]]}}.
A need for this was found to best support BeanUtils's BEANUTILS-509
This issue is looking for a volunteer.
> Add a ConcurrentWeakHashMap
> ---
>
> Key: COLLECTIONS-700
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-700
> Project: Commons Collections
> Issue Type: New Feature
> Components: Map
>Reporter: Gary Gregory
>Priority: Major
>
> Add a {{ConcurrentWeakHashMap}}: A concurrent
> {{[WeakHashMap|https://docs.oracle.com/javase/8/docs/api/java/util/WeakHashMap.html]}}.
> A need for this was found to best support BeanUtils's BEANUTILS-509
> This issue is looking for a volunteer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (COLLECTIONS-700) Add a ConcurrentWeakHashMap
Gary Gregory created COLLECTIONS-700:
Summary: Add a ConcurrentWeakHashMap
Key: COLLECTIONS-700
URL: https://issues.apache.org/jira/browse/COLLECTIONS-700
Project: Commons Collections
Issue Type: New Feature
Components: Map
Reporter: Gary Gregory
Add a {{ConcurrentWeakHashMap}}: A concurrent
{{[WeakHashMap|https://docs.oracle.com/javase/8/docs/api/java/util/WeakHashMap.html]]}}.
A need for this was found to best support BeanUtils's BEANUTILS-509
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-698) Expand LoopingListIterator
[
https://issues.apache.org/jira/browse/COLLECTIONS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649001#comment-16649001
]
BELUGA BEHR commented on COLLECTIONS-698:
-
As always, if I have time. I put it out there in the hopes that it piques
someone's interest. Good starter for a new contributor.
> Expand LoopingListIterator
> --
>
> Key: COLLECTIONS-698
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-698
> Project: Commons Collections
> Issue Type: Improvement
> Components: Iterator
>Affects Versions: 4.2
>Reporter: BELUGA BEHR
>Priority: Minor
>
> Please enhance {{LoopingListIterator}} to accept a starting offset and a
> number to indicate the number of loops.
> https://docs.oracle.com/javase/7/docs/api/java/util/List.html#listIterator(int)
> {code:java}
> public LoopingListIterator(List list, int offset, int loops);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-699) Add a PairingIterator
[
https://issues.apache.org/jira/browse/COLLECTIONS-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649002#comment-16649002
]
BELUGA BEHR commented on COLLECTIONS-699:
-
As always, if I have time. I put it out there in the hopes that it piques
someone's interest. Good starter for a new contributor.
> Add a PairingIterator
> -
>
> Key: COLLECTIONS-699
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-699
> Project: Commons Collections
> Issue Type: Improvement
> Components: Iterator
>Affects Versions: 4.2
>Reporter: BELUGA BEHR
>Priority: Major
>
> Currently there exists a {{ZippingIterator}}, however, I am looking for a
> {{PairingIterator}}. A {{PairingIterator}} would accept two Iterables and for
> each call to {{next()}} should return a {{Pair}} object containing a
> reference to the next item in each Iterable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-698) Expand LoopingListIterator
[
https://issues.apache.org/jira/browse/COLLECTIONS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648995#comment-16648995
]
Gary Gregory commented on COLLECTIONS-698:
--
Hi [~belugabehr],
Do you plan on providing a patch?
Gary
> Expand LoopingListIterator
> --
>
> Key: COLLECTIONS-698
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-698
> Project: Commons Collections
> Issue Type: Improvement
> Components: Iterator
>Affects Versions: 4.2
>Reporter: BELUGA BEHR
>Priority: Minor
>
> Please enhance {{LoopingListIterator}} to accept a starting offset and a
> number to indicate the number of loops.
> https://docs.oracle.com/javase/7/docs/api/java/util/List.html#listIterator(int)
> {code:java}
> public LoopingListIterator(List list, int offset, int loops);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-699) Add a PairingIterator
[
https://issues.apache.org/jira/browse/COLLECTIONS-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648993#comment-16648993
]
Gary Gregory commented on COLLECTIONS-699:
--
Hi [~belugabehr],
Do you plan on providing a patch?
Gary
> Add a PairingIterator
> -
>
> Key: COLLECTIONS-699
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-699
> Project: Commons Collections
> Issue Type: Improvement
> Components: Iterator
>Affects Versions: 4.2
>Reporter: BELUGA BEHR
>Priority: Major
>
> Currently there exists a {{ZippingIterator}}, however, I am looking for a
> {{PairingIterator}}. A {{PairingIterator}} would accept two Iterables and for
> each call to {{next()}} should return a {{Pair}} object containing a
> reference to the next item in each Iterable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
