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
a while back. Let's have the Ant-based build do the same. We can also get rid
of samskivert-gwt, since it hasn't been necessary for some time.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2987 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
doesn't just indicate leniency in the face of conflict. Jesus fucking christ.
Anyhow, we can't cope with velocity-1.7.1-beta, so we have to provide a "soft"
recommendation for velocity-1.6.4.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2967 6335cc39-0255-0410-8fd6-9bcaacd3b74c
dependencies. This will ensure that Maven does not erroneously omit a newer
dependency of some other library because we happen to specify an older version.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2966 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
our tests when building samskivert with 1.5 because they depend on hsqldb which
is a 1.6 jar file. The main code base still compiles with a 1.5 compiler, so
there's no need for alarm.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2954 6335cc39-0255-0410-8fd6-9bcaacd3b74c
repository to be specified anyway. If you want to install to your local
repository, we should be using :install rather than :deploy.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2953 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Deadmoose