I wasn't thinking clearly when I introduced that Depot depend. ooo-util is
*just* supposed to depend on Guava and samskivert and the fact that it was able
to do DB stuff because of samskivert's (unfortunate) database stuff was an
unhappy accident. ooo-util is really for only the most generic utility stuff.
I'm creating a new library, ooo-db which extends ooo-util with database stuff,
and OOO projects that do database things (which is not Narya, Nenya, Vilya &c)
can depend on ooo-db instead of ooo-util and they'll get a sensible Depot in
addition to a sensible Guava and samskivert.
don't want to all of a sudden foist a Depot on all the non-Depot needing
libraries that happen to already depend on ooo-util.
Originally lived in projectx and had a bunch more interesting stuff.
But the code that used it (gates, minerals, themes) went away because
all that mineral stuff went away.
Kept what's still in use. In particular, singleton() is quite useful
(really, Google should add it to Multisets or ImmutableMultiset).
The count ordering stuff is perhaps semi-deprecated, since Google has
added Multisets.copyHighestCountFirst().
Sometimes we have a Map already built via other methods, and there's
really no reason to copy each key/value into a Multimap prior
to encoding them.
Accept a Map<?, ?> and just take the small extra step of toStringing
every key and value, otherwise we'd have to transform the map
values and that's a bunch of extra wrapping.
Translations are sometimes done by third parties long after
development is done. A runtime exception is not appropriate
here. Return what we can and log extensively.
This was noticed when "{0 }" was written instead of "{0}".
When I had added this feature I verified that it would be OK to look up
a non-existant bundle, and even added a little note in the code.
But, it's the ResourceBundle that will be null, a MessageBundle
is always returned. And so, when it tried to initialize that bogus
MessageBundle and recursed into this same patch of code, the newly
added check for __parent would cause an NPE.
They're an implementation detail, not an exported public API. It would be nice
if Java allowed for package-plus-subpackage visibility.
I'm tempted to just use a Log class per-package across the board, which would
allow one to omit the import and use Log.log.info() which isn't half bad. It's
certainly better than adding a static Logger field to every single class that
uses logging, which is the "best practice" used by every other Java developer
in the world.
Michael Bayne