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
raw type usage. I'm surprised that the Eclipse code hygienist failed to catch
these. Also had to be slightly more blatant in a few places where we're
subverting the generics type system because the 1.7 javac is less tolerant of
the fast and loose.
For future reference, that usually means first assigning a reference to a
wildcard and then casting that to what you want:
Foo<?> fc = someFooWithCrazyAssParameters;
@SuppressWarnings("unchecked") Foo<Object> fo = (Foo<Object>)fc;
instead of just:
@SuppressWarnings("unchecked") Foo<Object> fo =
(Foo<Object>)someFooWithCrazyAssParameters;
because javac won't let you do casts that are inconvertible and it's smarter
about what sort of generic types are convertible to one another.
Hopefully this future reference won't be needed because we won't be needing to
subvert the type system. But when reflection is involved, it's hard not to end
up doing a bit of the old Father Knows Best.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2756 6335cc39-0255-0410-8fd6-9bcaacd3b74c
karma@deadmoose.com