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/i...@ibmca Sent by: [email protected] 03/04/2010 03:07 PM Please respond to E4 Project developer mailing list <[email protected]> To [email protected] 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 [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
