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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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:* [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_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 > >>>>> > > > [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 > _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
