[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] e4 and Java5 (was: Asynchronous Infrastructure)
|
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:* 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_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@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
