- 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
field/method names for the ActionScript version of a class (or to omit
something entirely). This removes the need for special case hackery for
toStringBuilder().
In order for annotations to work, however, we have to require that the
GenActionScriptTask be loaded from the same classloader that loads the classes
to be reflected upon. Before we only reflected on the target classes, never
instantiated them. Annotations are actually instantiated, so we have to be able
to create an instance of the ActionScript.class that is compiled into our
target classes and assign it to a reference that is compiled into
GenActionScriptTask. Beware the complexities of dealing with multiple class
loaders.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4405 542714f4-19e9-0310-aa3c-eee0fc999fb1
unmarshalled into an ArrayList on the receiver. Along the way, I improved
support for generic types as arguments to invocation services (which required
one unfortunate "sweeping" warning suppression, but since this is in generated
code, I think we can be sure it won't be doing anything untoward).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4375 542714f4-19e9-0310-aa3c-eee0fc999fb1
around of the interface (I wanted to automatically call getStreamerClass() for
the caller but that turns out not to be possible when unstreaming so fuck it).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4373 542714f4-19e9-0310-aa3c-eee0fc999fb1
are now correct, but unfortunately a little more complicated.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4371 542714f4-19e9-0310-aa3c-eee0fc999fb1
type, but we don't really want to pollute our class <-> id mapping with a bunch
of extra fiddly enum classes, so we stream all enums as instances of their
declared type and let Enum.valueOf() map back to the custom derived type when
it creates an instance during deserialization.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4370 542714f4-19e9-0310-aa3c-eee0fc999fb1
value to avoid future compatibility problems if someone saves an object to a
database and then later adds a new enum anywhere but at the end of the list,
thereby changing the ordinals.
If you want maximal network efficiency, don't use enums. For most of what we'll
do with them, it doesn't merit having the future incompatibility hitch of
sending the ordinal.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4369 542714f4-19e9-0310-aa3c-eee0fc999fb1
ObjectInputStream works in conjunction with a ObjectOutputStream on the
other end. The ObjectOutputStream will always assign class codes starting
at 1 and increasing sequentially from there, so we can look up a class
by index rather than hashing.
Uses less memory and is faster.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4365 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell