support streaming them as bytes.
It's better than writing a modified UTF String, but
it'd be even nicer if we could avoid the short to read the class name
(Enums are final), but I suppose we still have to know whether one is null
or not. Hm.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5920 542714f4-19e9-0310-aa3c-eee0fc999fb1
la String.intern) as we do class names, by sending the value the
first time and a short code thereafter (with special handling for
datagrams, where me must continue sending the mapping until we
know they've been received). This is mostly useful for the
lengthy config names and parameter names of Project X, but it
could conceivably also be used for things like NamedEvents, which
stream the same object field names many times in the course of a
stream.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5797 542714f4-19e9-0310-aa3c-eee0fc999fb1
acknowledged datagram (not the ones before it, which may or may
not have been received). Also, make sure we don't throw an
ArrayIndexOutOfBounds exception when retrieving a bogus class
mapping (so that we show the correct error logging information).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5751 542714f4-19e9-0310-aa3c-eee0fc999fb1
thing before committing instead of just going "oh yeah, I've been having this stuff
sitting around uncommitted for a while waiting on it to be blessed" and missing
out on things that'd changed in the meantime.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5400 542714f4-19e9-0310-aa3c-eee0fc999fb1
and you can't use @Override in java 5 when implementing an interface method.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5378 542714f4-19e9-0310-aa3c-eee0fc999fb1
- It's probably "more" standard, and maybe when they finally add Predicate
to java.util, it will be based on google's implementation.
- Unfortunately this is a little less efficient at runtime. The samskivert
Predicate can filter into a new Collection that knows its size, google's
code just returns an Iterable that is a *view* on the Iterable passed
in, so it doesn't know how many elements are in it. When we copy it into
an array, a List is first created to receive all the filtered elements
from this view, then that List is turned into an array. Oh well, it's
less lines of code here in this class thanks to Google's fun libs.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5375 542714f4-19e9-0310-aa3c-eee0fc999fb1
Note: this involves generated code from a samskivert patch I only just sent to mdb,
but he's in a meeting, so that won't show up for a little.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5369 542714f4-19e9-0310-aa3c-eee0fc999fb1
directly to stderr. Logging an exception with the associated warning does the
right thing and logs the stack trace via the logging system.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5318 542714f4-19e9-0310-aa3c-eee0fc999fb1
issue a warning if someone created a reader method or a writer method but not
both. Eclipse's static analysis helpfully pointed out that we'll never know if
someone fails to declare a reader but does declare a writer because of the way
method lookup fails. Since we want to actually detect that situation and
generate a helpful warnings, we restructure the code so that the static
analyzer is happy and developers asses are covered.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5286 542714f4-19e9-0310-aa3c-eee0fc999fb1
him (correctly) that some of the null checking there was not needed. If you have that setting
off, however, Eclipse warns that the @SuppressWarnings itself is unneeded. So, instead of freaking
out Eclipses of one persuasion or the other, lets just clean up the code and add an explanatory
comment.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5285 542714f4-19e9-0310-aa3c-eee0fc999fb1
knows some of those states of nullness can't exist, but the conditional
really reads nicely and conveys what's going on, so let's just suppress the warning.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5283 542714f4-19e9-0310-aa3c-eee0fc999fb1
Currently, Streamer will skip fields marked transient for the purposes of the default streaming implementation, but 'transient' is also used by the Java serialization mechanism, and there are instances where a field in a Serializable, Streamable object can't be streamed but should be serialized.
I have a bunch of code to check in related to the game server sending stat updates to the world server, but I'm going to hold off on those changes until I get the go-ahead from the powers that be that this is an acceptable solution to the problem.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5270 542714f4-19e9-0310-aa3c-eee0fc999fb1
logic. If we're inner and we're not static, we have a problem.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5019 542714f4-19e9-0310-aa3c-eee0fc999fb1
non-static member. Pre-1.5 VMs can't do all of these things and Retroweaver
freaks out at runtime when put to the task.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5018 542714f4-19e9-0310-aa3c-eee0fc999fb1
freakoutery as we try to stream the instance's implicit reference to its
containing class.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5001 542714f4-19e9-0310-aa3c-eee0fc999fb1
sandbox. They should work exactly the same but there seem to be remaining
niggles, so we'll iron those out without impacting other projects.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4706 542714f4-19e9-0310-aa3c-eee0fc999fb1
altogether as that also solves the "Class.getDeclaredFields() is not required
to return fields in declaration order" problem which has been looming. However,
this should work for now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4701 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne