Fixes#212 that object and list substitutions could not have
whitespace in between.
This patch carries quoted-ness into ConfigString, which is somewhat
bogus, and we may be able to clean it up later if we start to track
the tokens that each value originates from.
Fixes#228 reported by @derrickburns; since we can interpret
numeric keys as lists, we sort the keys numerically to make
it easy to read the list value in order.
We want to avoid ever getting a ClassCastException, instead we
want a more helpful error. So write out all types explicitly.
This also will make it easier to ensure that tests are
comprehensive, and this commit adds a lot more tests.
This commit now supports typesafe List<T>, and allows you
to have fields of type Object, ConfigObject, Config, ConfigValue,
and Map<String,Object>, so if you want to accept "anything" you
can do that by specifying a vague type and then casting it yourself.
The right way to do these would be analogous to getInt, that is,
with a getter on Config that checks the range and throws the
right exception if the range is incorrect. But, I hesitate to
add getByte, getShort, getByteList, getShortList all to Config,
since they don't seem super useful. If we do want them though,
they should be added to beans and to Config at the same time,
so they are completely parallel to how Integer and Long work.
The advantage of this is that rather than throwing a single
"ConfigException.Missing" we can give the user a list of all
missing and wrong-typed settings for the entire bean up front.
Validation is not perfect (just as the regular checkValid method
isn't, it doesn't find all problems that actually getting the
value could find), but it does find the common cases of leaving
out a setting or having a blatantly incorrect type.
This was supposed to be done earlier, but the test for it wasn't
actually being run - it looked like it was in a list due to
indentation, but in fact was not in the list. So Scalariform
revealed the bug.
The spec already documents that these cases had undefined
behavior, so the tests were wrong and Java 8 broke them.
The tests are now still wrong, but have a comment that
should make it easier to understand what's happening next
time Java's hash table order changes.
