implementations are noted in the docs as not thread safe). I specifically
verified that parse() mutates internal fields.
Since ParameterUtil is *designed* to be called by servlets which naturally run
on multiple threads, we need to be careful here to avoid getting bogus results.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2730 6335cc39-0255-0410-8fd6-9bcaacd3b74c
unprivileged code calls into privileged code, the security manager "does the
right thing" (I'd explain this better if I understood it better).
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2724 6335cc39-0255-0410-8fd6-9bcaacd3b74c
into a collection that keeps things sorted. Doing so without implementing
hashCode() and equals() is a recipe for breakage. Instead we'll just define a
comparator that does the one sorting we need, and use that, rather than give
the wrong impression.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2719 6335cc39-0255-0410-8fd6-9bcaacd3b74c
I am starting to prefer things in the guava library when there are
equivalents. I've been wondering what we want to do about informing
people about the changes. Something more interesting will happen,
because I want a place to put useful bits of code built atop guava,
and that's not samskivert, at least not now.
So anyway, here's a lighter-weight @Deprecated sorta annotation.
It can be used to indicate methods that have a replacement in guava
(or new stuff in the standard java libraries). It will show up
in the javadocs. Let's see how it looks.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2708 6335cc39-0255-0410-8fd6-9bcaacd3b74c
check this in anyway, at least for posterity.
The advantages over the 'CountingMap' (currently in yohoho):
- Faster, because adding to a count doesn't add to a boxed int, nor does
it hash twice (except on the intial use of a particular key).
The disadvantages:
- More complicated implementation (CountingMap builds upon google
collections)
- If a non-HashMap is desired, the fact that the underlying map is
<K, int[]> is exposed.
- When iterating over the entrySet, each entry is a new object
created solely for your iteration.
So.. yeah. I'll check it in. Maybe I'll blow it away. We should
probably think about how samskivert will move forward- do we want to
depend on google-collect or guava? Do we want to deprecate huge
swaths of this library in preference to those? A lot of what's
in here is a bit outdated, but maintained to support code built
atop it.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2704 6335cc39-0255-0410-8fd6-9bcaacd3b74c
- Provide an implementation in AbstractIntSet that checks the interator
for at least one element.
- Override that in ArrayIntSet so that we're just checking our size again.
- Added optimized isEmpty()s for a few of the inner classes in IntSets.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2701 6335cc39-0255-0410-8fd6-9bcaacd3b74c
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
samskivert