Martin,
My understanding is that the .class files needed to support enums for
1.4 are tiny. It was interesting, for example, that EMF's type safe
enum pattern turned out to be binary compatible with Java 5.0's enums.
It would definitely be interesting to hear from the JDT guys directly.
I believe the biggest roadblock in this space is Sun and its
conformance rules. We have exceedingly smart people around here who
can solve any technical problem! The JDT guys are exceptionally
amazing...
Cheers,
Ed
Oberhuber, Martin wrote:
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
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
|
