Also, add some @Overrides that were missing on things that were overriding a base class method.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6570 542714f4-19e9-0310-aa3c-eee0fc999fb1
If we /didn't/ care at all about backwards compatibility, my preferred approach would have been to have the invoker for PeerManager injected in the constructor instead of as a field such that said constructor could be overridden and the invoker be injected with a different annotation.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6569 542714f4-19e9-0310-aa3c-eee0fc999fb1
RFC. I realize I need to add a lot of examples to the documentation.
The biggest win here is only needing to learn the ins and outs of
this one class, and using it everywhere for your listening/chaining needs.
Please, let me know what you think.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6568 542714f4-19e9-0310-aa3c-eee0fc999fb1
wearing the camouflage of being an empty method body.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6564 542714f4-19e9-0310-aa3c-eee0fc999fb1
how we're going to stream a class and then create the right streamer for it.
Using the ClassStreamer for an interface and then not doing any of the
ClassStreamer stuff means: don't use a ClassStreamer.
I went in here intending to find or create a dummy Streamable streamer that
all interfaces could share...
But, as it turns out, non-final arrays don't need a delegate streamer, so I can
just remove that and interface types will never create a Streamer.
(Interfaces can never be final.)
So: the problem just goes away and everything gets cleaner.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6563 542714f4-19e9-0310-aa3c-eee0fc999fb1
classes that rely on the marshallers never being initialized don't break.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6560 542714f4-19e9-0310-aa3c-eee0fc999fb1
original source code did not list it as such:
- protected Name _user;
- @Inject ChatHistory _chatHistory;
- }
I wonder whether it worked...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6559 542714f4-19e9-0310-aa3c-eee0fc999fb1
improvement in locality of code and reduction in LOC.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6556 542714f4-19e9-0310-aa3c-eee0fc999fb1
We need to support legacy closures that have multiple constructors, one of
which will be a zero-argument constructor. All of the existing static inner
classes that extend NodeAction/NodeRequest will be such legacy classes. Whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6555 542714f4-19e9-0310-aa3c-eee0fc999fb1
synthetic val$local fields that get inserted, only the this$outer field. And we
need to pass "zero" values for val$ fields to the synthesized constructor.
This means that closures cannot have more than one constructor, but since
they're anonymous inner classes, they necessarily have only one constructor, so
we should be fine.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6552 542714f4-19e9-0310-aa3c-eee0fc999fb1
warning about having to extend them with static inner classes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6551 542714f4-19e9-0310-aa3c-eee0fc999fb1
streaming mechanism will quietly gloss over the funny little outer class
reference stuffed into your closure as long as you promise not to use it
(because it's going to be null on the other side of the wire).
This will allow us to write:
_peermgr.invokeNodeAction(new NodeAction() {
...
});
which we presently have a big fat warning against, since it didn't work until
about 30 seconds from now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6550 542714f4-19e9-0310-aa3c-eee0fc999fb1
from the beginning, but useful if you clear the profiles in order to record
over a brief interval).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6546 542714f4-19e9-0310-aa3c-eee0fc999fb1
having every node connect to every other, we want to support having (for
example) nodes connect to a "super-peer" that distributes updates to its
children.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6537 542714f4-19e9-0310-aa3c-eee0fc999fb1
headers on the associated Java files were being stripped.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6534 542714f4-19e9-0310-aa3c-eee0fc999fb1
Bug 4464323 was filed 10 years ago, bringing this to Sun's attention, and has
been acknowledged as a known bug. Apparently this has not annoyed anyone on the
Java team enough to merit fixing. Sigh.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6532 542714f4-19e9-0310-aa3c-eee0fc999fb1
using a proxy, in which case we'll send the non-proxy hostname in the
bootstrap data.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6530 542714f4-19e9-0310-aa3c-eee0fc999fb1
not whether they're old or new.
OLD -> NAME_WITH_BYTE_ENUM
NEW -> ORDINAL
NEW_WITH_BYTE_ENUM -> ORDINAL_WITH_BYTE_ENUM
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6523 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Allow configuring of two new streaming policies for enums.
- Changed the alphabetical fields policy to be checked once on class init.
Let me elaborate on the first two changes:
1) The base Streamer class had grown to handle a variety of things.
There were two different ways to handle enums, a whole section of code
for arrays (two ways of handling those), and then custom reader/writer
methods were supported with fallback for regular old streaming classes.
A lot of this was checked by introspection every single time an object
was written/created/read. In addition, there were 6 different fields
in the base class, many of which would be unused by default. All
the BasicStreamers also inherited these fields and never did anything
with them.
So my change makes Streamer an abstract class with no non-static fields.
I pulled all the logic for different streaming strategies
into different classes and do the tests to determine which class
to use once when first setting up the streamer for a particular target class.
If our target class is an array with a final element type, why should
we be re-checking those two things each and every time an object is
written? Or if it's not an array and we've got field marshallers set up,
why are we wondering if it's an array or enum each time?
In addition, reading/writing would freak out if a field marshaller
was never found for a particular field. Let's fail faster and freak
out when the marshallers are first initialized, which is fine
now that (in a recentish commit) we don't initialize the marshallers
if there appears to be no reason to do so (if a Streamable class has
both a custom reader and a custom writer method, then the marshallers
are never used. The class could have non-transient fields that don't
stream, but it takes care of them itself in the custom methods.)
2) There are now three enum-streaming policies that can be configured.
- OLD, the default, will try to stream by byte if the enum is a ByteEnum,
and fall back to using the enum's name.
- NEW will always stream an enum by ordinal, using the smallest integer
type possible, given the enum's size. ByteEnum is ignored.
- NEW_WITH_BYTE_ENUM will do the ByteEnum thing for ByteEnums, and fall
back to the new ordinal thing for other enums.
The idea here is that narya streaming is designed specifically such that
the server and client are running the same code. There are some edge
cases, and some games persist streamed objects, but in general
streaming by ordinal should be fine.
But, it's opt-in for now. I can't go breaking everything.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6522 542714f4-19e9-0310-aa3c-eee0fc999fb1
Andrzej Kapolka