- Fix the bug with streaming an object that had a field typed as merely 'List'.
This will result in an incompatible change. Notably, BootstrapData has a List
field, but this shouldn't be accessed until after versions are checked.
The bug also meant that such fields could only hold an ArrayList. Now they
may hold any List type and will turn into an ArrayList on the other end...
- Support Map and Set streaming in the same way.
- Support using unmodifiedUTF if the "com.threerings.io.unmodifiedUTFStreaming"
system property is set to the String "true".
We can roll this back if it freaks something out, but I'd rather push forward.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6116 542714f4-19e9-0310-aa3c-eee0fc999fb1
preserve the registration order, in case that's significant. It would be nice
if Guava had an ImmutableLinkedHashMap, but I don't see such a thing.
Thanks to my newly added unit tests, I'm pretty confident that I didn't just
fuck something up. Woo.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6113 542714f4-19e9-0310-aa3c-eee0fc999fb1
- expanded Widget to contain all of the generally supported streamable types
(if I missed any, please add them);
- added proper equals() methods and tests to ensure that writing an object and
reading it back yield an object that equals() the original;
- added a binary blob containing the over-the-wire bits for said comprehensive
object; test that serializing an instance yields those bits and test that
unserializing those bits yields a proper object; this will catch future
situations where we inadvertently change the wire format for a type via
subtle changes to the streaming code;
- updated things to JUnit 4 style.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6110 542714f4-19e9-0310-aa3c-eee0fc999fb1
Assign the DEFAULT_MAP if we unstream an empty map, too.
Comment DEFAULT_MAP.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6107 542714f4-19e9-0310-aa3c-eee0fc999fb1
full of some weird old stuff, much of it replaced by using Guava or newer
1.5 features.
Instead of using a "sorted iterator", slap the elements in a TreeSet.
Insertions are O(log n), and sorting an ArrayList would be O(n log n),
so it should be pretty much the same (TreeSet probably uses more memory).
Comments welcome.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6098 542714f4-19e9-0310-aa3c-eee0fc999fb1
First & easiest, no longer include zeros in our built-up string. It used to
say things like "3 days, 0 hours, 2 minutes, 0 seconds" if your minUnit was
seconds. Now we'll just tell you it's 3 days & 2 minutes.
Second, it used to (and still does, if you use the old-signature wrapper)
round DOWN to the nearest minUnit.
For example, 59 minutes, shown with minUnit of hours, would claim to be
0 hours. For some things (e.g. showing time remaining on a subscription), that
kind of pessimistic display is the safe approach. For other things
(e.g. come back in 0 hours and your temp ban is over), we'd rather err on the
side of saying TOO much time (e.g. telling someone their suspension will be
over in 2 hours when they really only need to wait 61 minutes)
There's other rework that I'm itching to do in this stuff, but no, let's just
give ourselves an option on this particular thing so we can clean up one thing
in yohoho and be done with it for now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6096 542714f4-19e9-0310-aa3c-eee0fc999fb1
If it's public, we try to shadow it in a subclass & wind up still
getting THIS one.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6083 542714f4-19e9-0310-aa3c-eee0fc999fb1
Removed corelib and ooolib (aspirin) from our included libraries.
That ain't right. But they were also in the external libraries
and that seems to have been what was happening.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6073 542714f4-19e9-0310-aa3c-eee0fc999fb1
separate methods so that we can override them to do crazy stuff like simulate
latency/dropped packets for debugging.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6072 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell