- 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
I'm rolling back the fluency addition. It's not sufficiently useful to merit
the breakage, especially since you can do (_foo = new Interval()).schedule() to
achieve much the same effect. Boo for backwards binary compatibility.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2641 6335cc39-0255-0410-8fd6-9bcaacd3b74c
But I haven't done it yet.
And I've learned recently that since we're not synchronizing
we're not guaranteeing that each thread is seeing the latest result.
But these all seem to work for us.
So I'll commit this now, from Charlie Groves, and we can
fiddle in the future.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2627 6335cc39-0255-0410-8fd6-9bcaacd3b74c
etc. from a midnighted calendar.
Also added at(year, month, day) to the builder so that you can do:
Calendars.in(zone).at(2009, Calendar.JANUARY, 1)
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2624 6335cc39-0255-0410-8fd6-9bcaacd3b74c
instances configured to the desired year month and day. Also added the
requisite warning about using the Calendar month constants to the appropriate
at() method.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2622 6335cc39-0255-0410-8fd6-9bcaacd3b74c
We may add some other at()s, and probably remove all the set*() methods, because
they are not that useful and ambiguous w/r/t HOUR vs. HOUR_OF_DAY, etc.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2621 6335cc39-0255-0410-8fd6-9bcaacd3b74c
better than using java.util.Calendar directly. Also moved CalendarUtil methods
into Calendars and deprecated the lot of them.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2620 6335cc39-0255-0410-8fd6-9bcaacd3b74c
ray.j.greenwell