[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-incubator-e4-dev] e4 and Java5(was:Asynchronous Infrastructure)
|
Actually,
I think I see where the problem is.
If a cross-compiler compiles an enum into some non-1.5-runtime
utility class, the result will run on an 1.4 runtime but won't be
interoperable with other plugins compiled with 1.5 against an
1.5 runtime which also use enum but the "1.5 enum"...
That's not an issue with Generics, which are a source-only
concept.
Moreover, annotations likely won't be able to live in
1.4 compatible classfiles.
Long story short, if Equinox moved to 1.5 then it could
likely still be compiled into some JARs which can run on
an 1.4 only runtime, but those JARs would need to be
separate from the JARs used with 1.5. And enums would
need to be forbidden in the APIs.
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 Oberhuber, Martin
> Sent: Tuesday, November 04, 2008 9:56 PM
> To: E4 developer list
> Subject: RE: [eclipse-incubator-e4-dev] e4 and
> Java5(was:Asynchronous Infrastructure)
>
> Well,
>
> you can emulate Enums with a Class, can't you? In the end
> that's what the Java5 classlib does itself. The crosscompiler
> just needs to emit the required utility class(es). Whereby
> the hard thing is emitting the utility class(es) only once.
>
> I believe that's what retroweaver is doing too...
>
> 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 Tom Schindl
> > Sent: Tuesday, November 04, 2008 9:18 PM
> > To: E4 developer list
> > Subject: Re: [eclipse-incubator-e4-dev] e4 and Java5
> > (was:Asynchronous Infrastructure)
> >
> > Hi,
> >
> > There are constructs in Java 5 you can't compile to Java
> 1.4 like e.g.
> > enums whereas e.g. generics can get compiled to Java1.4
> > without problems
> > and javac itself has an unsupported feature to make this work [1].
> >
> > Tom
> >
> > [1]http://dev.eclipse.org/newslists/news.eclipse.tools.jdt/msg
> > 20212.html
> >
> >
> > Oberhuber, Martin schrieb:
> > > Hi all,
> > >
> > > I agree that Generics are a very big advantage of Java5, and
> > > a decision in favor or against generics should likely be made
> > > early, before much new code / API is created for e4. It's likely
> > > that the decision needs to be considered separately for various
> > > layers (Equinox/Runtime vs. RCP vs. IDE, particularly).
> > >
> > > Retroweaver [1] <http://retroweaver.sourceforge.net/>
> > supports compiling
> > > Java5 sources into Java4
> > > compatible binaries today. I'm not sure how good it is, and
> > > I'd assume that some strategic member(s) would rather
> > > beef up Eclipse's own ecj rather than relying on a SF project
> > > it if we wanted to cross-compile.
> > >
> > > That being said, is anybody from JDT core listening here?
> > > Is it technically feasible to compile 1.5 sources into 1.4
> > > bytecode with ecj?
> > >
> > > I'm wondering how we can best move this important discussion
> > > forward without burning everybody's time in flame wars.
> > > I'd love to hear McQ's opinion on the matters.
> > >
> > > [1] http://retroweaver.sourceforge.net/
> > >
> > > Cheers,
> > > --
> > > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River*
> > > Target Management Project Lead, DSDP PMC Member
> > > http://www.eclipse.org/dsdp/tm
> > >
> > >
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > > *From:* eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> > > [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx]
> > *On Behalf Of
> > > *Ed Merks
> > > *Sent:* Tuesday, November 04, 2008 8:07 PM
> > > *To:* E4 developer list
> > > *Subject:* Re: [eclipse-incubator-e4-dev] Asynchronous
> > > Infrastructure (was:EFS, ECF and asynchronous)
> > >
> > > 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.
> > >>
> > >>
> > --------------------------------------------------------------
> > ----------
> > >> *From:* eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> > >> [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] *On
> > >> Behalf Of *Pawel Piech
> > >> *Sent:* Tuesday, November 04, 2008 1:43 PM
> > >> *To:* E4 developer list
> > >> *Subject:* Re: [eclipse-incubator-e4-dev] Asynchronous
> > >> Infrastructure (was:EFS, ECF and asynchronous)
> > >>
> > >> 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
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> *Pawel Piech <pawel.piech@xxxxxxxxxxxxx>*
> > >>>>> Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> > >>>>>
> > >>>>> 10/31/2008 12:53 PM
> > >>>>> Please respond to
> > >>>>> E4 developer list
> <eclipse-incubator-e4-dev@xxxxxxxxxxx>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> To
> > >>>>> E4 developer list
> > <eclipse-incubator-e4-dev@xxxxxxxxxxx>
> > >>>>> cc
> > >>>>>
> > >>>>> Subject
> > >>>>> Re: [eclipse-incubator-e4-dev]
> > Asynchronous Infrastructure
> > >>>>> (was: EFS, ECF and asynchronous)
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> 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@eclipse.org_
> > >>>>> <mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx>
> > >>>>> > >
> > [_mailto:eclipse-incubator-e4-dev-bounces@eclipse.org_] 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_Asy
> > nchronous_
> > >>>>> > > >
> > >>>>> > > > * 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@eclipse.org_
> > >>>>> <mailto: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@eclipse.org_
> > >>>>> <mailto: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@eclipse.org_
> > >>>>> <mailto: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@eclipse.org_
> > >>>>> <mailto: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
> >
> >
> > --
> > B e s t S o l u t i o n . a t EDV
> > Systemhaus GmbH
> > --------------------------------------------------------------
> > ----------
> > tom schindl leiter
> > softwareentwicklung/CSO
> > --------------------------------------------------------------
> > ----------
> > eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43
> > 512 935834
> > _______________________________________________
> > 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
>
