|
There's a big difference between "under consideration" and
what will actually get done in e4. Even this discussion on asynchronousity,
while interesting and important, isn't likely to lead to real code change,
IMHO.
And to compare this Java 4 versus 5 war to something we in the
embedded space are also familiar with, how many APIs are C++ only and aren't
based on a C layer. Java 5 will become ubuquitous when C++ does, which is
pretty much never.
Sorry, cranky today :(
Doug.
I hate to say it, but perhaps it's time to admit that Eclipse
community is too large and too divergent to be served by a single
platform. IMO, this is already happening and the e4 effort is in fact a
fork. With the radical changes under consideration here, it's safe to
say that 3.x is going to be around for a long long time and e4 is going to be
competing for its users and developers. Since e4's main selling point is
innovation and lighter legacy load, the decision on using Java 5 seems obvious
to me.
But to bring this back to asynchronous programming. The
concurrency package can be and has been cloned for older jvms, but I think
generics are just as important. Being able to parametrize the return
types in a future, callable, and a callback interface makes a huge difference
in making the code using them more readable and less error prone. Still,
using Java 5 is not an all or nothing decision, so I don't think it's
necessary to hold up development because there's no consensus on
it.
-Pawel
Ed Merks wrote:
Pawel,
Lack of progress on the Java 5 front is primarily
an issue with Sun's failure to keep the micro versions moving forward;
perhaps that's more my opinion than a fact. I believe that a 5.0 JVM
is not significantly bloated compared to 1.4 and that migrating the micro
libraries to 5.0 would not have a bloating impact on those either.
It's pretty frustrating to see stagnation of Java in one segment of the
community. While some in the community focus on what will be in Java
7.0 others are stuck feeling like they will never be able to move beyond
1.4. >From an E4 perspective of wanting to keep things lively,
vibrant, modern, and forward-looking, it's particularly frustrating.
This case here is just a micro example of it.
Pawel Piech wrote:
Hi
John,
I didn't mean to sound so categorical, so I apologize for
that. As you mentioned in the bug it's likely parts or all of
platform will never move to Java 5, so preconditioning improvements
in Eclipse APIs on it is a bad idea. But whatever new APIs are
created in this area, it would be ideal if they were designed in such a
way that projects using Java 5 could still leverage the concurrent package
and generics without having compatibility issues with rest of
platform.
Cheers,
Pawel
John Arthorne wrote:
I didn't make the
connection between the CBFuture class Martin proposed and Java 5's
Future, so I didn't mean to compare the job API to the
java.util.concurrent API. I agree that java.util.concurrent does a very
good job of separating concerns and providing reusable
interfaces/classes that we could incorporate into the Job API and other
Eclipse APIs. I know you're already aware of it Pawel, but for others
who are interested there is an existing bug report about making use of
java.util.concurrent API in the jobs API: https://bugs.eclipse.org/bugs/show_bug.cgi?id=178278.
I've referenced this thread in the bug so that the information is
available when the day comes that we can use Java 5 there.
John
Hi John,
I don't think it's fair to compare just the
*Future* interface to the entire jobs API. Future is a single
purpose interface, used to synchronously access a result of an
asynchronous operation. Jobs API includes, in some form,
additional features found in the concurrent package:
*Executor* - In
the concurrent package this is another single-purpose interface which
abstracts the task of running an operation using some facility. In
jobs API, this facility is implemented as a thread pool, or a UI
dispatch loop when using UIJob.
*Callable* - It's basically a
runnable with a return value. In jobs API, this is the
Job.run():IStatus method.
IMO, the killer feature of the
concurrent package is that you can pick and choose the elements to use
as is, re-implement other elements, and invent new elements as needed.
With the jobs API the choice is either all or nothing.
Looking forward in e4, or even 3.x, I hope that Eclipse can
support the complete java concurrent package as a layer either above or
below the jobs API.
If it is above, then all that would
be needed is an Executor implementation which is a proxy to the current
jobs API, which would simply execute Runnables and Callables using Jobs.
If it is below, which I think is the more work/more gain option,
then the jobs API becomes a collection of components:
- JobManager
becomes an Executor which accepts any Runnable or Callable, where
progress monitor and a scheduling rule are optional.
- A Job becomes
just an implementation of Callable<IStatus>.
- UIJob is
replaced by a separate implementation of an Executor.
-
etc.
Supporting the java concurrent package would only make
the current jobs api functionality more convenient and extensible.
The larger goal for e4 should be to make asynchronous programming
in Eclipse easier and safer. To that end we'd need additional
standard APIs for things like callbacks and realms, and more importantly
we'd need good tooling for validating and debugging asynchronous
systems.
Cheers,
Pawel
John Arthorne
wrote:
There doesn't seem to
be much difference between the future construct you describe and the Job
API. You can attach listeners to jobs which seems to be the same as your
Callback mechanism. Future.waitFor() is the same as Job.join(), and
Future.get() is similar to Job.getResult(). I did actually have futures
in mind when designing the jobs API, with the job's "result" being the
payload returned from the asynchronous operation. I initially made this
result of type Object so clients could pass back whatever return value
they wanted. I then perhaps mistakenly switched the result type to
IStatus, thinking that clients could return sub-types of Status
containing any result object they wanted. This is why I specified almost
nothing for the return value of Job#run and Job#getResult, leaving it as
a mechanism for clients to communicate whatever they want back to the
caller. In reality it didn't end up being used this way, because
people fell into the common coding patterns around IStatus and just
returned the usual OK/ERROR results.
So, I'm wondering if there's
something fundamental missing from Jobs that makes these asynchronous
coding patterns difficult, and is there some incremental improvement we
can make to Jobs to make it as expressive and useful as your Future
construct? If not, the org.eclipse.core.jobs bundle could still
perhaps be a home for such an API, since it obviously needs a backing
thread pool implementation with support for progress monitors,
etc.
John
Martin Oberhuber wrote on 10/30/2008 04:47:02 PM:
>
Hi Scott, Pawel and all,
>
> it looks like this Thread has
long left the resources/EFS
> aspect of things, and moved to a
more general discussion
> about infrastructure for asynchronous
coding patterns.
>
> I'd thus like to make the discussion
more general. We
> seem to agree that there needs to be some base
infrastructure
> for asynchronous coding patterns, and (perhaps
even more
> important) API Documentation for how to properly use
that
> infrastructure. If this base infrastructure is
unified,
> we all win.
>
> Thanks Scott for
volunteering to offer your expertise
> as well as contributions.
What could be the next steps
> towards making it happen? I'm
assuming that the base
> infrastructure should be in Equinox. Is
anyone from
> the Equinox team listening and could guide
through
> their process for contribution?
>
>
Assuming that Equinox is right, we should perhaps first
> find a
proper place for this discussion; then argue
> about good
infrastructure/patterns; these need to be
> backed by some actual
usage somewhere. Right now, it
> looks like what we'll want is at
least
>
> Future (aka RequestMonitor,
AsyncExecutionResult)
> Callback (aka Listener)
>
Status/MultiStatus (async variant)
>
Executor/Queue/Realm (for posting async Runnables/Callbacks
>
in a well-known Thread)
>
> along with some well-documented Exception types
(cancellation,
> timeout) as well as Threading paradigm.
>
> How to proceed from here? Potential clients of async
>
certainly include DD/DSF and ECF, perhaps Resources/EFS;
> who
else is interested in infrastructure for async?
>
>
Cheers,
> --
> Martin Oberhuber, Senior Member of Technical
Staff, Wind River
> Target Management Project Lead, DSDP PMC
Member
> http://www.eclipse.org/dsdp/tm
>
>
>
> >
-----Original Message-----
> > From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> > [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On
> > Behalf Of Scott Lewis
> > Sent:
Wednesday, October 29, 2008 7:06 PM
> > To: E4 developer
list
> > Subject: Re: [eclipse-incubator-e4-dev] [resources]
EFS, ECF
> > and asynchronous
> >
> > Hi
Martin,
> >
> > Oberhuber, Martin wrote:
> >
> Hi Scott,
> > >
> > > to me, Futures and
Listeners don't need to be a contradiction.
> > >
> >
> > Before my further comments...I don't believe
they are in
> > conflict either
> > (that is, both
can be used in some cases as described by Martin). I
> >
guess I sort of presented them as exclusive, but I didn't
> >
really mean to
> > have it be so.
> >
> >
> 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.
> > >
> >
> > I agree that the general issue of how to
handle progress monitors is
> > tricky. Although I
accept your ideas above as a possible
> > solution, I'm
> > not sure whether this is the 'right' mechanism or not for
'remote
> > progress monitoring'. I've been thinking
about this for some
> > time, but
> > still don't
feel like I have a good general solution for supporting
> >
IProgressMonitor for remote procedures.
> >
> > >
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.
> > >
> >
>
> I agree these are other issues...thanks.
> >
> >
> > > 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.
> > >
> >
> > Yes, I agree that these are issues. I also agree
that it would be
> > useful to have Equinox-specific impls of
Future (which is really what
> > the IAsyncResult interface
was meant to be and can/will
> > change to be if
> >
desired). Further, I've recently also realized that there
>
> also should
> > probably be something like remote impls
of
> > IStatus/MultiStatus, as I've
> > been doing
some remote mgmt interfaces (i.e. accessing and managing a
> >
remote processes' OSGi framework, p2, etc)...and it's clear
>
> to me that
> > it is going to be very helpful to support
the usage of
> > IStatus/Multistatus as return values, as well
as exceptions in remote
> > service access. I agree that
Future/IAsyncResult as well as
> > IStatus/Multistatus and
exception types should be widely
> > available (i.e.
>
> in Equinox rather than redone/available in many locations above
> > Equinox). We (ECF) are willing to contribute (and
modify as desired)
> > what we've done in this area (e.g.
IAsyncResult+impl,
> > RemoteStatus/RemoteMultiStatus,
exception types) as desired.
> >
> > Scott
>
>
> >
> >
> > > Cheers,
> >
> --
> > > Martin Oberhuber, Senior Member of Technical
Staff, Wind River
> > > Target Management Project Lead, DSDP
PMC Member
> > > http://www.eclipse.org/dsdp/tm
> > >
_______________________________________________
> > >
eclipse-incubator-e4-dev mailing list
> > > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> > >
> >
> >
_______________________________________________
> >
eclipse-incubator-e4-dev mailing list
> > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> >
>
_______________________________________________
>
eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev
mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev
mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
|
