- Added ArrayUtil.indexOf(int[], int).
This has never been added, in all our years, because it exists in IntListUtil.
IntLists are sort of different from int[]s, they're designed such that a 0
is an empty slot. But indexOf() works the same in either one, so let's make
ArrayUtil the definitive container of this code, and have IntListUtil use
ArrayUtil.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2344 6335cc39-0255-0410-8fd6-9bcaacd3b74c
mdb's changes to GenUtil yesterday are causing it to choke when making type
names for arrays and causing genservice to blow up in yohoho. This checks
for the subclass of Type for arrays and properly generates a name for it.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2341 6335cc39-0255-0410-8fd6-9bcaacd3b74c
- Makes the button arg on GroupLayout.makeButtonBox a vararg so multiple
buttons can be passed in at creation time. It also adds a version using
center justification as the default since that's what we do about 80%
of the time in yohoho.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2337 6335cc39-0255-0410-8fd6-9bcaacd3b74c
for (CountHashMap.Entry entry : cmap.countEntrySet()) {
which you can't do with the somewhat butchered current entrySet()
implementation. Indeed, I'm not sure quite how one is supposed to use that.
Perhaps in an iterator and cast the result to a CountHashMap.Entry?
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2319 6335cc39-0255-0410-8fd6-9bcaacd3b74c
configuration system property is set (and a particular logger is not
specifically configured).
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2315 6335cc39-0255-0410-8fd6-9bcaacd3b74c
samskivert to use logging services without creating a dependency on a logging
implementation.
This is basically what JCL (Jakarta Commons Logging) does except they do
auto-detection based on what's in the classpath and we're only going to
auto-detect log4j and only use it if we see that a log4j configuration has been
provided via a system property (or maybe not at all, I'm not sure yet). The
point is avoid the major gripe about JCL which is that when you stick some
logging system's jar file into your classpath for some other dependency (or
it's there for unknown reasons like maybe your servlet container uses it), all
of a sudden your log output disappears or breaks.
I had an idea while doing this and couldn't resist slipping it in: all of the
logging methods take varargs additional parameters which are a set of key/value
pairs to append to the log message in our standard format with an optional
final exception to be logged as well.
So instead of:
log.warning("Oh crap, the fibbleminscher has exploded [state=" + 15 +
", monkeys=" + StringUtil.toString(_monkeys) + "].");
You do:
log.warning("Oh crap, the fibbleminscher has exploded.", "state", 15,
"monkeys", _monkeys);
The formatter automatically does the StringUtil.toString magic on the arguments
(and does it safely so that if toString throws an exception the log message
isn't lost). You can also throw an exception in the mix:
log.warning("Oh crap, the fibbleminscher has exploded.", "state", 15,
"monkeys", _monkeys, ioe);
Or supply one with no parameters:
log.warning("Oh mammy!", ioe);
Or even just log an exception if you have nothing pithy to add:
log.warning(ioe);
Some research shows that other people have started doing this in their logging
systems as well under the fancier name of parameterized logging. The big
benefit is that you can pass objects that are expensive to toString() and avoid
toString()ing them unless you're actually going to generate the log message.
In our case we also get the benefit of our standard formatting and less
cluttered code (begone lots of + ", ...=" + typing).
I'm going to be doing away with the old samskivert Log code and converting all
of our libraries (and projects) to use this new shim so that we can easily
switch to using log4j, which for other reasons we want to use instead of Java's
built-in logging.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2311 6335cc39-0255-0410-8fd6-9bcaacd3b74c
mdb