Per the wailing and gnashing of teeth in response to 7e51d4c and 7bb7ee2,
I'll do the extra legwork to keep my bits in a List despite java handing
them to me as an array.
In AuditLogger, we roll over the audit log on the Interval timer thread, which
is dubious, because it could block, but introducing an Invoker thread here
would require a ticket on a boat that sailed a long time ago. In the case of
SerialExecutor, we're just doing Thread.kill() on the Interval timer thread, so
that's fast enough.
If no runqueue is supplied on which to prune sessions, we don't schedule a
session pruner, rather than scheduling a long running database action on the
Interval timer thread, thereby booching all other Intervals.
run on the interval timer thread, rather than allowing that to be the default
behavior if they forget to supply a RunQueue to the constructor.
Running on the interval timer thread is only safe if you know your interval
will complete very quickly, because you'll delay the firing of all other
intervals until your interval finishes. This is almost never what you want.
- Fixed wacky use of short index variable in toString's short[] handling.
- Ensured that custom separator and whether or not we're traversing collections
is properly passed to recursive calls.
automatically traverse collections, but instead simply call toString on them.
The versions that take box arguments (where the developer is clearly expressing
a desire for custom formatted collections) still do the traversal. Moved the
warning that Enumeration and Iterator are consumed into said methods.
Switched LogBuilder to use StringUtil.toString, since it now subsumes the
behavior of ArrayUtil.toString without the undesirable collection munging that
motivated its original creation.
Nixed ArrayUtil.toString/safeToString because they haven't been in the wild
long enough to be likely to have been discovered and used by third parties.
- ObserverList shouldn't extend ArrayList; bad mojo.
- Policies should be an enum.
- Use CopyOnWriteArrayList instead of our hand-rolled snapshotting.
MDB addends:
- ObserverList should be an interface (turned out to be easier to make it an
abstract class).
- WeakObserverList should be simpler, and turns out to be so, once we simplify
ObserverList public interface and remove ArraListness.
This should all be source compatible with previous usage (modulo deprecation of
the ObserverList notification constants, which most code is probably not using,
since the nice factory methods are much more concise).
cancellation. It's tempting to store the string representation as
well when the reference is cleared, but that could be anything, so
avoid the expense.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2992 6335cc39-0255-0410-8fd6-9bcaacd3b74c
There are actually 5 different implementations of quicksort in here when
one will do (the array versions could go away and call the list version,
wrapping in Arrays.asList()). But I won't touch those right now. I am
super tempted to reduce things down to one List version and one array
version.
Also it's weird that there are customized Comparators that are null-safe.
I believe I was the one who added them in the past, but I've since learned.
It's a strange undocumented "convenience" when it's easy enough for someone
to provide a null-safe comparator for comparables. (In guava you can call
Ordering.natural().nullsLast()).
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2988 6335cc39-0255-0410-8fd6-9bcaacd3b74c
If Java were invented today, you can be damn sure the array classes
would have reasonable hashCode(), equals(), and toString() implementations,
instead of falling back to Object's.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2969 6335cc39-0255-0410-8fd6-9bcaacd3b74c
It's not that it didn't exist, it just used to be on Frame. So when
I did all my 1.5 testing, I was working with a JFrame, and then at the
11th hour decided to make this function take as general a thing as
possible, so I merrily climbed up the tree in 1.6 & didn't notice that
change.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2965 6335cc39-0255-0410-8fd6-9bcaacd3b74c
As the comments say, it tries to use the nicer stuff that was added in
1.6, but falls back as needed.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2963 6335cc39-0255-0410-8fd6-9bcaacd3b74c
I'm open to suggestions as to whether this is the right thing.
I think if it were returning a view, we'd definitely want it like this.
You don't want a List<Integer> to look like a List<Number> and have
it break something when someone stuffs a Float in it.
But the argument could be made that returning a new List can surely be
seen as a List<Number> because it is not referenced anywhere else as
something more specific. Many of the guava methods allow a "re-typing"
like this, although I think they have admitted that it was a mistake and
newly added methods don't allow it.
In any case, I think that it's most proper to retain things as specifically
as possible. Why would you turn a List<Integer> into a List<Number>?
Why would you want to throw away the information? If you need to pass it
to a method that expects List<Number> then that method should be modified
to correctly accept List<? extends Number>.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2958 6335cc39-0255-0410-8fd6-9bcaacd3b74c
David Hoover