[jira] [Commented] (COLLECTIONS-439) TreeBag with comparator does not store non-key duplicates.
[ https://issues.apache.org/jira/browse/COLLECTIONS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655840#comment-13655840 ] Claude Warren commented on COLLECTIONS-439: --- While the MultiValueMap may do the same thing I have not looked. This is an implementation of Bag and operates like a non-unique index on a database table. (In fact that is what I use it to emulate) Asking if this is useful because it has similar functionality to MultiValueMap is like asking if Queue should be included when LinkedList can be used. You use Queue because it provides a clue to any developers reading your code what you are trying to do -- what you are thinking. The same with Bag vs MultiValueMap. I think it is a valid and useful addition to the collection and vote to include it. But then I contributed it so I would think that. :) > TreeBag with comparator does not store non-key duplicates. > -- > > Key: COLLECTIONS-439 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-439 > Project: Commons Collections > Issue Type: Improvement > Components: Bag >Affects Versions: 3.2.1 >Reporter: Claude Warren > Fix For: 4.x > > Attachments: COLLECTIONS-439.tar.gz, SortedBag.java > > > When storing objects that are sorted by a Comparator, if the differences in > the objects are not in the comparator the same version of the object is > returned. I expected that the sorted bag would work like a DB table with a > non-unique key -- ordered but duplicate only determined by Object.equals(). > I have implemented this type of bag using a TreeMap of List. My > implementation uses the Jena ExtendedIterator to make building the iterator() > and array() methods easier. > Will attach the code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBUTILS-107) Patch QueryLoader to also load from XML properties files
[ https://issues.apache.org/jira/browse/DBUTILS-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-107. --- Resolution: Fixed Fix Version/s: 1.6 Patch applied in r1482047 > Patch QueryLoader to also load from XML properties files > > > Key: DBUTILS-107 > URL: https://issues.apache.org/jira/browse/DBUTILS-107 > Project: Commons DbUtils > Issue Type: Improvement >Affects Versions: 1.5 >Reporter: PB >Priority: Minor > Fix For: 1.6 > > Attachments: DBUTILS-107.patch > > > This is a request to patch QueryLoader so that it calls loadFromXML when an > XML properties file is provided. Maintenance of long, multi-line queries can > be preferable in XML format compared to properties file format. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBUTILS-108) Create functionality to return auto-generated keys in batches of SQL inserts
[ https://issues.apache.org/jira/browse/DBUTILS-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-108. --- Resolution: Fixed Patch applied in r1482045 > Create functionality to return auto-generated keys in batches of SQL inserts > > > Key: DBUTILS-108 > URL: https://issues.apache.org/jira/browse/DBUTILS-108 > Project: Commons DbUtils > Issue Type: Improvement >Affects Versions: 1.6 >Reporter: Micah Huff > Fix For: 1.6 > > Attachments: dbutils-108.patch > > > Related to DBUTILS-87, there should be support for retrieving the > automatically-generated keys from a batch insert operation. Similar to how > singular insert was added to return the generated key, there should be an > insertBatch operation that allows the ResultSetHandler to perform an > operation with the newly generated keys. > I have a patch and will be submitting it soon for review. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBUTILS-100) columnLabel and columnname
[ https://issues.apache.org/jira/browse/DBUTILS-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-100. --- Resolution: Fixed Fix Version/s: 1.6 Fix applied in r1482051. > columnLabel and columnname > --- > > Key: DBUTILS-100 > URL: https://issues.apache.org/jira/browse/DBUTILS-100 > Project: Commons DbUtils > Issue Type: Improvement >Reporter: xiaofei.xu > Fix For: 1.6 > > > The method toMap(ResultSet rs) > should use getColumnLabel() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-109) AbstractExecutor.currentPosition should be an int
[ https://issues.apache.org/jira/browse/DBUTILS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656294#comment-13656294 ] William R. Speirs commented on DBUTILS-109: --- Sebb I think you fixed this in http://svn.apache.org/r1481212 right? > AbstractExecutor.currentPosition should be an int > - > > Key: DBUTILS-109 > URL: https://issues.apache.org/jira/browse/DBUTILS-109 > Project: Commons DbUtils > Issue Type: Bug >Reporter: Sebb > > AbstractExecutor.currentPosition is currently an Integer. > It is only used here: > posList.add(++currentPosition); > This involves converting the Integer to an int, incrementing the int and then > converting back to an Integer. > It would be rather more efficient to create the field as an int. > Alternatively, if the class is supposed to be thread-safe, maybe an > AtomicInteger would be better. > Integer is not the best choice here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-347) [contribution] LimitedSizeFifoMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656357#comment-13656357
]
Thomas Neidhart commented on COLLECTIONS-347:
-
This could still be a useful addition, as it decorates another map to be
bounded.
The patch has a few flaws that need to be corrected before committing:
* use the BoundedMap interface instead of the self-defined LimitedSizeMap
* modifications of the decorated map via iterator, entrySet or keySet are not
reflected in the decorator, i.e. the queue containing the inserted keys is not
updated accordingly
* do not catch a RuntimeException in put, but instead reorder the instructions
to make it fail-safe
* the unit test should be plugged into the testing framework, e.g. inherit
from AbstractIterableMapTest
> [contribution] LimitedSizeFifoMap
> -
>
> Key: COLLECTIONS-347
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-347
> Project: Commons Collections
> Issue Type: New Feature
> Components: Map
>Reporter: Michael Thomas
>Priority: Minor
> Fix For: 4.x
>
> Attachments: LimitedSizeFifoMap.patch, LimitedSizeFifoMap.patch
>
>
> The {{LimitedSizeFifoMap}} never exceeds a given element limit by deleting
> old entries, whenever new ones are inserted. It may be of use for caches
> holding memory-intense objects (it is for me, anyway).
> The patch contains:
> * the interface {{LimitedSizeMap}}
> * the fully documented implementation {{LimitedSizeFifoMap}}, which deletes
> the oldest items first
> * the accompanying unit test
> If you find anything that needs improvement, please let me know.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBUTILS-109) AbstractExecutor.currentPosition should be an int
[ https://issues.apache.org/jira/browse/DBUTILS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved DBUTILS-109. -- Resolution: Fixed Fix Version/s: 2.0 Fixed in http://svn.apache.org/r1481212 > AbstractExecutor.currentPosition should be an int > - > > Key: DBUTILS-109 > URL: https://issues.apache.org/jira/browse/DBUTILS-109 > Project: Commons DbUtils > Issue Type: Bug >Reporter: Sebb > Fix For: 2.0 > > > AbstractExecutor.currentPosition is currently an Integer. > It is only used here: > posList.add(++currentPosition); > This involves converting the Integer to an int, incrementing the int and then > converting back to an Integer. > It would be rather more efficient to create the field as an int. > Alternatively, if the class is supposed to be thread-safe, maybe an > AtomicInteger would be better. > Integer is not the best choice here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COLLECTIONS-468) Change Bag interface and implementations to conform to Collection interface
Thomas Neidhart created COLLECTIONS-468: --- Summary: Change Bag interface and implementations to conform to Collection interface Key: COLLECTIONS-468 URL: https://issues.apache.org/jira/browse/COLLECTIONS-468 Project: Commons Collections Issue Type: Bug Reporter: Thomas Neidhart Fix For: 4.0 Several methods of the Bag interface do not conform to the Collection interface (e.g. add, remove, containsAll, removeAll, retainAll). This should be fixed for 4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-468) Change Bag interface and implementations to conform to Collection interface
[ https://issues.apache.org/jira/browse/COLLECTIONS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-468: Attachment: COLLECTIONS-468.patch Attached patch with the proposed changes: * update Bag interface to conform to Collection contract * update AbstractMapBag * update unit tests to inherit from AbstractCollectionTest > Change Bag interface and implementations to conform to Collection interface > --- > > Key: COLLECTIONS-468 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-468 > Project: Commons Collections > Issue Type: Bug >Reporter: Thomas Neidhart > Fix For: 4.0 > > Attachments: COLLECTIONS-468.patch > > > Several methods of the Bag interface do not conform to the Collection > interface (e.g. add, remove, containsAll, removeAll, retainAll). > This should be fixed for 4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-467) LRUMap remove callback
[ https://issues.apache.org/jira/browse/COLLECTIONS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656459#comment-13656459 ] Thomas Neidhart commented on COLLECTIONS-467: - You may take a look at the PassiveExpiringMap decorator which has been added recently to the trunk. For the other things, patches are, as always, very welcome. Regarding the callback, what do you think about a listener interface? Callbacks as protected methods always require subclassing, which may not always be useful / possible. > LRUMap remove callback > -- > > Key: COLLECTIONS-467 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-467 > Project: Commons Collections > Issue Type: New Feature >Affects Versions: 3.2 >Reporter: l0co >Priority: Minor > Fix For: 4.x > > > If you use LRUMap with objects that require doing some disposal when they are > dropped (eg. close()) and you hold these objects only in LRUMap, you cannot > do it with current implementation. I propose to add onRemove() and onAdd() > methods to the implementation, so that you can create anonymous inherited > class and be able to react to these events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-439) TreeBag with comparator does not store non-key duplicates.
[ https://issues.apache.org/jira/browse/COLLECTIONS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656464#comment-13656464 ] Thomas Neidhart commented on COLLECTIONS-439: - So, when I take the Queue/LinkedList example, then the MultiValueMap should actually also implement the Bag interface. This would avoid code duplication and also make the intent clearer imho. > TreeBag with comparator does not store non-key duplicates. > -- > > Key: COLLECTIONS-439 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-439 > Project: Commons Collections > Issue Type: Improvement > Components: Bag >Affects Versions: 3.2.1 >Reporter: Claude Warren > Fix For: 4.x > > Attachments: COLLECTIONS-439.tar.gz, SortedBag.java > > > When storing objects that are sorted by a Comparator, if the differences in > the objects are not in the comparator the same version of the object is > returned. I expected that the sorted bag would work like a DB table with a > non-unique key -- ordered but duplicate only determined by Object.equals(). > I have implemented this type of bag using a TreeMap of List. My > implementation uses the Jena ExtendedIterator to make building the iterator() > and array() methods easier. > Will attach the code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Moved] (FUNCTOR-26) functors filtering on bean properties using(== ,!=, >,>=.>.>=. isNull, Like,..... )
[
https://issues.apache.org/jira/browse/FUNCTOR-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart moved COLLECTIONS-305 to FUNCTOR-26:
Component/s: (was: Functor)
Fix Version/s: (was: 4.x)
Affects Version/s: (was: 3.2)
Workflow: jira (was: Default workflow, editable Closed status)
Key: FUNCTOR-26 (was: COLLECTIONS-305)
Project: Commons Functor (was: Commons Collections)
> functors filtering on bean properties using(== ,!=, >,>=.>.>=. isNull,
> Like,. )
> -
>
> Key: FUNCTOR-26
> URL: https://issues.apache.org/jira/browse/FUNCTOR-26
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Anil K.Kinge
>Assignee: Brent Worden
> Attachments: functors.propertypredicates.new.diff
>
>
> In my current project I created a set of new Predicates that I call as
> Property Predicates. These predicates can used to filter a collection based
> on property values.
> For example we have :
> Class Foo{
> String name;
> Int age;
> Address address;
> }
> Address{
> String street;
> String zip;
> }
> Collection myFoos ;
> And we want to find all the Foo in myFoos with name that starts with A, and
> age > 40 and who are living at Zip 07095 we can create a Predicate like
> follows:
> Predicate p = new PropertyLikePredicate("name","A*")
> .andGreaterThan("age",40)
> .andEquals(address.zip,"07095");
> Note: Like supports wildcards '*' and '?'
> What is even better is that these predicates work with collections too. What
> I mean is if we have :
> FooBar{
> String name;
> Collection addresses;
> }
> And you want to locate someone with a zip 07095 as part of anyof its'
> addresses all we need is to create a predicate :
> Predicate p = new PropertyEqualsPredicate("addresses[].zip","07095");
> My Predicate chain currently supports the following features:
> 1.andEquals
> 2.orEquals
> 3.andNotEquals
> 4.orNotEquals
> 5.andLike
> 6.orLike
> 7.andGreatorThan
> 8.orGreatorThan
> 9.andGreatorThanOrEquals
> 10. orGreatorThanOrEquals
> 11. andLessThan
> 12. orLessThan
> 13. andLessThanOrEquals
> 14. orLessThanOrEquals
> 15. isNull
> 16. isNotNull
> 17. orNull
> 18. orNotNull
> 19. orNullOrEmpty
> 20. orNotNullOrEmpty
> 21. andNullOrEmpty
> 22. andNotNullOrEmpty
> All features have accompanying testcases. In my opinion this is a powerful
> addition to the functors and I would like to contribute this work to the
> commons-collection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-354) Add Collection utils from MINA: e.g. CopyOnWriteMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-354. - Resolution: Won't Fix Fix Version/s: (was: 4.x) Resolve as Won't fix for now. > Add Collection utils from MINA: e.g. CopyOnWriteMap > --- > > Key: COLLECTIONS-354 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-354 > Project: Commons Collections > Issue Type: New Feature > Components: Map >Reporter: Sebb > > MINA has some useful Collection utilities, for example CopyOnWriteMap. > http://svn.apache.org/repos/asf/mina/trunk/core/src/main/java/org/apache/mina/util/CopyOnWriteMap.java > Several of the other utilities look useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-461) splitmap.TransformedMap is not really a Map
[ https://issues.apache.org/jira/browse/COLLECTIONS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-461: Fix Version/s: 4.x > splitmap.TransformedMap is not really a Map > --- > > Key: COLLECTIONS-461 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-461 > Project: Commons Collections > Issue Type: Bug >Reporter: Sebb > Fix For: 4.x > > > splitmap.TransformedMap is part of the Get/Put hierarchy, but it does not > behave like a proper Java Map. > In particular, java.util.Map.put(K, V) returns V. > However the collections Put interface returns Object. > As far as I can tell, this was done in order to be able to include > TransformedMap in the hiearchy. But the side effect is to break the generics > for all the non-transformer maps in the hierarchy. > Maybe there should be a separate PutTransformed interface which has the > appropriate generic types, i.e. > public T put(K key, V value) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-461) splitmap.TransformedMap is not really a Map
[ https://issues.apache.org/jira/browse/COLLECTIONS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656472#comment-13656472 ] Matt Benson commented on COLLECTIONS-461: - What value would one return? > splitmap.TransformedMap is not really a Map > --- > > Key: COLLECTIONS-461 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-461 > Project: Commons Collections > Issue Type: Bug >Reporter: Sebb > Fix For: 4.x > > > splitmap.TransformedMap is part of the Get/Put hierarchy, but it does not > behave like a proper Java Map. > In particular, java.util.Map.put(K, V) returns V. > However the collections Put interface returns Object. > As far as I can tell, this was done in order to be able to include > TransformedMap in the hiearchy. But the side effect is to break the generics > for all the non-transformer maps in the hierarchy. > Maybe there should be a separate PutTransformed interface which has the > appropriate generic types, i.e. > public T put(K key, V value) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-468) Change Bag interface and implementations to conform to Collection interface
[ https://issues.apache.org/jira/browse/COLLECTIONS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656474#comment-13656474 ] Emmanuel Bourg commented on COLLECTIONS-468: The change of return value on the add method bothers me. I have code that relies on this behavior and I think that's an important feature of the Bag interface. > Change Bag interface and implementations to conform to Collection interface > --- > > Key: COLLECTIONS-468 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-468 > Project: Commons Collections > Issue Type: Bug >Reporter: Thomas Neidhart > Fix For: 4.0 > > Attachments: COLLECTIONS-468.patch > > > Several methods of the Bag interface do not conform to the Collection > interface (e.g. add, remove, containsAll, removeAll, retainAll). > This should be fixed for 4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-461) splitmap.TransformedMap is not really a Map
[
https://issues.apache.org/jira/browse/COLLECTIONS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656484#comment-13656484
]
Thomas Neidhart commented on COLLECTIONS-461:
-
I just tried it out myself, and it seems to work as expected:
{noformat}
Map map = new HashMap();
TransformedMap mp =
TransformedMap.transformingMap(map,
new Transformer() {
public Integer transform(Integer input) {
return input + 1;
}
}, new Transformer() {
public String transform(String input) {
return "value:" + input;
}
});
String old = mp.put(1, "1");
System.out.println(old);
Put put = mp;
System.out.println(put);
{noformat}
> splitmap.TransformedMap is not really a Map
> ---
>
> Key: COLLECTIONS-461
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-461
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Sebb
> Fix For: 4.x
>
>
> splitmap.TransformedMap is part of the Get/Put hierarchy, but it does not
> behave like a proper Java Map.
> In particular, java.util.Map.put(K, V) returns V.
> However the collections Put interface returns Object.
> As far as I can tell, this was done in order to be able to include
> TransformedMap in the hiearchy. But the side effect is to break the generics
> for all the non-transformer maps in the hierarchy.
> Maybe there should be a separate PutTransformed interface which has the
> appropriate generic types, i.e.
> public T put(K key, V value)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-448) Proposal for addinig random pick methods to Bags
[ https://issues.apache.org/jira/browse/COLLECTIONS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-448: Summary: Proposal for addinig random pick methods to Bags (was: [PATCH] Proposal for addinig random pick methods to Bags) > Proposal for addinig random pick methods to Bags > > > Key: COLLECTIONS-448 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-448 > Project: Commons Collections > Issue Type: Wish > Components: Bag >Affects Versions: 4.0 >Reporter: Othmen Tiliouine >Priority: Minor > Labels: patch > Fix For: 4.x > > Attachments: pickFromABag2.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > Hello, > This is a patch to add two methods to Bag interface and classes > public E pick(); > public E pickAndRemit(); > as discussed in this mail. > - > http://mail-archives.apache.org/mod_mbox/commons-dev/201303.mbox/%3CCAChO4O-YRE%3Db1%3D4hEK%2BuhvpV6-OD3F3apyRn3mwjvGzUEXe%2BaQ%40mail.gmail.com%3E > I just saw the Bag interface and its implementations, I'm surprised that Bag > (and none of these implementations) expose the method > public T pick() and public T pickAndRemit() (pick a random element) > The Bag object we see in nature, it is mainly used to this, that's why it is > widely used in the probability that when I met 2 white balls and one black, > when I draw a ball randomly I have 2 times more likely to have a white ball > I think that if this caracteristic exists it would be very valuable. > -- > these methods pick a random element from the bag, The probability of picking > a copy of a given element is proportional to the number of copies of this > element in the bag. > the diference between pick() and pickAndRemit() is that with pick() the > picked element is removed from the bag. > this is my first contribution on open source project > if you accept to add this feature to bags and validate my patch i will > propose one other patch to add this methods > public Iterator pick(int n); //pick random n element (with remove) > public Iterator pickAndRemit(int n) ; //pick random n element (without > remove) > -Question : should i regenerate the serialVersionUID of classes that i have > changed ? > Othmen Tiliouine -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-347) Proposal for adding a LimitedSizeFifoMap decorator
[
https://issues.apache.org/jira/browse/COLLECTIONS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated COLLECTIONS-347:
Summary: Proposal for adding a LimitedSizeFifoMap decorator (was:
[contribution] LimitedSizeFifoMap)
> Proposal for adding a LimitedSizeFifoMap decorator
> --
>
> Key: COLLECTIONS-347
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-347
> Project: Commons Collections
> Issue Type: New Feature
> Components: Map
>Reporter: Michael Thomas
>Priority: Minor
> Fix For: 4.x
>
> Attachments: LimitedSizeFifoMap.patch, LimitedSizeFifoMap.patch
>
>
> The {{LimitedSizeFifoMap}} never exceeds a given element limit by deleting
> old entries, whenever new ones are inserted. It may be of use for caches
> holding memory-intense objects (it is for me, anyway).
> The patch contains:
> * the interface {{LimitedSizeMap}}
> * the fully documented implementation {{LimitedSizeFifoMap}}, which deletes
> the oldest items first
> * the accompanying unit test
> If you find anything that needs improvement, please let me know.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-448) Proposal for adding random pick methods to Bags
[ https://issues.apache.org/jira/browse/COLLECTIONS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-448: Summary: Proposal for adding random pick methods to Bags (was: Proposal for addinig random pick methods to Bags) > Proposal for adding random pick methods to Bags > --- > > Key: COLLECTIONS-448 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-448 > Project: Commons Collections > Issue Type: Wish > Components: Bag >Affects Versions: 4.0 >Reporter: Othmen Tiliouine >Priority: Minor > Labels: patch > Fix For: 4.x > > Attachments: pickFromABag2.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > Hello, > This is a patch to add two methods to Bag interface and classes > public E pick(); > public E pickAndRemit(); > as discussed in this mail. > - > http://mail-archives.apache.org/mod_mbox/commons-dev/201303.mbox/%3CCAChO4O-YRE%3Db1%3D4hEK%2BuhvpV6-OD3F3apyRn3mwjvGzUEXe%2BaQ%40mail.gmail.com%3E > I just saw the Bag interface and its implementations, I'm surprised that Bag > (and none of these implementations) expose the method > public T pick() and public T pickAndRemit() (pick a random element) > The Bag object we see in nature, it is mainly used to this, that's why it is > widely used in the probability that when I met 2 white balls and one black, > when I draw a ball randomly I have 2 times more likely to have a white ball > I think that if this caracteristic exists it would be very valuable. > -- > these methods pick a random element from the bag, The probability of picking > a copy of a given element is proportional to the number of copies of this > element in the bag. > the diference between pick() and pickAndRemit() is that with pick() the > picked element is removed from the bag. > this is my first contribution on open source project > if you accept to add this feature to bags and validate my patch i will > propose one other patch to add this methods > public Iterator pick(int n); //pick random n element (with remove) > public Iterator pickAndRemit(int n) ; //pick random n element (without > remove) > -Question : should i regenerate the serialVersionUID of classes that i have > changed ? > Othmen Tiliouine -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-461) splitmap.TransformedMap is not really a Map
[ https://issues.apache.org/jira/browse/COLLECTIONS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656488#comment-13656488 ] Matt Benson commented on COLLECTIONS-461: - Yes, but you didn't transform the keys and/or values to different *types*. ;) > splitmap.TransformedMap is not really a Map > --- > > Key: COLLECTIONS-461 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-461 > Project: Commons Collections > Issue Type: Bug >Reporter: Sebb > Fix For: 4.x > > > splitmap.TransformedMap is part of the Get/Put hierarchy, but it does not > behave like a proper Java Map. > In particular, java.util.Map.put(K, V) returns V. > However the collections Put interface returns Object. > As far as I can tell, this was done in order to be able to include > TransformedMap in the hiearchy. But the side effect is to break the generics > for all the non-transformer maps in the hierarchy. > Maybe there should be a separate PutTransformed interface which has the > appropriate generic types, i.e. > public T put(K key, V value) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-468) Change Bag interface and implementations to conform to Collection interface
[ https://issues.apache.org/jira/browse/COLLECTIONS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656489#comment-13656489 ] Thomas Neidhart commented on COLLECTIONS-468: - We obviously do not want to copy guava, but their MultiSet does conform to the Collection contract. > Change Bag interface and implementations to conform to Collection interface > --- > > Key: COLLECTIONS-468 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-468 > Project: Commons Collections > Issue Type: Bug >Reporter: Thomas Neidhart > Fix For: 4.0 > > Attachments: COLLECTIONS-468.patch > > > Several methods of the Bag interface do not conform to the Collection > interface (e.g. add, remove, containsAll, removeAll, retainAll). > This should be fixed for 4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-461) splitmap.TransformedMap is not really a Map
[
https://issues.apache.org/jira/browse/COLLECTIONS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656497#comment-13656497
]
Thomas Neidhart commented on COLLECTIONS-461:
-
well right, but this does not change anything:
{noformat}
Map map = new HashMap();
TransformedMap mp =
TransformedMap.transformingMap(map,
new Transformer() {
public String transform(Integer input) {
return String.valueOf(input + 1);
}
}, new Transformer() {
public String transform(Integer input) {
return "value:" + input;
}
});
String old = mp.put(1, 1);
System.out.println(old);
Put put = mp;
System.out.println(put);
{noformat}
What I wanted to test is whether the put returns Object or the given type V,
which it does ;-)
> splitmap.TransformedMap is not really a Map
> ---
>
> Key: COLLECTIONS-461
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-461
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Sebb
> Fix For: 4.x
>
>
> splitmap.TransformedMap is part of the Get/Put hierarchy, but it does not
> behave like a proper Java Map.
> In particular, java.util.Map.put(K, V) returns V.
> However the collections Put interface returns Object.
> As far as I can tell, this was done in order to be able to include
> TransformedMap in the hiearchy. But the side effect is to break the generics
> for all the non-transformer maps in the hierarchy.
> Maybe there should be a separate PutTransformed interface which has the
> appropriate generic types, i.e.
> public T put(K key, V value)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-460) Add IteratorQueue
[ https://issues.apache.org/jira/browse/COLLECTIONS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656501#comment-13656501 ] Thomas Neidhart commented on COLLECTIONS-460: - After some thought, I think we should better update IteratorChain to use a Queue internally. I am failing to see a use case for accessing the iterators in the chain. > Add IteratorQueue > - > > Key: COLLECTIONS-460 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-460 > Project: Commons Collections > Issue Type: New Feature > Components: Iterator >Reporter: Thomas Neidhart > Fix For: 4.0 > > > An IteratorQueue is equivalent to an IteratorChain with the difference that > the iterators to use are put into a queue instead of an list, and that they > are removed from the queue if an iterator is exhausted. > The IteratorChain keeps the iterators in the list even if they are exhausted, > thus they can not be gc'ed until the whole chain is done. The interface of > IteratorChain also contains a getIterators method, which returns the list of > iterators used by this chain. So instead of changing the IteratorChain, I > propose to add a separate class IteratorQueue with the described behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-461) splitmap.TransformedMap is not really a Map
[
https://issues.apache.org/jira/browse/COLLECTIONS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656508#comment-13656508
]
Matt Benson commented on COLLECTIONS-461:
-
Riight... I hadn't looked at this stuff in years. {{TransformedMap}} narrows
the RT from {{Object}} to return {{V}} from {{#put(J, U)}} and in that sense
will never behave like a regular {{Map}}--my point being that we don't know how
to "untransform" the value back to the {{U}} type. Returning the value
actually contained in the target map is the best we can do. The proposed
{{#putTransformed()}} method would still suffer the same problem: no way to
get back to a {{U}} type from the {{V}} contained in the decorated {{Map}}. Is
the issue that {{TransformedMap}} is still named \*Map? It was my intent that
placing it in the {{splitmap}} subpackage would, along with
[http://svn.apache.org/viewvc/commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/splitmap/package-info.java?view=markup],
make the intent clear: namely, that a "split map" is like a "map" but is
really a combination of {{Get}}/{{Put}} with no guarantees as to the type
assignability between the two. This was the only approach I found at the time
to allow the preservation of the functionality of {{TransformedMap}} while also
permitting it to be fully genericized.
> splitmap.TransformedMap is not really a Map
> ---
>
> Key: COLLECTIONS-461
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-461
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Sebb
> Fix For: 4.x
>
>
> splitmap.TransformedMap is part of the Get/Put hierarchy, but it does not
> behave like a proper Java Map.
> In particular, java.util.Map.put(K, V) returns V.
> However the collections Put interface returns Object.
> As far as I can tell, this was done in order to be able to include
> TransformedMap in the hiearchy. But the side effect is to break the generics
> for all the non-transformer maps in the hierarchy.
> Maybe there should be a separate PutTransformed interface which has the
> appropriate generic types, i.e.
> public T put(K key, V value)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-461) splitmap.TransformedMap is not really a Map
[ https://issues.apache.org/jira/browse/COLLECTIONS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656536#comment-13656536 ] Sebb commented on COLLECTIONS-461: -- bq. Is the issue that TransformedMap is still named *Map? No, the problem here is that the "real" Map classes are compromised because Put#put(K, V) returns Object rather than V. The Put interface is not exactly the same as the "write" subset of java.util.Map. > splitmap.TransformedMap is not really a Map > --- > > Key: COLLECTIONS-461 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-461 > Project: Commons Collections > Issue Type: Bug >Reporter: Sebb > Fix For: 4.x > > > splitmap.TransformedMap is part of the Get/Put hierarchy, but it does not > behave like a proper Java Map. > In particular, java.util.Map.put(K, V) returns V. > However the collections Put interface returns Object. > As far as I can tell, this was done in order to be able to include > TransformedMap in the hiearchy. But the side effect is to break the generics > for all the non-transformer maps in the hierarchy. > Maybe there should be a separate PutTransformed interface which has the > appropriate generic types, i.e. > public T put(K key, V value) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-461) splitmap.TransformedMap is not really a Map
[
https://issues.apache.org/jira/browse/COLLECTIONS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656547#comment-13656547
]
Matt Benson commented on COLLECTIONS-461:
-
I'm still not connecting the dots as to how the "real" Maps are compromised.
{{TransformedMap}} isn't a {{Map}}. It's not intended to be plugged in as one.
Rather, if you need to be agnostic to whether you have a {{Map}} or a {{Put}}
and a {{Get}}, you can program to the {{Put}}/{{Get}} APIs and use any of the
{{IterableMap}} impls provided by {{\[collections\]}} to implement these as
well. By extending {{Map}} and {{Put}}, {{IterableMap}} forces the RT of
{{#put()}} to be narrowed to {{V}}.
> splitmap.TransformedMap is not really a Map
> ---
>
> Key: COLLECTIONS-461
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-461
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Sebb
> Fix For: 4.x
>
>
> splitmap.TransformedMap is part of the Get/Put hierarchy, but it does not
> behave like a proper Java Map.
> In particular, java.util.Map.put(K, V) returns V.
> However the collections Put interface returns Object.
> As far as I can tell, this was done in order to be able to include
> TransformedMap in the hiearchy. But the side effect is to break the generics
> for all the non-transformer maps in the hierarchy.
> Maybe there should be a separate PutTransformed interface which has the
> appropriate generic types, i.e.
> public T put(K key, V value)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FUNCTOR-26) functors filtering on bean properties using(== ,!=, >,>=.>.>=. isNull, Like,..... )
[
https://issues.apache.org/jira/browse/FUNCTOR-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656630#comment-13656630
]
Bruno P. Kinoshita commented on FUNCTOR-26:
---
Sounds like an useful improvement for [functor]. Perhaps we could find another
name for that; not sure if PropertyPredicate is the best name for that. As a
side note, JDK8's Predicate [1] is a functional interface with the test(A)
method and or/xor/and default methods, all of them returning a new Predicate.
Allowing similar fluent API as your patch :)
[1] http://download.java.net/jdk8/docs/api/java/util/function/Predicate.html
> functors filtering on bean properties using(== ,!=, >,>=.>.>=. isNull,
> Like,. )
> -
>
> Key: FUNCTOR-26
> URL: https://issues.apache.org/jira/browse/FUNCTOR-26
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Anil K.Kinge
>Assignee: Brent Worden
> Attachments: functors.propertypredicates.new.diff
>
>
> In my current project I created a set of new Predicates that I call as
> Property Predicates. These predicates can used to filter a collection based
> on property values.
> For example we have :
> Class Foo{
> String name;
> Int age;
> Address address;
> }
> Address{
> String street;
> String zip;
> }
> Collection myFoos ;
> And we want to find all the Foo in myFoos with name that starts with A, and
> age > 40 and who are living at Zip 07095 we can create a Predicate like
> follows:
> Predicate p = new PropertyLikePredicate("name","A*")
> .andGreaterThan("age",40)
> .andEquals(address.zip,"07095");
> Note: Like supports wildcards '*' and '?'
> What is even better is that these predicates work with collections too. What
> I mean is if we have :
> FooBar{
> String name;
> Collection addresses;
> }
> And you want to locate someone with a zip 07095 as part of anyof its'
> addresses all we need is to create a predicate :
> Predicate p = new PropertyEqualsPredicate("addresses[].zip","07095");
> My Predicate chain currently supports the following features:
> 1.andEquals
> 2.orEquals
> 3.andNotEquals
> 4.orNotEquals
> 5.andLike
> 6.orLike
> 7.andGreatorThan
> 8.orGreatorThan
> 9.andGreatorThanOrEquals
> 10. orGreatorThanOrEquals
> 11. andLessThan
> 12. orLessThan
> 13. andLessThanOrEquals
> 14. orLessThanOrEquals
> 15. isNull
> 16. isNotNull
> 17. orNull
> 18. orNotNull
> 19. orNullOrEmpty
> 20. orNotNullOrEmpty
> 21. andNullOrEmpty
> 22. andNotNullOrEmpty
> All features have accompanying testcases. In my opinion this is a powerful
> addition to the functors and I would like to contribute this work to the
> commons-collection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCS-100) JCS never going out of the dispose methode
[ https://issues.apache.org/jira/browse/JCS-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656633#comment-13656633 ] Jean-Marc Spaggiari commented on JCS-100: - Thanks Thomas. I have been able to extract to trunk and build it. I will try the application locally first, then push it on the servers and see if it's having the same issue. If so, I wlil update this ticket. > JCS never going out of the dispose methode > -- > > Key: JCS-100 > URL: https://issues.apache.org/jira/browse/JCS-100 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-1.3 > Environment: Windows >Reporter: Jean-Marc Spaggiari > > I have an application using many threads all calling JCS. When I close the > application, the cache is usually working fine, but sometime, it stays > stucked on the dispose methode. > The cacheEventQueue never going empty. Then it's looping on while ( keepGoing > ) and never ending. I have to kill the application to exit. > It's difficult to reproduce. There is no fixed pattern so far. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-893) Default value for StrSubstitutor
Lauri Siltanen created LANG-893:
---
Summary: Default value for StrSubstitutor
Key: LANG-893
URL: https://issues.apache.org/jira/browse/LANG-893
Project: Commons Lang
Issue Type: Improvement
Components: lang.text.*
Affects Versions: 2.4
Reporter: Lauri Siltanen
public static void main(String[] args) {
String s = "The number of ${item} items currently available:
${number}";
String result = StrSubstitutor.replace(s,
Collections.singletonMap("item", "monitor"));
System.out.println(result);
}
This results in: "The number of monitor items currently available: ${number}".
I'd need a default value for a placeholder that cannot be resolved.
String result = StrSubstitutor.replace(s, Collections.singletonMap("item",
"monitor"), "N/A");
-> "The number of monitor items currently available: N/A".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-893) Default value for StrSubstitutor
[
https://issues.apache.org/jira/browse/LANG-893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656703#comment-13656703
]
Lauri Siltanen commented on LANG-893:
-
Can't fix the description formatting, sorry.
> Default value for StrSubstitutor
>
>
> Key: LANG-893
> URL: https://issues.apache.org/jira/browse/LANG-893
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.text.*
>Affects Versions: 2.4
>Reporter: Lauri Siltanen
>
> public static void main(String[] args) {
> String s = "The number of ${item} items currently available:
> ${number}";
> String result = StrSubstitutor.replace(s,
> Collections.singletonMap("item", "monitor"));
> System.out.println(result);
> }
> This results in: "The number of monitor items currently available: ${number}".
> I'd need a default value for a placeholder that cannot be resolved.
> String result = StrSubstitutor.replace(s, Collections.singletonMap("item",
> "monitor"), "N/A");
> -> "The number of monitor items currently available: N/A".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-468) Change Bag interface and implementations to conform to Collection interface
[ https://issues.apache.org/jira/browse/COLLECTIONS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656832#comment-13656832 ] Thomas Neidhart commented on COLLECTIONS-468: - Another thing: we could also add a decorator which mimics the old behavior? > Change Bag interface and implementations to conform to Collection interface > --- > > Key: COLLECTIONS-468 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-468 > Project: Commons Collections > Issue Type: Bug >Reporter: Thomas Neidhart > Fix For: 4.0 > > Attachments: COLLECTIONS-468.patch > > > Several methods of the Bag interface do not conform to the Collection > interface (e.g. add, remove, containsAll, removeAll, retainAll). > This should be fixed for 4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (BCEL-163) Incorporate patch file from Findbugs?
[ https://issues.apache.org/jira/browse/BCEL-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved BCEL-163. --- Resolution: Fixed Resolving per https://issues.apache.org/jira/browse/BCEL-163?focusedCommentId=13655323&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13655323 Did you update the changes.xml file? > Incorporate patch file from Findbugs? > - > > Key: BCEL-163 > URL: https://issues.apache.org/jira/browse/BCEL-163 > Project: Commons BCEL > Issue Type: Bug > Components: Main >Affects Versions: unspecified > Environment: Operating System: Windows XP > Platform: PC >Reporter: Sebb >Assignee: Apache Commons Developers > Attachments: findbugs_bcel6.patch > > > The Findbugs project uses a patched version of BCEL. > Consider incorporating their patch (as below) into the next release of BCEL? > http://code.google.com/p/findbugs/source/browse/trunk/findbugs/src/patches/bcel.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (BCEL-163) Incorporate patch file from Findbugs?
[ https://issues.apache.org/jira/browse/BCEL-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved BCEL-163. --- Resolution: Fixed Resolving per https://issues.apache.org/jira/browse/BCEL-163?focusedCommentId=13655323&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13655323 Did you update the changes.xml file? > Incorporate patch file from Findbugs? > - > > Key: BCEL-163 > URL: https://issues.apache.org/jira/browse/BCEL-163 > Project: Commons BCEL > Issue Type: Bug > Components: Main >Affects Versions: unspecified > Environment: Operating System: Windows XP > Platform: PC >Reporter: Sebb >Assignee: Apache Commons Developers > Attachments: findbugs_bcel6.patch > > > The Findbugs project uses a patched version of BCEL. > Consider incorporating their patch (as below) into the next release of BCEL? > http://code.google.com/p/findbugs/source/browse/trunk/findbugs/src/patches/bcel.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-468) Change Bag interface and implementations to conform to Collection interface
[ https://issues.apache.org/jira/browse/COLLECTIONS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656849#comment-13656849 ] Emmanuel Bourg commented on COLLECTIONS-468: Or a decorator that mimics a real collection? > Change Bag interface and implementations to conform to Collection interface > --- > > Key: COLLECTIONS-468 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-468 > Project: Commons Collections > Issue Type: Bug >Reporter: Thomas Neidhart > Fix For: 4.0 > > Attachments: COLLECTIONS-468.patch > > > Several methods of the Bag interface do not conform to the Collection > interface (e.g. add, remove, containsAll, removeAll, retainAll). > This should be fixed for 4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-439) TreeBag with comparator does not store non-key duplicates.
[ https://issues.apache.org/jira/browse/COLLECTIONS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656862#comment-13656862 ] Claude Warren commented on COLLECTIONS-439: --- That would seem reasonable. > TreeBag with comparator does not store non-key duplicates. > -- > > Key: COLLECTIONS-439 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-439 > Project: Commons Collections > Issue Type: Improvement > Components: Bag >Affects Versions: 3.2.1 >Reporter: Claude Warren > Fix For: 4.x > > Attachments: COLLECTIONS-439.tar.gz, SortedBag.java > > > When storing objects that are sorted by a Comparator, if the differences in > the objects are not in the comparator the same version of the object is > returned. I expected that the sorted bag would work like a DB table with a > non-unique key -- ordered but duplicate only determined by Object.equals(). > I have implemented this type of bag using a TreeMap of List. My > implementation uses the Jena ExtendedIterator to make building the iterator() > and array() methods easier. > Will attach the code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
