Guys,
Comments below.
Schaefer, Doug wrote:
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.
There's a discussion killer. :-P
And to compare this Java 4
versus 5 war
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.
I can't comment on the C++ verses C thing , other than to mention that
Java killed the C++ IDE I was working on, but I see no reason why a
Java 5.0 version of the micro libraries for embedded devices are an
impossible thing. Talking to the compiler guys, I'm lead to believe
it's relatively trivial to cross compile Java 5.0 to 1.4 anyway; it's
just not allowed by the language. Goodness knows what Sun is
thinking...
Sorry, cranky today :(
I've got a pain in the neck myself...
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.
Blasphemer! :-P
IMO,
this is already happening and the e4 effort is in fact a fork.
There are folks working very hard to ensure it's not a fork. I.e., to
ensure that your 3.x plugins will run on 4.0...
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
I'm not sure the radical changes are the cause, but it seems a fairly
safe bet nevertheless.
and
e4 is going to be competing for its users and developers.
It will be hard to split the efforts...
Since e4's main selling point is innovation and lighter legacy load,
the decision on using Java 5 seems obvious to me.
Yes, I made that point at the summit. We can't make a legitimate claim
to achieving a progressive modern API while rejecting the modernization
of the language itself. Raw types just appear offensive when you've
spent a great deal of time eliminating every vestige of them as was the
case for EMF...
But to bring this back to asynchronous programming.
Nothing like an interesting digression into the parallel between C++
and C compared to Java 5.0 and Java 1.4 to keep us entertained. :-)
The concurrency package can be and has been cloned for older jvms, but
I think generics are just as important.
I can't help but bemoan how sad it is that there isn't a micro version
for 5.0! That pain in my neck gets worse just thinking about it. I
hope it stays at neck level...
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.
Some will argue it's just sugar, but the point is, that there are those
in the community of consider this sugar to make a huge difference, so
therefore it makes a huge difference.
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.
For the e4 UI work we're just starting to use and 5.0 and consider
things like cross compiling to 1.4 and back porting portions of
libraries to be a potential solution. It continues to be a festering
sore point though...
-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
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
|