Oh baby, look at the @SuppressWarnings and cast removal.
It's all itchy, flakey, and pale under the cast!
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2695 6335cc39-0255-0410-8fd6-9bcaacd3b74c
(RangeIntSet, CompleteIntSet & ClumpyArrayIntSet (which both are capable
of holding every int, and not maxing out at Integer.MAX_VALUE size)).
But here's a bunch of useful stuff all wrapped up nicely.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2690 6335cc39-0255-0410-8fd6-9bcaacd3b74c
- Don't wig-out trying to grow from a size larger
than half of Integer.MAX_VALUE.
- Don't try to add any values once size reaches Integer.MAX_VALUE.
- Fixed the Interator's remove() to behave properly should it be
called improperly.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2679 6335cc39-0255-0410-8fd6-9bcaacd3b74c
The RunBuddy posted to a RunQueue will call its Interval's
toString() method. If an Interval is created with a Runnable,
let's call the Runnable's toString().
We could also add a form of create() that takes a String for the name...
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2676 6335cc39-0255-0410-8fd6-9bcaacd3b74c
the Executor interface.
- Also accept our "receiver" as an Executor, deprecating the old RunQueue
constructor.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2671 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Provide a method for getting a Comparable Comparator in a typesafe way.
I had to change the Comparator to be untyped.
Hopefully this doesn't hork anything. Oh, now I worry...
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2664 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Is this weird? Maybe. It violates the requirment that the Comparable relation
is transitive, because the "other" object need not even be Comparable.
java.util.Arrays.binarySearch() (added in 1.6) is documented as if it
supports this behavior, but it does not.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2661 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Wrap it in an AssertionError.
I looked to Java sources to see what the best practice was:
Sometimes it's ignored, sometimes an InternalError is thrown,
sometimes an AssertionError without the "cause", but sometimes
this pattern, which is clearly the best of those.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2660 6335cc39-0255-0410-8fd6-9bcaacd3b74c
does not permit null (or, obviously, elements of the wrong type),
but is gracious about simply returning false if an invalid
Object is passed to contains() or remove().
- Implement a dumb size().
- toIntArray() impl now deals with oversize IntSets.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2657 6335cc39-0255-0410-8fd6-9bcaacd3b74c
but that's like half the point of the containsKey() method!
- check for shrinkage when values are removed from the keySet, but avoid
doing iteration-breaking shrinking modifications when remove() is called
on any of our iterators.
- Slight performance improvement on keySet.remove().
- Other simplifications.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2655 6335cc39-0255-0410-8fd6-9bcaacd3b74c
- 1.5 compatibility: Removed @Override on some methods that
had no concrete implementation in superclasses.
- Added @Override to a few places where there does happen to
be an implementation in our abstract superclass.
I now think the 1.6 behavior of @Override is more sensible, it's
less special-casey.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2653 6335cc39-0255-0410-8fd6-9bcaacd3b74c
WARNING: behavior change! May cause runtime errors!
- Previously these methods would always return an Integer[], which is
incorrect. The toArray() version should always return an Object[],
and the toArray(T[] a) version should return an array of the same
type as that passed in, even if a supertype of T (like Object[]).
- The toArray(T[] a) version was not doing any size checking, nor
doing any of the required steps if the size doesn't match.
This change may break something, but it brings this class into
compliance with the Collection interface.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2652 6335cc39-0255-0410-8fd6-9bcaacd3b74c
the specified object is not an Integer. We're allowed to do that
per the Collection interface spec, and ArrayIntSet previously had
that behavior (but the IntMap keySets did not...).
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2651 6335cc39-0255-0410-8fd6-9bcaacd3b74c
- Fully filled-out AbstractIntSet with default implementations of most
things and documented the two methods that must be provided (interator()
and size()) as well as the ones that should probably be overridden for
performance or to make one mutable.
- Fixed implementations of contains(Object o) and remove(Object o) to not NPE.
- Return hashCode() identically to the way Set<Integer> would.
- Created an AbstractInterator.
- Added notes where I believe an implementation is bogus...
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2649 6335cc39-0255-0410-8fd6-9bcaacd3b74c
binary compatibilty! Whee!
I genericized these when I was first using generics, before I understood the
"PECS" rule.
It seems to me that these could be
<T> Collection<T> addAll (Collection<T> col, Iterator<? extends T> iter);
(rather than)
<T> Collection<? super T> addAll (Collection<? super T> col, Iterator<T> iter);
..but in fact there is already a java.util.Collections.addAll() that takes
an array and specifies the type as that of the producer.
So I followed that. I'm not sure which would be more correct.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2646 6335cc39-0255-0410-8fd6-9bcaacd3b74c
ray.j.greenwell