our tests pass even when we haven't run them before. We were relying on
sub.sub3 having been set and persisted from a previous test invocation.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2848 6335cc39-0255-0410-8fd6-9bcaacd3b74c
to put your source and test source code for Java projects. I'm going to toe the
line here because I want to use SBT to publish samskivert to the centralized
Maven repositories.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2807 6335cc39-0255-0410-8fd6-9bcaacd3b74c
room to spare, per the spec.
- Document that we do not support null elements.
- Increment modCount in our modifying methods, to take advantage of
fail-fast iterators.
- A few small comments.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2805 6335cc39-0255-0410-8fd6-9bcaacd3b74c
the memory benefits of ArrayIntSet and better performance than a
HashSet<Integer> (presumably because of less boxing and better spatial
locality). The downside is that you need to pick a sentinel value that can't
be stored in the set, but that's not a problem in any application for which
I've ever used an IntSet. In some (admittedly simplistic) Google Caliper
testing, HashIntSet was 22% faster than ArrayIntSet and 73% faster than
HashSet for arrays of size N=10, 100% faster than ArrayIntSet and 69% faster
than HashSet for N=100, and 357% faster than ArrayIntSet and 74% faster than
HashSet for N=1000.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2801 6335cc39-0255-0410-8fd6-9bcaacd3b74c
I haven't deprecated our version in CollectionUtil because it
copes with being passed a null array...
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2799 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Our getOr() will skip the first argument if it is "blank"
(null, empty, or all whitespace), not just null.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2783 6335cc39-0255-0410-8fd6-9bcaacd3b74c
lose precision during the cast. Now it will freak out if the
"byte" is out of range.
- A bit less hashing in our static initializer.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2782 6335cc39-0255-0410-8fd6-9bcaacd3b74c
(Although, the implementation builds a Pattern object, which
seems rather wasteful if the match sequence isn't found..)
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2781 6335cc39-0255-0410-8fd6-9bcaacd3b74c
- If there is only one element in the Iterable, compare it to itself to
make sure it's not "bogus", like null in the Comparable version.
- Use our own natural ordering Comparator, as the one in Comparators is null-safe. Gah!
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2773 6335cc39-0255-0410-8fd6-9bcaacd3b74c
show up on HashIntMap when I added it to IntMap. Not so. Apparently it only works
for superclasses, no implemented interfaces, and it may also not apply to
non-runtime annotations.
So: add @ReplacedBy to these IntMap-related classes.
I've not yet used @ReplacedBy on IntSet, and I guess some people still
really like their ArrayIntSet, but the memory gain is minimal and it's actually
usually a loss in terms of performance.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2769 6335cc39-0255-0410-8fd6-9bcaacd3b74c
samskivert