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
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ed
Merks
Sent: Wednesday, October 29, 2008 10:40 AM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] [resources] EFS, ECF and
asynchronous
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"
<[EMAIL PROTECTED]> 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
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
