into the starter collection using addAll. Certain Collections, like
guava's Multiset have optimized addAll() methods that recognize
other Multisets.
There is also a putAll() equivalent for Maps.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2891 6335cc39-0255-0410-8fd6-9bcaacd3b74c
And SVN is being super pokey so I'm swimming against molasses and
that wasn't showing yet. Argh.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2889 6335cc39-0255-0410-8fd6-9bcaacd3b74c
If someone wants to use StringUtil.toString(), let them get
the openBox/closeBox/separators they were expected.
Gee, I hope r2885 didn't beak any Log parsing code...
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2886 6335cc39-0255-0410-8fd6-9bcaacd3b74c
This is an incomplete fix and brings up a larger issue that I'll explain
below. Also, this breaks the customization of openBox/closeBox/separator
Strings.
First off, I know of no Collection that doesn't have a decent toString()
implementation. The java.util.Abstract* classes all do something
reasonable and most Collections are built from those.
Guava's Multiset has a defined way of representing itself as a String.
An example would be "[value1, value2 x 100]". This fix is mainly
addressed at fixing that, as this class would do the very dumb thing
if provided with a Multiset.
Do we really customize the openBox/closeBox/separator values? Should we?
The second issue comes from the way Log uses StringUtil to evaluate
the var-args it is passed. Check out the following code.
Iterator<Thing> it = Iterables.concat(_staticThings, newThings).iterator();
log.debug("About to iterate", "user", user, "request", req, "iterator", it);
while (it.hasNext()) {
...
If the logging level is above debug, this works fine. However if one day
you lower your logging level, the message will be logged and the Iterator
will be passed to String.toString(), which will suck all the elements out of it.
That's a problem.
Actually, perhaps the right thing to do is simply to change the Log class
to avoid using this, and instead just call String.valueOf() on all objects
except arrays, which can instead be String'd with the methods added to
java.util.Arrays in 1.5.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2884 6335cc39-0255-0410-8fd6-9bcaacd3b74c
line count of the build.xml file, but I suppose that's just because XML is
absurdly verbose (and Maven annoyingly chose to do things like
<quiet>true</quiet> instead of a quiet="true" attribute). I wonder if there's a
Maven plugin that allows you to specify your pom.xml in YAML or some less
verbose format and which automatically converts it to XML. That'd probably cut
the line count by 2/3.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2853 6335cc39-0255-0410-8fd6-9bcaacd3b74c
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
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
ray.j.greenwell