[jira] [Comment Edited] (POOL-240) GKOP: invalidateObject does not unblock threads waiting in borrowObject
[ https://issues.apache.org/jira/browse/POOL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831055#comment-13831055 ] Phil Steitz edited comment on POOL-240 at 11/25/13 5:23 AM: I can think of two, both pretty ugly, workarounds for this issue until we get 2.0.1 with a fix out. 1. For the specific issue in the report (invaliateObject not freeing capacity), follow invalidateObject with addObject. 2. Enable the evictor (set timeBetweenEvictionRuns to a positive value) and set minIdle to 1. This will handle both the invalidateObject and failed validation on return cases. Unfortunately, relief for blocked threads will only come when the evictor runs. was (Author: psteitz): I can think of two, both pretty ugly, workarounds for this issue until we get 2.0.1 with a fix out. 1. For the specific issue in the report (invaliateObject not freeing capacity), follow invalidateObject with a borrow-return sequence. The borrow will be allowed to create a new object and the return will make it available to waiting threads. 2. Enable the evictor (set timeBetweenEvictionRuns to a positive value) and set minIdle to 1. This will handle both the invalidateObject and failed validation on return cases. Unfortunately, relief for blocked threads will only come when the evictor runs. > GKOP: invalidateObject does not unblock threads waiting in borrowObject > --- > > Key: POOL-240 > URL: https://issues.apache.org/jira/browse/POOL-240 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Dan McNulty > Fix For: 2.0.1 > > Attachments: InvalidateObjectTest.java > > > It appears that when threads are blocked in GKOP.borrowObject due to max > object limits being reached and another thread calls invalidateObject, the > threads blocked in GKOP.borrowObject are not woken up to attempt to create a > new object. > Have the semantics changed for invalidate in 2.0? > Attached is a unit test that demonstrates this issue. I should note that this > test passed against POOL 1.5, after making the appropriate changes due to the > API changes in 2.0. > After a cursory glance through the source for GenericObjectPool, it looks > like it might be affected by the same issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (LANG-863) Method returns number of inheritance hops between parent and subclass
[
https://issues.apache.org/jira/browse/LANG-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved LANG-863.
---
Resolution: Fixed
Fix Version/s: (was: Review Patch)
3.2
URL: http://svn.apache.org/r1545145
Log:
LANG-863 Method returns number of inheritance hops between parent and subclass
Added:
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/reflect/InheritanceUtils.java
(with props)
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/reflect/InheritanceUtilsTest.java
(with props)
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/reflect/testbed/AnotherChild.java
(with props)
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/reflect/testbed/AnotherParent.java
(with props)
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/reflect/testbed/Grandchild.java
(with props)
Modified:
commons/proper/lang/trunk/src/changes/changes.xml
> Method returns number of inheritance hops between parent and subclass
> -
>
> Key: LANG-863
> URL: https://issues.apache.org/jira/browse/LANG-863
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.reflect.*
>Reporter: Daneel S. Yaitskov
> Fix For: 3.2
>
> Attachments: LANG-863.patch, LANG-863.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> For example.
> class A {
> }
> class B extends A {
> }
> class C extends B {
> }
> int d;
> d = InheritanceUtils.distance(A.class, A.class);
> Assert.assertEquals(0, d);
> d = InheritanceUtils.distance(B.class, A.class);
> Assert.assertEquals(1, d);
> d = InheritanceUtils.distance(C.class, A.class);
> Assert.assertEquals(2, d);
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (IO-406) Move StringBufferOutputStream class to apache commons io project.
[ https://issues.apache.org/jira/browse/IO-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831157#comment-13831157 ] Sebb commented on IO-406: - +1 to AppendableOS > Move StringBufferOutputStream class to apache commons io project. > - > > Key: IO-406 > URL: https://issues.apache.org/jira/browse/IO-406 > Project: Commons IO > Issue Type: Task > Components: Streams/Writers >Affects Versions: 2.4 > Environment: Regardless >Reporter: cynthia avishegnath > Labels: commons, geronimo, io, refactor, util > Fix For: 2.5 > > Attachments: IO-406-AppendableOutputStream.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Move org.apache.geronimo.mail.util.StringBufferOutputStream class to apache > commons io project. > Many would like to use that class without having to pull in dependency on > Geronimo, but also wish to comply to DIE-DRY by not replicating that class in > our respective personal libraries. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (IO-410) [IO] Readfully() That Returns A Byte Array
[
https://issues.apache.org/jira/browse/IO-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved IO-410.
-
Resolution: Fixed
Fix Version/s: 2.5
URL: http://svn.apache.org/r1545141
Log:
IO-410 Readfully() That Returns A Byte Array
Modified:
commons/proper/io/trunk/src/changes/changes.xml
commons/proper/io/trunk/src/main/java/org/apache/commons/io/IOUtils.java
commons/proper/io/trunk/src/test/java/org/apache/commons/io/IOUtilsTestCase.java
> [IO] Readfully() That Returns A Byte Array
> --
>
> Key: IO-410
> URL: https://issues.apache.org/jira/browse/IO-410
> Project: Commons IO
> Issue Type: Wish
> Components: Utilities
>Reporter: BELUGA BEHR
>Priority: Minor
> Fix For: 2.5
>
> Attachments: IOUtils.java.patch, IOUtilsTestCase.java.patch
>
>
> I am looking for an implementation withe the following method signature:
> {code}
> public static byte[] readFully(final InputStream input, long length) throws
> IOException
> {code}
> I have needed this when parsing different protocols. For example, if the
> protocol has a fixed-length header with 40 bytes, I may just want to
> instantiate the small buffer with the entire header and then pick it apart.
> In my implementation of my business logic, if the header cannot be read in
> then it should throw an exception for being malformed.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (MATH-1066) Add Bessel functions of the first kind
[ https://issues.apache.org/jira/browse/MATH-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Wignall updated MATH-1066: Description: According to the Wish List, special functions are a priority item to be added to ACM. As Bessel functions (http://en.wikipedia.org/wiki/Bessel_function) are listed by name, I have translated some Fortran code from Netlib -- specifically, http://www.netlib.org/specfun/rjbesl -- for Bessel functions of the first kind. (was: According to the Wish List, special functions are a priority item to be added to ACM. As Bessel functions (http://en.wikipedia.org/wiki/Bessel_function) are listed by name, I have translated some Fortran code from Netlib--specifically, http://www.netlib.org/specfun/rjbesl--for Bessel functions of the first kind.) > Add Bessel functions of the first kind > -- > > Key: MATH-1066 > URL: https://issues.apache.org/jira/browse/MATH-1066 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Brian Wignall > Labels: newbie, patch, special-functions > Attachments: patch_besselj > > Original Estimate: 168h > Remaining Estimate: 168h > > According to the Wish List, special functions are a priority item to be added > to ACM. As Bessel functions (http://en.wikipedia.org/wiki/Bessel_function) > are listed by name, I have translated some Fortran code from Netlib -- > specifically, http://www.netlib.org/specfun/rjbesl -- for Bessel functions of > the first kind. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1066) Add Bessel functions of the first kind
[ https://issues.apache.org/jira/browse/MATH-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Wignall updated MATH-1066: Attachment: patch_besselj My first patch submission; feedback and comments welcomed. I have signed and submitted a CLA. > Add Bessel functions of the first kind > -- > > Key: MATH-1066 > URL: https://issues.apache.org/jira/browse/MATH-1066 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Brian Wignall > Labels: newbie, patch, special-functions > Attachments: patch_besselj > > Original Estimate: 168h > Remaining Estimate: 168h > > According to the Wish List, special functions are a priority item to be added > to ACM. As Bessel functions (http://en.wikipedia.org/wiki/Bessel_function) > are listed by name, I have translated some Fortran code from > Netlib--specifically, http://www.netlib.org/specfun/rjbesl--for Bessel > functions of the first kind. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1066) Add Bessel functions of the first kind
Brian Wignall created MATH-1066: --- Summary: Add Bessel functions of the first kind Key: MATH-1066 URL: https://issues.apache.org/jira/browse/MATH-1066 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Brian Wignall According to the Wish List, special functions are a priority item to be added to ACM. As Bessel functions (http://en.wikipedia.org/wiki/Bessel_function) are listed by name, I have translated some Fortran code from Netlib--specifically, http://www.netlib.org/specfun/rjbesl--for Bessel functions of the first kind. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (POOL-240) GKOP: invalidateObject does not unblock threads waiting in borrowObject
[ https://issues.apache.org/jira/browse/POOL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831055#comment-13831055 ] Phil Steitz commented on POOL-240: -- I can think of two, both pretty ugly, workarounds for this issue until we get 2.0.1 with a fix out. 1. For the specific issue in the report (invaliateObject not freeing capacity), follow invalidateObject with a borrow-return sequence. The borrow will be allowed to create a new object and the return will make it available to waiting threads. 2. Enable the evictor (set timeBetweenEvictionRuns to a positive value) and set minIdle to 1. This will handle both the invalidateObject and failed validation on return cases. Unfortunately, relief for blocked threads will only come when the evictor runs. > GKOP: invalidateObject does not unblock threads waiting in borrowObject > --- > > Key: POOL-240 > URL: https://issues.apache.org/jira/browse/POOL-240 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Dan McNulty > Fix For: 2.0.1 > > Attachments: InvalidateObjectTest.java > > > It appears that when threads are blocked in GKOP.borrowObject due to max > object limits being reached and another thread calls invalidateObject, the > threads blocked in GKOP.borrowObject are not woken up to attempt to create a > new object. > Have the semantics changed for invalidate in 2.0? > Attached is a unit test that demonstrates this issue. I should note that this > test passed against POOL 1.5, after making the appropriate changes due to the > API changes in 2.0. > After a cursory glance through the source for GenericObjectPool, it looks > like it might be affected by the same issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (POOL-240) GKOP: invalidateObject does not unblock threads waiting in borrowObject
[ https://issues.apache.org/jira/browse/POOL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated POOL-240: - Fix Version/s: 2.0.1 > GKOP: invalidateObject does not unblock threads waiting in borrowObject > --- > > Key: POOL-240 > URL: https://issues.apache.org/jira/browse/POOL-240 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Dan McNulty > Fix For: 2.0.1 > > Attachments: InvalidateObjectTest.java > > > It appears that when threads are blocked in GKOP.borrowObject due to max > object limits being reached and another thread calls invalidateObject, the > threads blocked in GKOP.borrowObject are not woken up to attempt to create a > new object. > Have the semantics changed for invalidate in 2.0? > Attached is a unit test that demonstrates this issue. I should note that this > test passed against POOL 1.5, after making the appropriate changes due to the > API changes in 2.0. > After a cursory glance through the source for GenericObjectPool, it looks > like it might be affected by the same issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (POOL-240) GKOP: invalidateObject does not unblock threads waiting in borrowObject
[ https://issues.apache.org/jira/browse/POOL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831031#comment-13831031 ] Phil Steitz commented on POOL-240: -- I committed Dan's test case (thanks!) disabled in r1545063. I also committed (disabled, failing) tests for both invalidateObject and validation failures on return for GOP in r1544948. In r1544942, I added similar tests for GOP in the 1.5 branch, demonstrating that this bug is not present in 1.x (at least for GOP, but GKOP should be the same). > GKOP: invalidateObject does not unblock threads waiting in borrowObject > --- > > Key: POOL-240 > URL: https://issues.apache.org/jira/browse/POOL-240 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Dan McNulty > Attachments: InvalidateObjectTest.java > > > It appears that when threads are blocked in GKOP.borrowObject due to max > object limits being reached and another thread calls invalidateObject, the > threads blocked in GKOP.borrowObject are not woken up to attempt to create a > new object. > Have the semantics changed for invalidate in 2.0? > Attached is a unit test that demonstrates this issue. I should note that this > test passed against POOL 1.5, after making the appropriate changes due to the > API changes in 2.0. > After a cursory glance through the source for GenericObjectPool, it looks > like it might be affected by the same issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (MATH-1065) EnumeratedRealDistribution.inverseCumulativeProbability returns values not in the samples set
[ https://issues.apache.org/jira/browse/MATH-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830983#comment-13830983 ] Phil Steitz edited comment on MATH-1065 at 11/24/13 5:17 PM: - I think the intent of this class is to represent a discrete, but real-valued distribution. EnumeratedDistributions are discrete distributions with a finite, "enumerated" set of values. The problem here (as Thomas notes) is that EnumeratedRealDistribution extends AbstractRealDistribution and does not override the default inverse cum method that basically assumes a continuous distribution. What it should implement is a discrete algorithm like what Thomas has suggested. was (Author: psteitz): I think the intent of this class is to represent a discrete, but real-valued distribution. EnumeratedDistributions are discrete distributions with a finite, "enumerated" set of values. The problem here is that EnumeratedRealDistribution extends AbstractRealDistribution and does not override the default inverse cum method that basically assumes a continuous distribution. What it should implement is something like the discrete algorithm implemented in AbstractIntegerDistribution. I agree this is a bug and I think the correct fix is to implement inverseCumulativeProbability in EnumeratedRealDistribution by adapting the implementation of this method in AbstractIntegerDistribution. > EnumeratedRealDistribution.inverseCumulativeProbability returns values not in > the samples set > - > > Key: MATH-1065 > URL: https://issues.apache.org/jira/browse/MATH-1065 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: matteodg > Fix For: 4.0, 3.3 > > Attachments: EnumeratedRealDistributionTest.java > > > The method EnumeratedRealDistribution.inverseCumulativeProbability() > sometimes returns values that are not in the initial samples domain... > I will attach a test to exploit this bug. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1065) EnumeratedRealDistribution.inverseCumulativeProbability returns values not in the samples set
[ https://issues.apache.org/jira/browse/MATH-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830983#comment-13830983 ] Phil Steitz commented on MATH-1065: --- I think the intent of this class is to represent a discrete, but real-valued distribution. EnumeratedDistributions are discrete distributions with a finite, "enumerated" set of values. The problem here is that EnumeratedRealDistribution extends AbstractRealDistribution and does not override the default inverse cum method that basically assumes a continuous distribution. What it should implement is something like the discrete algorithm implemented in AbstractIntegerDistribution. I agree this is a bug and I think the correct fix is to implement inverseCumulativeProbability in EnumeratedRealDistribution by adapting the implementation of this method in AbstractIntegerDistribution. > EnumeratedRealDistribution.inverseCumulativeProbability returns values not in > the samples set > - > > Key: MATH-1065 > URL: https://issues.apache.org/jira/browse/MATH-1065 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: matteodg > Fix For: 4.0, 3.3 > > Attachments: EnumeratedRealDistributionTest.java > > > The method EnumeratedRealDistribution.inverseCumulativeProbability() > sometimes returns values that are not in the initial samples domain... > I will attach a test to exploit this bug. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COLLECTIONS-356) Request for a Many-to-Many BidiMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830963#comment-13830963 ] Radford Tam commented on COLLECTIONS-356: - Yes, I've been considering this. I've already had to override much of the test code for BidiMap while writing the unit test, because a lot of it assumes the one-to-one relationship. Let me think more on it. > Request for a Many-to-Many BidiMap > -- > > Key: COLLECTIONS-356 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-356 > Project: Commons Collections > Issue Type: New Feature > Components: Collection >Reporter: Franz Wong >Priority: Minor > Fix For: 4.x > > > Currently, BidiMap supports one to one relationship. However, in real life, > there are many many-to-many relationships. Take an example of student and > course. One student can take many courses while one course contain many > students. It would be useful to have a class to manipulate such situation. > The work around currently is using 2 hash maps. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1065) EnumeratedRealDistribution.inverseCumulativeProbability returns values not in the samples set
[
https://issues.apache.org/jira/browse/MATH-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830953#comment-13830953
]
Thomas Neidhart commented on MATH-1065:
---
For the other failing tests: I am not sure what the enumerated distribution
tries to achieve:
* a discrete probability distribution
* a distribution with continuous and discrete parts
in case of a discrete probability distribution the inverseCumulativeProbability
method is clearly wrong, and would have to fixed like this:
{noformat}
public double inverseCumulativeProbability(final double p) throws
OutOfRangeException {
double probability = 0;
double x = getSupportLowerBound();
for (final Pair sample : innerDistribution.getPmf()) {
if (sample.getValue() == 0.0) {
continue;
}
probability += sample.getValue();
if (probability <= p) {
x = sample.getKey();
}
if (probability >= p) {
break;
}
}
return x;
}
{noformat}
But then your other test cases are wrong imho:
{noformat}
inverseCumulativeProbability(0.5) = 14 instead of 18
inverseCumulativeProbability(0.5624) = 14 instead of 18
inverseCumulativeProbability(0.5626) = 18 instead of 28
inverseCumulativeProbability(0.7600) = 28 instead of 31
{noformat}
> EnumeratedRealDistribution.inverseCumulativeProbability returns values not in
> the samples set
> -
>
> Key: MATH-1065
> URL: https://issues.apache.org/jira/browse/MATH-1065
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
>Reporter: matteodg
> Fix For: 4.0, 3.3
>
> Attachments: EnumeratedRealDistributionTest.java
>
>
> The method EnumeratedRealDistribution.inverseCumulativeProbability()
> sometimes returns values that are not in the initial samples domain...
> I will attach a test to exploit this bug.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (MATH-1065) EnumeratedRealDistribution.inverseCumulativeProbability returns values not in the samples set
[
https://issues.apache.org/jira/browse/MATH-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830950#comment-13830950
]
Thomas Neidhart commented on MATH-1065:
---
Hi Matteo,
regarding the numerical issues:
the distribution works internally with an absolute accuracy of 1e-6. The
results should be compared with an epsilon value like this.
There is currently no easy way to set another accuracy, but you can instantiate
an EnumeratedRealDistribution like this, and override the
getSolverAbsoluteAccuracy method:
{noformat}
DISTRIBUTION = new EnumeratedRealDistribution(new double[]{
14.0, 18.0, 21.0, 28.0, 31.0, 33.0
}, new double[]{
4.0 / 16.0, 5.0 / 16.0, 0.0 / 16.0, 3.0 / 16.0, 1.0 / 16.0, 3.0 /
16.0
}) {
@Override
protected double getSolverAbsoluteAccuracy() {
return 1e-9;
}
};
{noformat}
> EnumeratedRealDistribution.inverseCumulativeProbability returns values not in
> the samples set
> -
>
> Key: MATH-1065
> URL: https://issues.apache.org/jira/browse/MATH-1065
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
>Reporter: matteodg
> Fix For: 4.0, 3.3
>
> Attachments: EnumeratedRealDistributionTest.java
>
>
> The method EnumeratedRealDistribution.inverseCumulativeProbability()
> sometimes returns values that are not in the initial samples domain...
> I will attach a test to exploit this bug.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (COLLECTIONS-503) IfTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830944#comment-13830944
]
Thomas Neidhart commented on COLLECTIONS-503:
-
Hi Josh,
thanks for your contribution, looks good except for missing unit tests.
On a second thought, there is already a SwitchTransformer which is a more
generalized version of an IfTransformer. What do you think of just updating the
SwitchTransformer to more easily create on for the your use-case: if else?
This would require only one additional factory method:
{noformat}
public static Transformer switchTransformer(final Predicate predicate,
final Transformer trueTransformers,
final Transformer falseTransformer) {
}
{noformat}
> IfTransformer
> -
>
> Key: COLLECTIONS-503
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-503
> Project: Commons Collections
> Issue Type: New Feature
> Components: Functor
>Reporter: Josh Cain
>Priority: Trivial
> Fix For: 4.0.1
>
> Attachments: ifTransformer.patch
>
>
> Just thought a basic ifTransformer that performs operations based on a
> predicate would be useful. I know this functionality can be accomplished via
> a switchTransformer, but sometimes it would just be easier and more clear to
> have an ifTransformer.
> I attached a draft of what it could look like. Let me know if this is
> something that should be included and I can polish it and write some tests.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (COLLECTIONS-471) Add a BoundedIterator which returns at most limit elements
[ https://issues.apache.org/jira/browse/COLLECTIONS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-471: Fix Version/s: (was: 4.x) 4.0.1 > Add a BoundedIterator which returns at most limit elements > -- > > Key: COLLECTIONS-471 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-471 > Project: Commons Collections > Issue Type: New Feature >Reporter: Thomas Neidhart > Fix For: 4.0.1 > > Attachments: BoundedIterator.java, BoundedIteratorTest.java > > > It would be nice to have a decorator which bounds the number of elements > returned by the decorated iterator. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (COLLECTIONS-503) IfTransformer
[ https://issues.apache.org/jira/browse/COLLECTIONS-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-503: Fix Version/s: 4.0.1 > IfTransformer > - > > Key: COLLECTIONS-503 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-503 > Project: Commons Collections > Issue Type: New Feature > Components: Functor >Reporter: Josh Cain >Priority: Trivial > Fix For: 4.0.1 > > Attachments: ifTransformer.patch > > > Just thought a basic ifTransformer that performs operations based on a > predicate would be useful. I know this functionality can be accomplished via > a switchTransformer, but sometimes it would just be easier and more clear to > have an ifTransformer. > I attached a draft of what it could look like. Let me know if this is > something that should be included and I can polish it and write some tests. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COLLECTIONS-356) Request for a Many-to-Many BidiMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830929#comment-13830929 ] Thomas Neidhart commented on COLLECTIONS-356: - In this case we should not implement the BidiMap interface to avoid confusion. We could create a MultiBidiMap interface similar to the MultiMap one for ordinary Maps. > Request for a Many-to-Many BidiMap > -- > > Key: COLLECTIONS-356 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-356 > Project: Commons Collections > Issue Type: New Feature > Components: Collection >Reporter: Franz Wong >Priority: Minor > Fix For: 4.x > > > Currently, BidiMap supports one to one relationship. However, in real life, > there are many many-to-many relationships. Take an example of student and > course. One student can take many courses while one course contain many > students. It would be useful to have a class to manipulate such situation. > The work around currently is using 2 hash maps. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (IMAGING-119) Convert ImageFormat from emulated enum to actual Java 5 enum
[ https://issues.apache.org/jira/browse/IMAGING-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic resolved IMAGING-119. -- Resolution: Fixed It's fine as is. Thank you, resolving fixed. > Convert ImageFormat from emulated enum to actual Java 5 enum > > > Key: IMAGING-119 > URL: https://issues.apache.org/jira/browse/IMAGING-119 > Project: Commons Imaging > Issue Type: Improvement >Affects Versions: 0.97 >Reporter: Matt Benson >Assignee: Matt Benson > Fix For: 1.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
