Question Mark Hangs Over Dependency Injection
He has blogged about filing bugs, calling for the use annotations for invoke in e4 and support for accessing workbench services without DI. This comes after he dived into the pros and cons of DI in the forthcoming Eclipse platform, and raised a number of concerns.
To aid his investigation, he examined the e4 contact manager, which displays some of the features of e4, including DI. Madsen admitted that the DI, as seen in contact manager, cuts down on the need for listener code, especially in comparison to the the 3.x version, and features what he referred to as “understandable code.” After examining the code, he also decided that the intension becomes clear once you realise the injection is persistent. This means that changes in the context are automatically propagated to the view.
However, he wasn't happy with the other features he found. He was unsure what type of tooling would be used to access services in e4, and how developers would be warned about accidental changes in the e4 string. 3.x uses a Java method chain, meaning that general Java tooling helps users access the services in 3.x.
But the biggest sticking point for Masden, was the SaveHandler of the contact manager, which delegates the save functionality to the doSave method of the view by saving the current contact in the details view. He was unsure how this would work with the Java tooling, quick assists and refactoring. Masden also foresaw problems with maintenance and the testability of this functionality.
“Is the new magic DI code worth the lost functionality in the Java tooling?” he asked. He reached the conclusion that he himself would use a combination of "traditional" 3.x code and the new-style DI of e4.
His original blog drew a strong reaction against DI, with Thomas Hallgreen citing JBoss Seam as a tool that makes heavy use of DI. He agreed with Masden that, in his experience, DI makes it harder to debug, and can cause problems with refactoring. He advised using helper classes, services, and smart use common base classes instead of DI, to cut down on boilerplate code.
Despite the community's apparent uncertainty when it comes to DI in e4, if the e4 team can build the option to use DI, or completely ignore it, into the new Eclipse platform, then it seems that would be positively received by the community. Hopefully, the newly-filed bug reports, are a step towards this.