No, Java is bad. If you want to minimize short-lived objects,
use C. Nothing faster than short-lived objects living on the
stack.
Being facetious of course ;) maybe...
Doug
David,
So iterators are bad?
:-P
Cheers, Ed
David Orme wrote:
Re: explosions of inner classes
On Android (and probably other embedded VMs) construction is expensive
and also leads to more GC pauses. Google recommends minimising
architectures that force a lot of short-lived objects.
Just one more data point for the discussion.
-Dave Orme
On Oct 29, 2008 5:30 AM, "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
wrote:
Hi Scott,
to me, Futures and Listeners don't need to
be a contradiction. What's more interesting to me, is how to deal with
Progress. When a Progress Monitor already exists for the client,
then using it makes a lot of sense even if the result is
obtained asynchronously:
final CBFuture<IFileStore[]>
childrenF = myFileStore.list(myProgress); childrenF.chain(new
Callback() { public void onDone(IStatus result) {
if (result.isOK()) {
handleResult(childrenF.get()); }
}; });
I'm using class "CBFuture" as an "enhanced Future" that
allows registering Callbacks. Using a Callback style of handling
things, or CBFuture.waitFor() remains up to the client. Note that
I'm using a "chain()" method to indicate that the Framework/Future
could allow chaining multiple callbacks such that one is exeucuted
after the other. Also note how the callback retrieves the result
of computation from the Future, and not from the callback
itself.
The problems that I have seen with callbacks in our
products in the past are listed on http://wiki.eclipse.org/E4/Pervasive_Themes#Becoming_More_Asynchronous
*
Much boilerplate code - Closures would be nice to avoid
explosion of anonymous inner classes, which could cause
bloat
* Need clarification on what thread and in what context
the callback will be called
* When debugging, it is very
hard to trace back the flow of operation across multiple callback
invocations. It can even make debuging close to impossible unless
some Tracing functionality for the callbacks is built into the
Framework (we ended up doing this in our commercial
product).
* Exception handling needs to be clarified. Java6 Future
only provides Future#isCanceled(), that's not enough since
the result of an operation might also be an exception.
I'm introducint "Istatus result" above but that's also
not optimal.
The synchronous variant needs more verbosity
writing it than one would expect, because cancellation and errors
(exceptions) need to be handled, wrapped and potentially re-wrapped
with Futures:
final CBFuture<IFileStore[]> childrenF =
myFileStore.list(myProgress); try {
handleResult(childrenF.get()); } catch(CancellationException e)
{ throw new OperationCancelledException(e); }
catch(ExecutionExeption e) { throw new CoreException(new
Status(/*.blabla*/)); }
although that could perhaps be
simplified if we declared some Eclipse specific implementation of
Future which throws the kinds of Exceptions that we already know (like
CoreException embedding an Istatus) instead of the JRE's
ExecutionException that's really alien to our current code.
Cheers, -- Martin Oberhuber, Senior Member of
Technical Staff, Wind River Target Management Project...
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incuba...
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
|