Issue with JSR330 is that it is a standard "nothing" since it does not define any behavior behind the annotations so it is pointless to have this standard since all the behavior is vendor dependent and therefore we must fix that by a good doc. Wonder if we should define more explicitly and not accross 4-5 doc pages this. Anyone with more knowledge of the plexus migration knows if it is just too much hidden and not well linked between these pages or if we have to create a ticket to fix it - or even import some sisu doc/highlights?
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 5 févr. 2021 à 12:11, Paul Hammant <p...@hammant.org.invalid> a écrit : > CDI came after JSR330 I think. I was on the JSR330 experts group. I could > be wrong there. > > Back history of dependency injection - it was an antidote to classic GoF > service-locator being used everywhere in Javaland. When we co-created > PicoContainer we were careful to avoid Singleton as a term or idiom for > good within the classbase and documentation. GoF singleton being a sibling > of service locator. Spring used the term in XML, then later as an > annotation (after Guice used Singleton as an annotation when Java5 kicked > off). Then JSR330 gets to include it in the set of annotations. > > Anyway, I always told readers "single managed instance" was the thing you > were trying to do. That could be one per JVM for a flat classloader design. > Or in a hierarchy of classloaders (Tomcat, Intellij, a stupid Jesktop > <http://jesktop.sourceforge.net/> thing I worked on) it would be one per > meaningful separate part of a tree of classloaders in a JVM. > > These days, twice a year I get to give an opinion of a technology in a > language that purports to be DI, but is actually > Container.getInstance().getComponent(<some key>) by various obfuscations > (service locator *not* DI at all). > > - Paul >
