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

[Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>]

Java 1.5 aside, I just wanted second the notion that the application services should be separate from the injection mechanism.

It's really nice for consumers to be able to look at that bundle and not get mired in the details of injection if they just want to know what services they can use.
(As a side note, we are also going to give each service their own package to also help in consuming them [1]).

susan

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=304239

John Arthorne ---03/04/2010 02:26:11 PM---I understand that annotations are very important to the injection mechanism, and the non-annotation injection solution is not u

John Arthorne <John_Arthorne@xxxxxxxxxx> Sent by: e4-dev-bounces@xxxxxxxxxxx 03/04/2010 02:25 PM Please respond to E4 Project developer mailing list

To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx> cc: Subject: Re: [e4-dev] minimum execution environment for the "org.eclipse.e4.core.services"

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