|
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).
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.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
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
|
