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
was necessary (javac claimed it was, Eclipse claimed it wasnt'). Fortunately,
we can do everything with Class<FooClient> methods that avoid the need for
supression entirely.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5275 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
generic array type handling and other niggling bits.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5267 542714f4-19e9-0310-aa3c-eee0fc999fb1
an enumerated list of every class in the library. Since there are (as far as I know) only two
people currently using Flex Builder, and since these project files are easy to create and maintain
locally, lets not deal with keeping a versioned copy up to date every time a file is created,
removed or renamed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5261 542714f4-19e9-0310-aa3c-eee0fc999fb1
CheckStyle. The checks are slightly looser than I'd like but way better than
nothing and we get a bunch of other useful warnings like shadowed names and
other handy bits.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5253 542714f4-19e9-0310-aa3c-eee0fc999fb1
Eclipse doesn't know about javadoc, we should file a bug.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5246 542714f4-19e9-0310-aa3c-eee0fc999fb1
* New static method to extract a bureau id from a username
* Inject the client manager in the registry and tack all bureau sessions
* Listen for sessions ending and call the clientDestroyed method
* Actually clear our the agents and remove the bureau from the map when the client is destroyed (this will trigger a new launch for the next agent request in that bureau)
* Deprecate addClientFactory
* Added lookup function to retrieve a bureau session by bureau id so that client code will be able to kill specific bureau sessions
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5238 542714f4-19e9-0310-aa3c-eee0fc999fb1
How was this not a problem before? Maybe we just got lucky
on yohoho and never had an npp say something with filterable
words in the translation key.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5237 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne