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.
Presently we have some servlet bits from threerings, but shortly I'll be
pulling most of Narya's util package herein.
This is a public library, so we don't want hopelessly threerings-specific
things in there (put those in the newly slimmed down threerings library). What
we can do is rely on Guava, which is what keeps useful things out of samskivert
and often pushes them into weird places like Narya.
What we can also do is use ooo-util to export the latest version of samskivert
and Guava to all of our other projects. A project that relies on the latest
snapshot of ooo-util can expect to have the latest snapshot of samskivert and
Guava, and when either samskivert or Guava ships a versioned release, we'll
ship a versioned release of ooo-util so that projects can bump to that release
to obtain the latest transitive depends.
We should stronly resist the addition of additional depends to this library,
unless they are indisputably useful to every single library and project in the
whole wide world. Guava made that cut a long while back, and samskivert lingers
with us like an embarrassing uncle, but I don't imagine another universally
useful library is likely to come along in this decade. But if it does, we've
got a place to put it.
Michael Bayne