Re: [e4-dev] minimum execution environment for the "org.eclipse.e4.core.

[Oleg Besedin <obesedin@xxxxxxxxxx>]

That sounds good, and I do agree with
Susan's point that it will be better to separate this code from the application
services.

If nobody objects I'll make a new bundle,
something like "org.eclipse.e4.core.di" with the minimum EE of
Java 1.5 and move contexts + DI + bindings from the JSR330 in there. I'll
probably do it after EclipseCon to reduce changes to the consumers (as
we probably don't want the "core.services" bundle to re-export
the new bundle).

Sincerely,
Oleg Besedin

From:	John Arthorne/Ottawa/IBM@IBMCA
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Date:	03/04/2010 05:29 PM
Subject:	Re: [e4-dev] minimum execution environment for        the        "org.eclipse.e4.core.services"
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

I understand that annotations are very important to the injection mechanism,
and the non-annotation injection solution is not useful and we should get
rid of it. However, the injection code is only a small part of the org.eclipse.e4.core.services
bundle. This is also the bundle where all central non-UI e4 application
services are defined, none of which currently use or need Java 5 class
libraries. Making this change means nobody will be able to reference these
services in the future using a smaller class library profile. Although
nothing is definite yet, smaller class library profiles are on the plan
for Java 7, which means for the first time soon we may have small, modern
class libraries available for RCP application use. Large class library
usage in the API could also make multi-language or cross-compiling scenarios
harder to support for these core services. 

So, since the root problem here seems to be the injection mechanism, why
don't we move all the injection API and implementation into a different
bundle, separate from the actual core service APIs themselves? I think
this makes sense anyway, as someone might want to use these core APIs,
but not have a dependency on our injection system, either because they
don't want injection or because they are using Blueprint or some other
injection framework. Now that I think about it, the main client of the
injection API will be frameworks rather than typical client applications
and bundles, so removing it helps reinforce the focus of org.eclipse.e4.core.services
as primarly client API (API for people writing e4 bundles or applications).

Oleg Besedin/Ottawa/IBM@IBMCA
Sent by: e4-dev-bounces@xxxxxxxxxxx

03/04/2010 03:07 PM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	e4-dev@xxxxxxxxxxx
cc
Subject	[e4-dev] minimum execution environment for the        "org.eclipse.e4.core.services"

In the past we maintained that the minimum execution environment (EE) for
the "org.eclipse.e4.core.services" bundle will be Foundation
1.1 / J2SE1.4. 

Overtime, we discovered that there were problems in keeping 1.4 as a minimum
execution environment for dependency injection. Some problems were more
on the convenience side ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=284940
), but some were rather fundamental. 

In Java 1.5 we can use annotations to match values in the contexts to injected
fields and method arguments. In Java 1.4 we have to rely on tricks like
adding special prefixes to field names and requiring injected methods to
have special names. There is no good way to describe things like optional
injections or providers. Moreover, the original code supporting 1.4, not
being used, deteriorated over time and will require some effort to be fixed.
While it can be made to work, there is a substantial extra cost to developing
and maintaining two code paths. 

Recently the minimum EE for the bundle was bumped to 1.5 for other unrelated
changes, so, this seems like a good time to revisit the question of minimum
EE. 

My vote would be to say that dependency injection really needs Java 1.5+.
That would allow us to merge back the services fragment, remove duplicate
and deteriorated code, and provide cleaner, easier to understand API side
to consumers. 

Any opinions? 

Sincerely, 
Oleg Besedin _______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev