standard Maven layout.
I'm not a huge fan of that separation, particularly now that it's de rigueur to
ship your sources with your class files. In such circumstances, one could
imagine just copying the entire contents of src/main/java into target/classes
and being done with it. Class files, XML files, propert files, etc. are all
packaged up together into one happy jar file of goodness. Then you don't have
extra files off in src/main/resources being demure and hard to notice.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2849 6335cc39-0255-0410-8fd6-9bcaacd3b74c
our tests pass even when we haven't run them before. We were relying on
sub.sub3 having been set and persisted from a previous test invocation.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2848 6335cc39-0255-0410-8fd6-9bcaacd3b74c
to put your source and test source code for Java projects. I'm going to toe the
line here because I want to use SBT to publish samskivert to the centralized
Maven repositories.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2807 6335cc39-0255-0410-8fd6-9bcaacd3b74c
room to spare, per the spec.
- Document that we do not support null elements.
- Increment modCount in our modifying methods, to take advantage of
fail-fast iterators.
- A few small comments.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2805 6335cc39-0255-0410-8fd6-9bcaacd3b74c
the memory benefits of ArrayIntSet and better performance than a
HashSet<Integer> (presumably because of less boxing and better spatial
locality). The downside is that you need to pick a sentinel value that can't
be stored in the set, but that's not a problem in any application for which
I've ever used an IntSet. In some (admittedly simplistic) Google Caliper
testing, HashIntSet was 22% faster than ArrayIntSet and 73% faster than
HashSet for arrays of size N=10, 100% faster than ArrayIntSet and 69% faster
than HashSet for N=100, and 357% faster than ArrayIntSet and 74% faster than
HashSet for N=1000.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2801 6335cc39-0255-0410-8fd6-9bcaacd3b74c
I haven't deprecated our version in CollectionUtil because it
copes with being passed a null array...
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2799 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Our getOr() will skip the first argument if it is "blank"
(null, empty, or all whitespace), not just null.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2783 6335cc39-0255-0410-8fd6-9bcaacd3b74c
lose precision during the cast. Now it will freak out if the
"byte" is out of range.
- A bit less hashing in our static initializer.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2782 6335cc39-0255-0410-8fd6-9bcaacd3b74c
(Although, the implementation builds a Pattern object, which
seems rather wasteful if the match sequence isn't found..)
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2781 6335cc39-0255-0410-8fd6-9bcaacd3b74c
- If there is only one element in the Iterable, compare it to itself to
make sure it's not "bogus", like null in the Comparable version.
- Use our own natural ordering Comparator, as the one in Comparators is null-safe. Gah!
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2773 6335cc39-0255-0410-8fd6-9bcaacd3b74c
show up on HashIntMap when I added it to IntMap. Not so. Apparently it only works
for superclasses, no implemented interfaces, and it may also not apply to
non-runtime annotations.
So: add @ReplacedBy to these IntMap-related classes.
I've not yet used @ReplacedBy on IntSet, and I guess some people still
really like their ArrayIntSet, but the memory gain is minimal and it's actually
usually a loss in terms of performance.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2769 6335cc39-0255-0410-8fd6-9bcaacd3b74c
samskivert