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/msg20212.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:* [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] *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:* [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] *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 <[EMAIL PROTECTED]>* >>>>> Sent by: [EMAIL PROTECTED] >>>>> >>>>> 10/31/2008 12:53 PM >>>>> Please respond to >>>>> E4 developer list <[email protected]> >>>>> >>>>> >>>>> >>>>> To >>>>> E4 developer list <[email protected]> >>>>> 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: [EMAIL PROTECTED] >>>>> <mailto:[EMAIL PROTECTED]> >>>>> > > [_mailto:[EMAIL PROTECTED] 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 >>>>> > > > [EMAIL PROTECTED] >>>>> <mailto:[email protected]> >>>>> > > > >>>>> >>>>> _https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev_ >>>>> > > > >>>>> > > >>>>> > > _______________________________________________ >>>>> > > eclipse-incubator-e4-dev mailing list >>>>> > > [EMAIL PROTECTED] >>>>> <mailto:[email protected]> >>>>> > > >>>>> >>>>> _https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev_ >>>>> > > >>>>> > _______________________________________________ >>>>> > eclipse-incubator-e4-dev mailing list >>>>> > [EMAIL PROTECTED] >>>>> <mailto:[email protected]> >>>>> > >>>>> >>>>> _https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev_ >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> eclipse-incubator-e4-dev mailing list >>>>> [EMAIL PROTECTED] >>>>> <mailto:[email protected]> >>>>> >>>>> _https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev_ >>>>> >>>>> _______________________________________________ >>>>> eclipse-incubator-e4-dev mailing list >>>>> [email protected] >>>>> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> eclipse-incubator-e4-dev mailing list >>>>> [email protected] >>>>> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> eclipse-incubator-e4-dev mailing list >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> eclipse-incubator-e4-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> eclipse-incubator-e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > 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 [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
