+1 for "*If we wish to do async stuff it should be based off of java 5
futures or guava's ListenableFutures. Those APIs and libraries are far
more natural to java devs in the wild. Or we can get inspiration from
scala and akka on how to do async well in java. In short, if we have a
real use
Yeah, I understand the timing aspect. If there's already a lot in progress,
then I'd rather not step in front of that train. So as long as we agree going
forward we look to guava or something, then we can figure out how to get there.
Regarding the storage framework, can Edison or Min chime
To tell the truth, I don't like the use of cglib in this case either, it
is per-request of making callback input available to IDE's intelli-sense
editing and be friendly to automatic code-refactoring through IDE
(Eclipse) which we do all the time.
I'm fine with us to go with other standard approac
Kelvin,
I really have some concerns about the entire async framework that was put into
place as part of the ipc framework. I don't know what VM sync is so I can't
really comment too much on that.
Basically my concern with the async framework is that it's yet another custom
ACS thing. The use
New VM sync and job flow handling are moving towards event-driven model
which is async natural. Not sure about the details on how storage
framework is using async mechanism, but argument on callback to assume
memory state does not stand as strong as it might be, since arguments in
any regular call
+1 for removing complexity especially if the sync pattern is being used on
top of the async pattern.
I see this behavior in the AgentManager.send as well -- even thought the
AM
is capable of async, practically nobody uses it as such.
But I guess the question will arise : what if I do want more th
