every intention to move Factory, Closure, Predicate and Transformer to
another lower-level project, possibly [lang] or [pattern]. Currently
they live in [pattern], and the Util classes in that project are far
superior to these.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130779 13f79535-47bb-0310-9956-ffa450edef68
Deprecated all iterator classes in the main package released in 2.0.
Removed all iterator classes from the main package that were not
released yet.
Moved test code for iterators into new iterators subpackage.
Deleted old iterator test code in the main package.
Modified main package TestAll to invoke iterators subpackage TestAll.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130777 13f79535-47bb-0310-9956-ffa450edef68
now backed by the parent collection, even in fast mode, and those
classes now pass all unit tests in fast mode. The unit tests were
altered so that they actually test the classes with setFast(true).
PR:7924
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130771 13f79535-47bb-0310-9956-ffa450edef68
conventions outlined in the developer's guide.
Decorators are package-protected inner classes, not part of the public
API. Existing lazy and predicated decorators were moved to
CollectionUtils, ListUtils etc. New classes SetUtils, BagUtils were
added for decorators of those types.
New bounded and fixed size decorators were added for appropriate types.
Unmodifiable and synchronized decorators were added for Buffers and
Bags.
Unit tests were added where possible. No unit tests for synchronized
collection wrappers; not sure how to implement a valid test for proper
synchronization.
Also, no unit tests for Bag decorators, because the decorator unit tests
require the TestCollection framework, which won't work with Bag since it
violates the Collection contract.
Modified Files:
src/java/org/apache/commons/collections/BufferUtils.java
src/java/org/apache/commons/collections/CollectionUtils.java
src/java/org/apache/commons/collections/ListUtils.java
src/java/org/apache/commons/collections/MapUtils.java
src/java/org/apache/commons/collections/PredicateUtils.java
src/test/org/apache/commons/collections/TestAll.java
src/test/org/apache/commons/collections/TestCollectionUtils.java
src/test/org/apache/commons/collections/TestList.java
Added Files:
src/java/org/apache/commons/collections/BagUtils.java
src/java/org/apache/commons/collections/SetUtils.java
src/test/org/apache/commons/collections/TestBoundedCollection.java
src/test/org/apache/commons/collections/TestBufferUtils.java
src/test/org/apache/commons/collections/TestListUtils.java
src/test/org/apache/commons/collections/TestMapUtils.java
src/test/org/apache/commons/collections/TestPredicatedCollection.java
src/test/org/apache/commons/collections/TestSetUtils.java
Removed Files:
src/java/org/apache/commons/collections/LazyCollections.java
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130765 13f79535-47bb-0310-9956-ffa450edef68
BoundedFifoBuffer is renamed from Avalon's FixedSizeBuffer. Made it extend
AbstractCollection, provided an iterator. Removed "final" from class and method
declarations. Added javadoc.
UnboundedFifoBuffer is renamed from Avalon's VariableSizeBuffer. Made it extend
AbstractCollection, provided an iterator. Removed "final" from class and method
delcarations. Added javadoc.
BufferUtils provides Buffer decorators for synchronized, unmodifiable, and
predicated Buffers.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130740 13f79535-47bb-0310-9956-ffa450edef68
Modified the interface from Avalon so that it (a) defines a read-only get()
method and (b) extends java.util.Collection. Also altered the documentation so
that the scope of the interface is broader; it can apply to stacks, heaps and
LRU caches as well.
Submitted by: Paul Jack ( pjack at sfaf dot org )
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130738 13f79535-47bb-0310-9956-ffa450edef68
following changes to the Avalon implementation:
Changed improper short form of license to the approved long form.
Changed package from org.apache.avalon.excaliber.collections to
org.apache.commons.collections.
Altered to allow null keys and null values.
Fixed the values() method to return all values from the map. That is, when a
particular value is mapped to from two different keys, it should be included
twice in the values() collection; however the avalon implementation was using a
Set (thus not including duplicates). The new implementation uses a list which
does not restrict duplicate elements.
Fixed the put(Object,Object) method to return null rather than the value being
put into the map when the key does not already exist in the map (per the Map
contract).
Added equals(Object) and hashCode() implementations to conform to the Map
contract.
Altered the Node inner class's hashCode() method to return the hashCode of the
Map.Entry as defined in the Map.Entry's contract.
Added an equals(Object) method to the Node inner class to conform to the
Map.Entry contract.
Things left todo:
Alter the keySet(), values(), and entrySet() methods to return collections that
are backed by the map per the Map contract.
Add a constructor that takes another Map and adds all the mappings from that
map (per the Map recommendation).
Implement a DynamicBucketMap that will allow for dynamic resizing of the
hashtable's structure such that the map will not suffer a performance penalty
when the number of elements in the map exceeds the number of buckets in the
map.
Improve the documentation to indicate the performance problems when specifying
a size that is smaller than the expected number of elements.
Other general documentation cleanup
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130736 13f79535-47bb-0310-9956-ffa450edef68
so the full suite of List tests is performed on them.
Used BulkTest.makeSuite to pick up the sublist tests.
There should probably be additional work for testing the
primitive operations.
Submitted by: Paul Jack ( pjack at sfaf dot org )
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130735 13f79535-47bb-0310-9956-ffa450edef68
essentially making it an unmodifiable List. Since setFloat(int,float)
and removeFloatAt(int) already existed, I added trivial
implementations for set(int,Object) and remove(int).
Submitted by: Paul Jack ( pjack at sfaf dot org )
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130734 13f79535-47bb-0310-9956-ffa450edef68
TestCollection patterns. A bulk test has been included for
sublists and sub-sublists.
Removed the deprecated method from TestCollection, as no one uses
it anymore.
Modified TestCursorableLinkedList so that serialization tests on
sublists and sub-sublists are ignored.
Submitted by: Paul Jack ( pjack at sfaf dot org )
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130731 13f79535-47bb-0310-9956-ffa450edef68
raising a NullPointerException if null were passed as the argument.
This patch file fixes the behavior so that these methods will
correctly find a null element.
Submitted by: Paul Jack ( pjack at sfaf dot org )
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130730 13f79535-47bb-0310-9956-ffa450edef68
- TestBeanMap
- TestCursorableLinkedList
- TestDoubleOrderedMap
- TestFastHashMap
- TestFastHashMap1
- TestFastTreeMap
- TestFastTreeMap1
- TestLRUMap
- TestSequencedHashMap
- TestSoftRefHashMap
Submitted by Paul Jack ( pjack at sfaf dot org ).
Note: TestAll does not contain reference to TestSoftRefHashMap, so this test is
not automatically run. If you run it manually, you will see many failures that
are due to bug 9571.
Note: With this commit, there are four test failures if you are running with
JDK 1.2. This is due to a bug in the JDK's implementation of keySet on a
HashMap which incorrectly returns false after removing a mapping which maps a
key to a null value. Incidently, this problem is very similar to the problem
that existed on SequencedHashMap, filed as bug 9719, and fixed on June 9th.
See: http://developer.java.sun.com/developer/bugParade/bugs/4286765.html
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130727 13f79535-47bb-0310-9956-ffa450edef68
along with resetEmpty() and resetFull(). This allows for more calls to verify
to ensure that calls to methods that should not modify a collection don't
actually modify it.
Split the verify() method into four separate verification methods. This way,
if a Map implementation needs to change the way verification is performed for
just one of the collection views, they only need to override one method and
won't need to reimplement all the other verifications.
Override TestMultiHashMap's verifyValues() method to retrieve a fresh copy of
the values collection before verification. This ensures some verification
testing on the values, even though the values is not backed by the map (bug
9573)
Override a few more test methods and the verifyyMap and verifyEntrySet methods
for TestMultiHashMap since it's values are collections rather than the expected
objects. These will need to be filled in with better implementations to
actually test the MultiMap contact.
Removed the SupportsPut marker interface.
Removed some duplicate tests (i.e. some old tests that weren't written with the
current framework in mind and just duplicate the tests that have been added).
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130726 13f79535-47bb-0310-9956-ffa450edef68
Submitted by: Paul Jack ( pjack at sfaf dot org ).
Needed to change Paul's implementation slightly to get things compile properly
using JDK 1.2. The 1.2 compiler thought that the "confirmed" field was
ambiguous in the anonymous inner class and thus needed to be qualified with a
ClassName.this. In order to do that, the anonymous inner classes needed to be
made named inner classes.
This change exposes one test failure for MultiHashMap that appears to be caused
by its values() method not being backed by the map (bug 9573).
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130725 13f79535-47bb-0310-9956-ffa450edef68
should use makeEmptySet and makeFullSet rather than their collection
counterparts.
Added getSet() and getConfirmedSet() methods which wrap the collection and
confirmed fixtures so that tests don't need to perform the cast to a Set.
Modified tests that used makeEmptySet and makeFullSet to use the fixture
getSet() along with resetEmpty() and resetFull(). This allows for more calls
to verify() to ensure that calls to methods that should not modify a
collection don't actually modify it.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130724 13f79535-47bb-0310-9956-ffa450edef68
complete Set contract. This will be used to test Set implementations and set
views of other collections (e.g. Map.entrySet() and Map.keySet()).
Submitted by: Paul Jack ( pjack at sfaf dot org ).
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130723 13f79535-47bb-0310-9956-ffa450edef68
Removed commented out tests for equals and hashCode (the collection contract
does not specify a specific contract on equals and hashCode), and added a
comment at the top of the class so that no one comes in later and re-adds the
test cases.
Removed dependence on HashBag. If HashBag has a bug, this may adversly affect
the tests that are using it. Reimplemented without using HashBag.
Modified tests that used makeFullCollection and makeCollection to use the
fixture field "collection" along with resetEmpty() and resetFull(). This
allowed for more calls to verify to ensure that calls to methods that should
not modify a collection don't actually modify it.
When removing using the iterator, an equivalent operation cannot really be
performed on the confirmed collection for verification. After some
investigation, changed the existing tests (tested for instances of Set, List
and Bag) to one that is a bit more generic: A new flag (that test subclasses
can override) which specifies whether the elements in the collection are
distinguishable from each other (and such that it might matter which element is
actually removed from the collection when the iterator's remove method is
called).
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130722 13f79535-47bb-0310-9956-ffa450edef68
will be used to test straight Collection implementations and for collection
views of other collections (e.g. Map.values()).
Submitted by: Paul Jack ( pjack at sfaf dot org ).
Changed TestBag to extend from TestObject instead of TestCollection since the
Bag contract conflicts with the Collection contract. This needs to be
addressed at some point.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130721 13f79535-47bb-0310-9956-ffa450edef68
testing collections, maps, etc., can be reused to test collections, maps,
etc. that are returned from other collections. For example, the Map interface
defines entrySet() which is supposed to return a valid Set. The framework
added here would allow the Set testing code to be used for testing Sets and the
set returned from Map's entrySet() method.
Submitted by: Paul Jack < pjack at sfaf dot org >
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130720 13f79535-47bb-0310-9956-ffa450edef68
This can help avoid folks having to use the o.a*.c*.collections.comparators package, providing nice simple static helper method instead along the same lines as java.util.Collections and CollectionUtils here.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130714 13f79535-47bb-0310-9956-ffa450edef68
when one didn't exist before. That is, if containsKey(foo) returns
false, then get(foo) will not change that.
Added serial version UID to maintain backwards compatibility. The auto
generated serialization UID differs from the released version because
of the addition of a new method.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130699 13f79535-47bb-0310-9956-ffa450edef68
"default map based implementation" and differs in design from the
AbstractSet, AbstractMap classes which do not make assumptions about
how they might be implemented. To be consistent with JDK AbstractX
collections, an AbstractBag class should just be providing default
implementations that could be used regardless of underlying storage
mechanism. For example, the add(Object) method would call the abstract
add(Object,int) method passing the object and 1. Since this
implementation assumes a Map based storage for the Bag, it does not
follow the AbstractX pattern, and thus has been renamed. There is
still room for future addition of an AbstractBag that does not assume
a storage data structure.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130675 13f79535-47bb-0310-9956-ffa450edef68
in line with the Map contract where any modifications will throw
UnsupportedOperationException rather than allow modifications that are not
reflected in the underlying map. This also keeps values(), keySet() and
entrySet() consistent with each other.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130673 13f79535-47bb-0310-9956-ffa450edef68
implement Comparable. BinaryHeap implements this by accepting an
optional Comparator in its constructor. If no comparator is specified,
the object's natural ordering is used (i.e. it is cast to a Comparable
and compared using its compareTo method)
Also added basic tests for BinaryHeap
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130661 13f79535-47bb-0310-9956-ffa450edef68
Fixed entrySet() to return a set containing Map.Entry objects with readable
properties as keys. This fixes the test case error, and a couple of the test
case failures (and uncovers a couple more test case failures)
Fixed clone method to allow subclasses to clone properly. This requires a
non-backwards compatible change where the clone method now declares it throws
CloneNotSupportedException. See:
http://www.javaworld.com/javaworld/jw-01-1999/jw-01-object.html Seeing how
BeanMap never directly implemented Cloneable anyway, and this is for a major
revision, I don't see this changing being much of a problem.
Since clone() declares it throws CloneNotSupportedException, that exception is
now used to indicate a problem when attempting to clone (rather than
UnsupportedOperationException, or other RuntimeException).
Added a small test for testing BeanMap clone.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130638 13f79535-47bb-0310-9956-ffa450edef68
- In Bag.java, the statement "If the bag contains less than i occurences,
the item item will be removed from the unique set" implies that if the bag
contains 5 occurences and i is 5, (5 is not less than 5) then the item will
not be removed from the unique set, even though there should be no more
occurances in the bag.
- In AbstractBag.java, the documentation does not specify exactly what a
subcless needs to do to extend AbstractBag to make a concrete subclass.
- AbstractBag.add(Object,int) has two calls to getCount(o), when only one
is necessary. This wastes a few cycles to perform method invocations, a
map lookup, a cast, and a few comparisons.
- The AbstractBag.equals(Object) method will incorrectly throw a
NullPointerException if a null value is passed. The Object.equals(Object)
API specifies "For any non-null reference value x, x.equals(null) should
return false".
- The AbstractBag.equals(Object) method will only work if the object
passed in extends AbstractMap or implements Map. Neither of these facts
is documented, and neither is correct. The contract for
Object.equals(Object) states: "for any reference values x and y,
x.equals(y) should return true if and only if y.equals(x) returns true. ".
Returning true when the argument is a Map is incorrect since he reverse
(the map checking to see if its equal to the bag) will most certainly be
false. The same can be said for AbstractMap. A subclass of AbstractMap
may add extra data to be stored within the Bag that must also be compared
for them to be equal. The reverse comparison (specialized subclass equals
basic abstract bap) will fail. You can read more about this in a three-
year old, but still valid java world article:
http://www.javaworld.com/javaworld/jw-01-1999/jw-01-object.html
- if AbstractBag.remove(Object,int) is called passing in 0 as the number
to remove and specifying an object that exists in the bag, true will be
returned from the method. Per the Bag API specification, true should only
return when an object is actually removed. Since no objects are removed,
false should be returned instead. Additionally, if a negative number is
specified, not only is the object not removed, but object(s) are *added*
(well, in the sense that it is equivalent of calling add(o, -i))
- the uniqueSet() method returns the set of unique objects, however the
set is modifiable. If the underlying map implementation has the set
backed by the map (as per the map contract -- so it should), then elements
can be removed from the unique set and have them removed from the
underlying map as well. This causes consistency problems with the Bag
since _total will then be incorrect.
- in extractList(), getCount(current) is called each time through the
inner loop, adding lots of extra overhead. Reversing the loop (starting
at the count and going down to 0) eliminates the excess overhead.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130557 13f79535-47bb-0310-9956-ffa450edef68
cooresponding changes to other tests. These tests expose a few deviations from
the Map contract in BeanMap. These should either be fixed, or BeanMap should be
documented to describe how it differs from the Map contract.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130552 13f79535-47bb-0310-9956-ffa450edef68
it when the unit test source is 50% longer than the class being tested :-).
The only change I made was to use the long-form version of the Apache
license -- according to the Apache board, that is the only acceptable
approach at the moment. Any remaining classes in commons-collections (or
elsewhere) using the short form license should be updated.
Submitted by: Marc Johnson <marc_johnson27591@hotmail.com>
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130509 13f79535-47bb-0310-9956-ffa450edef68
called in the standard way. ie)
(cf: "Juozas Baliuka" <baliuka@mwm.lt>)
while(true) {
filterIterator.next();
}
This should eventually throw NoSuchElementException, but it returns null
forever.
Submitted by: Jan Sorensen <jan.sorensen@aragost.com>
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130505 13f79535-47bb-0310-9956-ffa450edef68
where ExtendedProperties would re-process data when making a subset. Hope no one
was depending on that :)
Also adjusted the testcase to test this.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130474 13f79535-47bb-0310-9956-ffa450edef68
1) replaced with the current version from velocity's CVS - this is a few
changes by dan
2) added the recent patch from Ilkka for dealing with encoded properties
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130456 13f79535-47bb-0310-9956-ffa450edef68
TreeMap). These help validate the tests themselves (by proving that they
operate as expected against the standard Java APIs), and serve as
convenient base classes for testing the "fast" variants.
Make TestArrayStack extend TestArrayList so that all standard ArrayList
contracts are tested.
Test FastArrayList, FastHashMap, and FastTreeMap in both "slow" mode and
"fast" mode.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130445 13f79535-47bb-0310-9956-ffa450edef68
HashMap, and TreeMap respectively. This improves the ability to
substitute "fast" versions for the use of the regular collection classes.
Implement clone(), equals(), and hashCode() methods in accordance with the
contracts specified in the Collections classes APIs.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk@130444 13f79535-47bb-0310-9956-ffa450edef68