Announcing @javax.inject.Inject

Home

News: Announcing @javax.inject.Inject

  1. Announcing @javax.inject.Inject (83 messages)

    Five years ago, Spring 1.0 brought Java dependency injection into the mainstream. Three years later, Google Guice 1.0 introduced annotation-based dependency injection and made Java programming a little easier. Since then, developers have had to choose between a) writing external configuration or b) importing vendor-specific annotations.

    Today, we hope to give developers the best of both worlds. Google Guice and SpringSource have partnered to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks. At the moment, the set of specified annotations consists of:
    • @Inject - Identifies injectable constructors, methods, and fields
    • @Qualifier - Identifies qualifier annotations
    • @Scope - Identifies scope annotations
    • @Named - String-based qualifier
    • @Singleton - Identifies a type that the injector only instantiates once
    One additional interface is specified for use in conjunction with these annotations:
    • Provider - Provides instances of a type T. For any type T that can be injected, you can also inject Provider.
    You can check out an early draft of the specification. We deliberately left external dependency configuration out, so as not to quash ongoing innovation. We haven't formally submitted this standard to the JCP yet, but we plan to do so shortly. Standards wonks can read a draft of our JSR proposal.

    The expert group will be inclusive and will work in the open. For example, our mailing list is publicly readable, and we host the specification at Google Code. Several industry players have already expressed interest in supporting this effort. Contact us if you'd like to help out.

    Threaded Messages (83)

  2. Re: Announcing @javax.inject.Inject[ Go to top ]

    it's about time. this should have been part of java 5.
  3. Re: Announcing @javax.inject.Inject[ Go to top ]

    @Inject(type="Hot Beef")
  4. All I can say...[ Go to top ]

    "YAY!" For both Guice and Spring Core it won't be much of a hassle to implement the annotations, they already have something similair. But having standards is always good! (like JPA for example) And to the guy who posted: "this all should have been in Java 5!" Why didn't you submit a JSR for it back then? This is also a public initiative... But yeah, its easy to blame Sun isn't it?
  5. Re: All I can say...[ Go to top ]

    Agree that this good news and JSR-299 smells too much of Seam and JSF for my liking.
    Why didn't you submit a JSR for it back then? This is also a public initiative... But yeah, its easy to blame Sun isn't it?
    Hey, I don't think anyone was blaming Sun or anything here. And I wish people would stop playing martyr and saying stuff like "why didn't you contribute to the JCP!!". There are plenty of reasons. Jeez.
  6. Re: All I can say...[ Go to top ]

    "YAY!"

    For both Guice and Spring Core it won't be much of a hassle to implement the annotations, they already have something similair. But having standards is always good! (like JPA for example)

    And to the guy who posted:
    "this all should have been in Java 5!"

    Why didn't you submit a JSR for it back then? This is also a public initiative... But yeah, its easy to blame Sun isn't it?
    Because submitting a JSR doesn't mean they are going to develop your proposal?
  7. Hi,[ Go to top ]

    What I am searching for is adolescent humans of access in our community pass4sure 640-802. I am alive on ambience up an Advisory Council that will serve as consultants and connectors for the project pass4sure F50-531. I would adulation to acquisition a (or several) motivated, affiliated adolescent humans from the association who affliction about the affair of advantageous sexuality pass4sure 1Y0-A05. Adolescent parents would be a plus! Part of the access that Real Life. Real Talk. takes is that we charge non-traditional partners, including the business community, to accouterment this issue.

  8. Re: Announcing @javax.inject.Inject[ Go to top ]

    Five years ago, Spring 1.0 brought Java dependency injection into the mainstream. Three years later, Google Guice 1.0 introduced annotation-based dependency injection and made Java programming a little easier. Since then, developers have had to choose between a) writing external configuration or b) importing vendor-specific annotations.

    Today, we hope to give developers the best of both worlds. Google Guice and SpringSource have partnered to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks.

    At the moment, the set of specified annotations consists of:
    • @Inject - Identifies injectable constructors, methods, and fields
    • @Qualifier - Identifies qualifier annotations
    • @Scope - Identifies scope annotations
    • @Named - String-based qualifier
    • @Singleton - Identifies a type that the injector only instantiates once
    One additional interface is specified for use in conjunction with these annotations:
    • Provider - Provides instances of a type T. For any type T that can be injected, you can also inject Provider.
    You can check out an early draft of the specification. We deliberately left external dependency configuration out, so as not to quash ongoing innovation. We haven't formally submitted this standard to the JCP yet, but we plan to do so shortly. Standards wonks can read a draft of our JSR proposal.

    The expert group will be inclusive and will work in the open. For example, our mailing list is publicly readable, and we host the specification at Google Code. Several industry players have already expressed interest in supporting this effort. Contact us if you'd like to help out.
    That's cool. I may be one of the few people who used the AOP alliance interfaces with an eye to standardization. Personally, I prefer external config, but am always open to having my assumptions challenged. This gives one some additional options to experiment. Here's to organic standardization!
  9. That's cool. I may be one of the few people who used the AOP alliance interfaces with an eye to standardization.

    Personally, I prefer external config, but am always open to having my assumptions challenged. This gives one some additional options to experiment.

    Here's to organic standardization!
    The two are not distinct from each other. You can have annotations and external deployment. Despite many folks opinions about EJB, I think this part they got right by allowing annotations to be overridden by external XML files. I don't use injection outside of EJB, but I think this kind of standardization will make injection ever more easy to use and wide spread.
  10. That's cool. I may be one of the few people who used the AOP alliance interfaces with an eye to standardization.

    Personally, I prefer external config, but am always open to having my assumptions challenged. This gives one some additional options to experiment.

    Here's to organic standardization!


    The two are not distinct from each other. You can have annotations and external deployment. Despite many folks opinions about EJB, I think this part they got right by allowing annotations to be overridden by external XML files.

    I don't use injection outside of EJB, but I think this kind of standardization will make injection ever more easy to use and wide spread.
    You are right. My last use of DI was actually moving toward using annotations in the data tier, but XML for wiring objects and applying AOP. The overridding annotation via XML does seem like a great way to go. Have some reusable code with say, caching injected via annotations by default, but perhaps change some of the specifics of the DI in the config,say cache provider. Regardless, I enjoy hearing when different systems come together, in effect, jelling and firming up the most common ideas. Exciting times...
  11. Flowers and unicorns[ Go to top ]

    Since JSR-299 is in the process of being finalized, and basically contains the same annotations as this specification (with some additional scope for Java EE and difference in naming) one might think that it's merely a way for Spring Framework to protect their interests in the dependency injection space with this disruption. Or somebody at Google has a axe to grind with Gavin, since JSR-299 doesn't match Guice exactly enough. The best approach at this point would be to ensure that JSR 299 satisfies the needs of users who solely rely on Java SE, and back-port or adopt the same set of annotations and deployment specification at a future date to the Java SE platform, similar to how JMX was eventually adopted. I think Web Beans as-is gets pretty close it, the reference implementation requiring only Javassist and Dom4J for running on JSE.
  12. Re: Flowers and unicorns[ Go to top ]

    Since JSR-299 is in the process of being finalized, and basically contains the same annotations as this specification (with some additional scope for Java EE and difference in naming) one might think that it's merely a way for Spring Framework to protect their interests in the dependency injection space with this disruption. Or somebody at Google has a axe to grind with Gavin, since JSR-299 doesn't match Guice exactly enough.
    Please refrain from political games and don't make this personal. Some of us just want the best technical solution regardless of where it comes from. You say 299 is in the process of being finalized, but last I checked, you dropped the XML configuration and are just getting started on a plain Java-based configuration (perhaps something Guice-like?). If the time line is that much of an issue, 299 should go forward with its own annotations, but we will still standardize a standalone set of annotations. I'm sorry, but the JCP doesn't allow you to pull out arbitrary subsets of specifications, so using 299 as is is a non-starter even if 299 were to adopt our more precisely specified set of annotations. I think James Strachan put it well:
    I can understand 299 folks wanting there to be just one spec that talks about IoC. However IoC is a large complex area that is still undergoing quite a bit of innovation (e.g. see the changes in Guice 2 and the JavaConfig which is part of Spring 3). For me the great thing about the new @Inject JSR is that its small, simple and focusses on the common well understood part of IoC (the annotations you add to your objects so that popular IoC containers can inject your objects). This is the thing I most want - a standard set of annotations I can use everywhere in objects - then consumers of those objects can choose whatever IoC container they wish to wire things together be it Spring or Guice or a JSR 299 provider or whatever. The actual wiring code (in Java, XML or some other script/language) tends to be kinda small stuff relative to the tons of Java code for the objects themselves. Given the large variety and constant innovation in the wiring side of things, its probably a bad time to try lock that part down as I don't think there's consensus on how that part should look (though Guice 2 and Spring JavaConfig seem to get closer all the time). 299 however standardizes lots of things which only seem to be done in Seam; I don't see Spring, Guice or Pico implementing 299 any time soon as its a bit too big - however all IoC containers should be able to implement @Inject pretty easily; most IoC containers have already got something like @Inject in them today. So as a practical kinda guy at heart, the best way forward IMHO to be able to write IoC container agnostic objects that can then be injected by Spring, Guice, Pico, Tapestry or indeed a 299 provider seems to be the @Inject JSR. This doesn't mean 299 isn't useful; there's some interesting stuff in there particularly relating to eventing and JEE integration to IoC; but I see getting @Inject done and adopted by Spring, Guice & Pico (and hopefully the JSR 299 RI too!) to be most important for IoC in the Java ecosystem as a whole.
  13. Re: Flowers and unicorns[ Go to top ]

    I just want to add support to Strachan's desire to have a standard set of annotations that I can apply to my objects that can apply to any injection technology. The information covered by this @Inject API is what I need 95% of the time. The ability to use something standard and not container specific would be huge.
  14. I'm sorry Bob[ Go to top ]

    I'm sorry Bob. Have you heard of Resin? Caucho did an excellent job by continuously releasing Resin IoC (now called CanDI) according to every preview of JSR 299 (even at proposal stage in Q4 2007). Resin IoC plays very well or better than Guice or Spring in web development. I switched from Spring to Guice at March 2007 and then switched from Guice to Resin IoC at March 2008, and I've got notable production improvement for each switching. Thanks for Guice 1.0, Bob. I know Resin IoC could run only in Resin App Server, I know that. What I really mean is that: Will u keep your good and hard working to release Guice 2.0 or keep your words reserved until something was finally done and ready to use. I use hibernate. I thank Gavin, but I don't like him very much. I don't like JSR299 being too late to be finalized too. I think both of you or even Rod maybe took too many energy into political or personal work. People like Scott Fergerson of Caucho.com said nothing and argued nothing but did very impressive work than any of you. Have you EVER mentioned him or Resin in ANY public place of blog? Have you EVER thanked him for his efforts? Just go camping or fishing, if u don't like hard work. Don't treat this very serious thing (DI or AoP) as a sweet candy after your vacation. Sorry again for my reasonless surmise.
    Since JSR-299 is in the process of being finalized, and basically contains the same annotations as this specification (with some additional scope for Java EE and difference in naming) one might think that it's merely a way for Spring Framework to protect their interests in the dependency injection space with this disruption. Or somebody at Google has a axe to grind with Gavin, since JSR-299 doesn't match Guice exactly enough.


    Please refrain from political games and don't make this personal. Some of us just want the best technical solution regardless of where it comes from.

    You say 299 is in the process of being finalized, but last I checked, you dropped the XML configuration and are just getting started on a plain Java-based configuration (perhaps something Guice-like?).

    If the time line is that much of an issue, 299 should go forward with its own annotations, but we will still standardize a standalone set of annotations. I'm sorry, but the JCP doesn't allow you to pull out arbitrary subsets of specifications, so using 299 as is is a non-starter even if 299 were to adopt our more precisely specified set of annotations.

    I think James Strachan put it well:


    I can understand 299 folks wanting there to be just one spec that talks about IoC. However IoC is a large complex area that is still undergoing quite a bit of innovation (e.g. see the changes in Guice 2 and the JavaConfig which is part of Spring 3).

    For me the great thing about the new @Inject JSR is that its small, simple and focusses on the common well understood part of IoC (the annotations you add to your objects so that popular IoC containers can inject your objects). This is the thing I most want - a standard set of annotations I can use everywhere in objects - then consumers of those objects can choose whatever IoC container they wish to wire things together be it Spring or Guice or a JSR 299 provider or whatever. The actual wiring code (in Java, XML or some other script/language) tends to be kinda small stuff relative to the tons of Java code for the objects themselves. Given the large variety and constant innovation in the wiring side of things, its probably a bad time to try lock that part down as I don't think there's consensus on how that part should look (though Guice 2 and Spring JavaConfig seem to get closer all the time).

    299 however standardizes lots of things which only seem to be done in Seam; I don't see Spring, Guice or Pico implementing 299 any time soon as its a bit too big - however all IoC containers should be able to implement @Inject pretty easily; most IoC containers have already got something like @Inject in them today.

    So as a practical kinda guy at heart, the best way forward IMHO to be able to write IoC container agnostic objects that can then be injected by Spring, Guice, Pico, Tapestry or indeed a 299 provider seems to be the @Inject JSR.

    This doesn't mean 299 isn't useful; there's some interesting stuff in there particularly relating to eventing and JEE integration to IoC; but I see getting @Inject done and adopted by Spring, Guice & Pico (and hopefully the JSR 299 RI too!) to be most important for IoC in the Java ecosystem as a whole.
  15. Re: Flowers and unicorns[ Go to top ]

    Please refrain from political games and don't make this personal. Some of us just want the best technical solution regardless of where it comes from.

    You say 299 is in the process of being finalized, but last I checked, you dropped the XML configuration and are just getting started on a plain Java-based configuration (perhaps something Guice-like?).
    The first sentence asks for refraining from making it personal, and the second accuses me ("you") of dropping an XML configuration. I have no idea I was somehow involved with that decision, given I'm just a spectator. :-) So, who's misrepresenting who? My technical viewpoint: I see JSR-299 more important (valuable) to fixing Java EE than I see this spec being important to Java SE. What adding @Inject to Java SE seems to suggest, is that all your important service objects "should" have these annotations in them to be interoperable with other components. In many ways, it's suggesting: We have this new standard and for the past 10 years of Java you've been writing code one way. But now you should add @Inject to all your application code for IoC interoperability, and use an IoC container for deployment. I don't really like the idea of retrofitting existing classes with @Inject or people asking me to add them to my new classes even though I don't need @Inject myself. Java was designed with traditional constructors and static build methods or locator methods and now Joe Programmer has to then wrap his brain around @Inject? And I don't see the burning need in standardizing this, even though I do find IoC pretty useful in specifying an application deployment configuration, I don't want or need it in third-party libraries. Thus, I'm perfectly happy using a specific set of non-standard annotations in my application, since it really just lives at the outermost deployment level. In the Java EE world, the EJB3 programming model already uses a lot of lifecycle methods and annotations. Really what has needed fixing in EE is JSF, which 299 addresses well. Adding a conversational model, POJO services, and fixing other issues in web applications is also important. In SE: I just don't see much use in adding in annotations if you don't have a way to actually use IoC. That is, write a complete application that uses them, in plain Java. Without a deployment framework, you may very well end up with a lot of annotated code but no way to assemble it into a deployment, without going to a third-party vendor. What subsystems in Java SE work this way? Existing subsystems, like XML parsing, are at least pluggable, ship with a default version, and share the same standard API.
  16. Isn't DI an Anti-Pattern?[ Go to top ]

    Sorry to spoil the party, but dependency injection, esp. (its primary use case) DI of DAOs into BusinessObjects, has turned out to be an Anti-Pattern. Anything that fosters this style of programming should be avoided.
  17. Sorry to spoil the party, but dependency injection, esp. (its primary use case) DI of DAOs into BusinessObjects, has turned out to be an Anti-Pattern. Anything that fosters this style of programming should be avoided.
    I think you are talking only about setter injection, and it may be an antipattern in that it prevents immutability. Constructor injection is the good practice here.
  18. I think you are talking only about setter injection, and it may be an antipattern in that it prevents immutability. Constructor injection is the good practice here.
    Objects returned by DAOs are (thanks to Hibenate/JPA) not only updateable but can also be navigated. This makes the BusinessObject fully dependent on the database structure. Clearly an Anti-Pattern.
  19. Re: Isn't DI an Anti-Pattern?[ Go to top ]

    Objects returned by DAOs are (thanks to Hibenate/JPA) not only updateable but can also be navigated. This makes the BusinessObject fully dependent on the database structure. Clearly an Anti-Pattern.
    My DAOs aren't typically coupled with my database structure in any way. Of course, I think some people refer to this as the Repository pattern nowadays. In any case, it's orthogonal to DI.
  20. Re: Isn't DI an Anti-Pattern?[ Go to top ]

    My DAOs aren't typically coupled with my database structure in any way. Of course, I think some people refer to this as the Repository pattern nowadays. In any case, it's orthogonal to DI.
    It's orthogonal to DI. But nowadays DI is mostly used in ways that defeat the original purpose (decoupling). The use cases of DI are probably much narrower than what is currently propagated. At least, retrieving beans/records via injected DAOs and navigating through them in BusinessObjects hardly makes sense.
  21. Re: Isn't DI an Anti-Pattern?[ Go to top ]

    If your DAO/Repository isn't coupled to your db structure, how is this still an anti-pattern? How is one entity supposed to look up another? Injecting a DAO/Repository into an entity is a fine pattern so far as I'm concerned; we even recommend it in Guice's docs.
  22. Re: Isn't DI an Anti-Pattern?[ Go to top ]

    If your DAO/Repository isn't coupled to your db structure, how is this still an anti-pattern? How is one entity supposed to look up another? Injecting a DAO/Repository into an entity is a fine pattern so far as I'm concerned; we even recommend it in Guice's docs.
    The problem is not the injected DAO but what it returns: a navigable object graph. Since in a typical JPA/Hibernate setting all objects can access both their children and their parent each DAO effectively returns (a dependency to) the whole database structure to the caller. Although the database access is encapsulated and hidden from the user the database structure is not. I'm currently maintaining a heavily spring-ified application where this problem is highly visible. One consequence e.g. is that testing becomes more difficult. Nobody cares to mock up the object graphs. For me, DI has very special, limited use cases. Injecting DAOs into BusinessObjects is not one of them.
  23. Re: Isn't DI an Anti-Pattern?[ Go to top ]

    Since in a typical JPA/Hibernate setting all objects can access both their children and their parent each DAO effectively returns (a dependency to) the whole database structure to the caller. Although the database access is encapsulated and hidden from the user the database structure is not. I'm currently maintaining a heavily spring-ified application where this problem is highly visible. One consequence e.g. is that testing becomes more difficult. Nobody cares to mock up the object graphs. For me, DI has very special, limited use cases. Injecting DAOs into BusinessObjects is not one of them.
    It sounds like the real anti-pattern here is that your DAOs are coupled to your database structure. Aren't DAOs supposed to decouple you from your database structure? Mine always have. When it comes to mocking, I'd try EasyMock. You only have to mock out the methods that your test will touch.
  24. Re: Isn't DI an Anti-Pattern?[ Go to top ]

    It sounds like the real anti-pattern here is that your DAOs are coupled to your database structure. Aren't DAOs supposed to decouple you from your database structure? Mine always have.
    Suppose you injected a CustomerDAO. In a typical DI/DAO (a.k.a. Spring/Hibernate) application it would be used like this: Customer c = customerDAO.getCustomerById(someId); Address a = c.getAddress(); List contracts = c.getContracts(); for(Contract contract : contracts) { List i = contract.getItems(); //... } // ...
  25. Re: Isn't DI an Anti-Pattern?[ Go to top ]

    Casual Visitor, sooooo... what? Rickard, I commented on your blog. My guess is that you didn't grok @Qualifier.
  26. Bob, this looks awesome! I think you managed to capture at least 95% of useful functionality with just 6 simple interfaces/annotations. I wish more standards were like this.
  27. Re: Announcing @javax.inject.Inject[ Go to top ]

    ...Today, we hope to give developers the best of both worlds. Google Guice and SpringSource have partnered to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks....
    Long way from "I do think Spring sucks (http://crazybob.org/2007/06/lies-damned-lies-and-xml.html)"
  28. Re: Announcing @javax.inject.Inject[ Go to top ]

    Firstly, it is always good to see anyone embracing standardization in favor of proprietary paths. That being said, I have to say I am skeptical about the technical merit of a JSR that provides limited portability and does not seem to have very broad implementation support, especially vis-a-vis JCDI (JSR 299). Indeed, I am inclined to see this merely as a limited subset of JSR 299. I would also love to hear detailed comments on what portions of JSR 299 the leads of this spec disagree with and how they believe a more complete standard would impede innovation or what JSR 299 features they believe are not yet well understood? Also, who are some of the major players hinted at? Are they existing Java EE adopters? Cheers, Reza ------------------------------------------ Expert Group Member, Java EE 6 and EJB 3.1 Author, EJB 3 in Action Independent Consultant
  29. Firstly, it is always good to see anyone embracing standardization in favor of proprietary paths.

    That being said, I have to say I am skeptical about the technical merit of a JSR that provides limited portability and does not seem to have very broad implementation support, especially vis-a-vis JCDI (JSR 299). Indeed, I am inclined to see this merely as a limited subset of JSR 299.

    I would also love to hear detailed comments on what portions of JSR 299 the leads of this spec disagree with and how they believe a more complete standard would impede innovation or what JSR 299 features they believe are not yet well understood? Also, who are some of the major players hinted at? Are they existing Java EE adopters?

    Cheers,
    Reza
    I think Reza's comments/questions here are very well put and very fair. I would also like to see this answered to give me a better perspective on this issue.
  30. Re: Announcing @javax.inject.Inject[ Go to top ]

    I have to say I am skeptical about the technical merit of a JSR that provides limited portability and does not seem to have very broad implementation support, especially vis-a-vis JCDI (JSR 299).
    299 can and should use these annotations. Doing so will improve 299 as our annotations are already better specified. This spec uses BNF grammar while the comparable parts of 299 are more example-driven and less precise.
    Indeed, I am inclined to see this merely as a limited subset of JSR 299.
    This spec does subset 299, but we will still have 299, so you lose nothing.
    I would also love to hear detailed comments on what portions of JSR 299 the leads of this spec disagree with
    See this thread.
    and how they believe a more complete standard would impede innovation
    299 is already inferior to existing configuration approaches. What's worse, it's not clear how a subsequent release of 299 could address its limitations in a clean way.
    or what JSR 299 features they believe are not yet well understood?
    I've read the 299 public draft spec and understand it just fine. The spec is kept private, so I haven't seen the latest. In contrast, our spec will be publicly viewable every step of the way, as will the EG mailing list.
    Also, who are some of the major players hinted at? Are they existing Java EE adopters?
    I guess you haven't read the proposal? Guice, Spring, PicoContainer, Tapestry IoC, Plexus, users like James Strachan and Tim Peierls, well known API designers such as Josh Bloch and Doug Lea. To my knowledge, the only dependency injection people behind 299 are from Seam, and this is their first foray into statically-typed DI.
  31. 299 is already inferior to existing configuration approaches. What's worse, it's not clear how a subsequent release of 299 could address its limitations in a clean way.
    Bob, you made this claim here (http://in.relation.to/Bloggers/CommentsOnAnnotationsForDependencyInjection) too and it was very hotly contested, to say the least. You also didn't appear to know very much about JSR299. Furthermore, in your spec (in section 2.6) you explain why your proposal needs are not met by existing specifications, and you reference JSR299 in a completely factually incorrect way (eg: that is depends on EJB and the semantics of its annotations aren't compatible with those of most existing injectors, neither of which are true). Bob, please don't misunderstand my tone. I very much respect all the great work you have contributed to the Java community (ie: I'm a huge fan :)). However, I am trying to reconcile the things you are saying with those that are hotly contesting your statements. Despite all the well respected names you are dropping that are behind this, there are an equal number of well respected people that are very concerned as to why you are completely ignoring JSR299 (and the relevant subset which your spec overlaps). When pressed to explain this, it seems to boil down to "I can't work with Gavin because he's a dictator". Are you kidding me? I'm sorry, but this seems like a very weak reason to ignore his very equally respected work in the DI space. There are a lot of smart people on this EG, not just Gavin and you're telling me that you can't convince any of them that what they are doing is supposedly a bad idea? I am simply trying to understand why there isn't more cooperation and compromise in this very important space which needs standardization. Help me understand, and thanks for your patience in making your case.
  32. You also didn't appear to know very much about JSR299.
    I'm not sure why you would think this. Is this about the "global" comment? I said 299's configuration is global. Gavin said it's not global, it's "per deployment." My applications are typically composed of a single deployment, so it's global so far as I'm concerned. In contrast, Guice enables arbitrarily fine grained and nested compartmentalization.
    eg: that is depends on EJB and the semantics of its annotations aren't compatible with those of most existing injectors, neither of which are true
    The 299 public draft specification says, "This runtime environment is called the container. The container may be a Java EE container or an embeddable EJB Lite container... This specification enhances the EJB component model." While some people have been able to implement 299 sans EJB, I have to wonder if these implementations are actually compatible by JCP standards. Of course, I haven't seen an up-to-date spec; neither 299's spec nor its EG mailing list are open. The annotations are not compatible. Details matter.
    Despite all the well respected names you are dropping that are behind this, there are an equal number of well respected people that are very concerned as to why you are completely ignoring JSR299 (and the relevant subset which your spec overlaps). When pressed to explain this, it seems to boil down to "I can't work with Gavin because he's a dictator". Are you kidding me? I'm sorry, but this seems like a very weak reason to ignore his very equally respected work in the DI space. There are a lot of smart people on this EG, not just Gavin and you're telling me that you can't convince any of them that what they are doing is supposedly a bad idea?
    This JSR has nothing to do with 299. We want to use dependency injection annotations with different configuration approaches, and we have legitimate reasons for doing so. Why should we not be able to do this? You can you still use 299.
    I am simply trying to understand why there isn't more cooperation and compromise in this very important space which needs standardization. Help me understand, and thanks for your patience in making your case.
    The @Inject proposal is full of cooperation and compromise. Also, its EG mailing list and spec will be publicly viewable at all times, as should be the case with such an important spec. Bob
  33. Jeremy,
    you reference JSR299 in a completely factually incorrect way (eg: that is depends on EJB
    I should also point out that while 299 can technically run on Java SE, it has an unmistakable EE-style which SE users find distasteful. For example, 299 forces implementations to proxy concrete classes to support scopes and circular dependencies. I've always ardently opposed creating standalone class proxies, long before 299 came around. If your class has fields, that memory is just wasted. If a class accesses private fields on a different instance (in equals() for example), that class will end up accessing uninitialized data. So, if a user passes in an instance of Foo and I compare it to a scoped instance of Foo, the code will fail. 299 introduces undesirable programming restrictions to support this style of proxying. Like EJB, your class must have a zero-argument constructor. This makes writing immutable types next to impossible or at least much harder; it's hard enough to do to begin with. Using proxies for scoped objects also throws away the meaning of object identity. While my code may be easier to write if I never have to worry about the scopes of objects, that same code is more difficult to read when object identity means nothing and the actual object that's being invoked can change from method invocation to invocation. Our proposal doesn't preclude 299 from supporting this sort of proxying, but it also doesn't force other injectors to support it. Bob
  34. Jeremy,

    you reference JSR299 in a completely factually incorrect way (eg: that is depends on EJB


    I should also point out that while 299 can technically run on Java SE, it has an unmistakable EE-style which SE users find distasteful. For example, 299 forces implementations to proxy concrete classes to support scopes and circular dependencies. I've always ardently opposed creating standalone class proxies, long before 299 came around. If your class has fields, that memory is just wasted. If a class accesses private fields on a different instance (in equals() for example), that class will end up accessing uninitialized data. So, if a user passes in an instance of Foo and I compare it to a scoped instance of Foo, the code will fail. 299 introduces undesirable programming restrictions to support this style of proxying. Like EJB, your class must have a zero-argument constructor. This makes writing immutable types next to impossible or at least much harder; it's hard enough to do to begin with. Using proxies for scoped objects also throws away the meaning of object identity. While my code may be easier to write if I never have to worry about the scopes of objects, that same code is more difficult to read when object identity means nothing and the actual object that's being invoked can change from method invocation to invocation.

    Our proposal doesn't preclude 299 from supporting this sort of proxying, but it also doesn't force other injectors to support it.

    Bob
    Thanks for taking the time to explain this Bob. It really helps me understand where you are coming from.
  35. Re: Announcing @javax.inject.Inject[ Go to top ]

    This just looks like silliness. Why can't we get consistent set of annotations for this? Were the Spring guys not involved in 299? It puts neither Spring nor JBoss in a good light, in my opinion. This is a crucial time for Java, and this kind of uncertainty makes me want to continue using Django and more Python. We'll continue with the JVM, but we'll be using Jython.
  36. In your blog entry, you also said:
    Long term, I think it sucks that we need a DI framework at all. Not all languages do. Technically, we're working around deficiencies in the Java language.
    I won't go into issues of flexibility and maintainability (as mentioned in the JSR proposal), but concerning testability, there are now several toolkits available for Java which allow one to easily write unit tests for any code, independently of such code making liberal use of static, final, or new. With such tools, mocks are not injected, but rather the production code is modified at runtime to redirect "real" method calls to the corresponding mocks. One of these tools is JMockit, which I develop. Another one is PowerMock.
  37. In your blog entry, you also said:

    Long term, I think it sucks that we need a DI framework at all. Not all languages do. Technically, we're working around deficiencies in the Java language.


    I won't go into issues of flexibility and maintainability (as mentioned in the JSR proposal), but concerning testability, there are now several toolkits available for Java which allow one to easily write unit tests for any code, independently of such code making liberal use of static, final, or new. With such tools, mocks are not injected, but rather the production code is modified at runtime to redirect "real" method calls to the corresponding mocks.

    One of these tools is JMockit, which I develop. Another one is PowerMock.
    Easy testability is just one side effect of using dependency injection, but I don't agree that mocking approaches that rely on bytecode rewriting are as easy as simply mocking an interface or overriding a class. Tools like that are nice when you need them though. For one, the compiler can't help you as much. When I talk about needing dependency injection support at the language level, I basically want dependency injection and my constructor arguments to be orthogonal so I can use constructors for run time arguments, not just dependencies.
  38. Easy testability is just one side effect of using dependency injection, but I don't agree that mocking approaches that rely on bytecode rewriting are as easy as simply mocking an interface or overriding a class. Tools like that are nice when you need them though. For one, the compiler can't help you as much.
    Simpler designs and implementations are a side effect of not having to worry about testability. Why should I use a tool that restricts my design choices, when another gives me total freedom, at no extra cost? And apart from the occasional need to access a private method or field, I get the same help from the compiler and IDE as I would get otherwise. In the JSR proposal there are some code snippets about writing tests for a Stopwatch class, with and without DI. I wrote the following JUnit test class which shows a working version for this example, using the JMockit tool. @RunWith(JMockit.class) public class StopWatchTest { static class Stopwatch { private final TimeSource timeSource; private long initialTime; Stopwatch() { timeSource = DefaultTimeSource.getInstance(); } void start() { initialTime = timeSource.getCurrentTime(); } long stop() { return timeSource.getCurrentTime() - initialTime; } } interface TimeSource { long getCurrentTime(); } static final class DefaultTimeSource implements TimeSource { private static final TimeSource INSTANCE = new DefaultTimeSource(); public static TimeSource getInstance() { return INSTANCE; } public long getCurrentTime() { return System.nanoTime(); } } @Test public void testStopwatch() { Stopwatch sw = new Stopwatch(); final long startTime = 20; final long stopTime = 60; new Expectations() { DefaultTimeSource mockTimeSource; { // Expectations: mockTimeSource.getCurrentTime(); returns(startTime); mockTimeSource.getCurrentTime(); returns(stopTime); } }.endRecording(); // Execute code under test: sw.start(); long timeElapsed = sw.stop(); // JUnit asserts (JMockit verifies expectations automatically): assertEquals(stopTime - startTime, timeElapsed); } } What is not easy in this code? (To run in the command line, type C:\Java\jdk1.6.0_13\bin\java -cp C:\Java\jdk1.6.0_13\lib\tools.jar;C:\Java\junit4.6\junit-4.6.jar;jmockit.jar;. org.junit.runner.JUnitCore StopWatchTest, after adapting to your environment.)
  39. I think that's bearable, but I'm sorry, it's still not as straightforward as mocking out an interface. Your argument is that you have to sacrifice your design to make it testable, but I don't buy that. In this example, I prefer for Stopwatch to accept a TimeSource. It makes StopWatch reusable in different contexts. For example, I can use it with the default system time (as you've done), or I could use a TimeSource that provides thread CPU time. I prefer not to write this boilerplate: private static final TimeSource INSTANCE = new DefaultTimeSource(); public static TimeSource getInstance() { return INSTANCE; } Guice makes it so I don't have to. I also like it when the compiler reminds me to mock out dependencies; this way my unit tests don't slow to a crawl because someone introduced a dependency that hits the network and failed to mock it out everywhere. If you watch one of my Guice presentations, you'll also see that a goal is to break compile time dependencies. In your example, Stopwatch has a compile time dependency on the implementation of TimeSource. Guice makes it trivial to break that up without sacrificing any up front checking.
  40. I think that's bearable, but I'm sorry, it's still not as straightforward as mocking out an interface. Your argument is that you have to sacrifice your design to make it testable, but I don't buy that. In this example, I prefer for Stopwatch to accept a TimeSource. It makes StopWatch reusable in different contexts.
    With these new mocking tools, there is really no limitation in how you design your production code. For JMockit, it makes no difference whether interface implementations are externally injected or not. The test class I wrote is just one possible example between many. I could have used "new AtomicClock()", or used DI through a constructor, setter property, or a field. It's all supported.
    For example, I can use it with the default system time (as you've done), or I could use a TimeSource that provides thread CPU time. I prefer not to write this boilerplate:
    private static final TimeSource INSTANCE = new DefaultTimeSource();
    public static TimeSource getInstance() { return INSTANCE; }
    Guice makes it so I don't have to.
    That's fine, the use of DI is perfectly valid in this case. JMockit would create the mock instance for the test, which would then pass it to the Stopwatch class using the constructor.
    I also like it when the compiler reminds me to mock out dependencies; this way my unit tests don't slow to a crawl because someone introduced a dependency that hits the network and failed to mock it out everywhere.
    I am not quite sure I understand what you mean... but I don't think this kind of thing would happen often in practice. If class A depends on B, the unit tests for A normally won't be affected by new dependencies added to B. And new dependencies added to A will usually require a review of the unit tests for A.
    If you watch one of my Guice presentations, you'll also see that a goal is to break compile time dependencies. In your example, Stopwatch has a compile time dependency on the implementation of TimeSource. Guice makes it trivial to break that up without sacrificing any up front checking.
    I watched this presentation, although not the whole thing; maybe now I will have a second look :^) The test I wrote also has a compile time dependency on the DefaultTimeSource implementation, which I agree is not ideal. Currently, if I wrote TimeSource mockTimeSource; instead, JMockit would create an implementation (using java.lang.reflect.Proxy), but would not redefine the actual implementation class loaded by the JVM. Using DI that is not necessary, but without DI it would be... I am going to implement this as a new feature for JMockit 0.98, since it's relativelly simple to do.
  41. What's the difference between this and JSR-299 ?
  42. Why @Inject is a bad idea[ Go to top ]

    Some thoughts on this proposal: http://www.jroller.com/rickard/entry/why_inject_is_a_bad
  43. Some thoughts on this proposal:
    http://www.jroller.com/rickard/entry/why_inject_is_a_bad
    +1
  44. Please JSR299 guys.......[ Go to top ]

    please b flexible.... not all java users are JavaEE users as u or as u want them we all know that you r JBoss guys and u get ur living from this respectable company and as more people stick to the EE standard, the more profit u get , and the more chance to survive u have BUT... please look at the community as a whole, to all java language fans and users around the world several developers are desktop application developers,or framework designers ,they do not need global transactions , AOP , complex lifecycle processing take struts 2 for example they used guice as an IoC container for handling the internal dependencies of the framework they need an IoC container , not transaction , no Aop , very little if any lifecycle management lot of us work this way and want just this functionality WE DO NOT NEED A BLOATED FRAMEWORK ,if we will never use its features you can make 2 profiles for the JSR :- 1- standard profile contains the above 5 annotations and may b some jsr 350 lifecycle annotation 2- Enterprise profile for developing web application and enterprise services in that case u gurentee a consistent API and community we donot need more fragmentation in the java world we r in a critical point in the java history,sun is dissolving , with a new management to the JCP ,and many many challenges facing us these days.... SO please b responsible , and take the community requirements into consideration thanks Joe
  45. About flexibility and maintainability, the JSR proposal has the following text:
    ... a programmer must predict accurately how much flexibility will be needed in the future or else suffer the consequences. If a programmer initially elects to use a constructor but later decides that more flexibility is required, the programmer must replace every call to the constructor.
    True, but this ignores the fact that "replacing every call to the constructor" is actually easy, and doable in a couple of minutes, no matter how many places in the codebase that constructor is called. In the example given in the JSR, if we initially have final TimeSource timeSource = new AtomicClock(); and later want to add flexibility by using a TimeSourceFactory, the following quick steps would be taken, when using IntelliJ IDEA:
    1. Apply the refactoring "Replace constructor with factory method" to one of the places with new AtomicClock().
    2. Create an empty TimeSourceFactory class.
    3. On the factory method created in the first step inside the AtomicClock class, apply the "Move" refactoring in order to move it to the desired TimeSourceFactory class.
    That's it. A similar procedure can be done in Eclipse, I hope.
  46. Non-Controversial?[ Go to top ]

    Hey Bob, Can you at least take the "non-controversial" part out of your message? If you succeed in getting approval to form this JSR, it will cause nothing but controversy and damage to Java EE and do nothing to help unify the platform. I expect nothing less from Rod to try and disrupt the Java EE space and prevent it from evolving as a weak EE strengthens his business, but I thought you and Google were a bit more responsible. If you think that you're not going to have to compromise in many of the same ways you couldn't compromise with Gavin and 299, then you're destined for frustration and your "5 months" will turn into a lot longer. Oh well, don't say I didn't warn you. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  47. Re: Non-Controversial?[ Go to top ]

    Bill, what do you have against this JSR? Java EE applications will be just as portable as when you had 299 only. EE classes will actually be more portable than before since they'll use the same injection annotations as non-299-specific code. The onus is on you to justify why we should put EE in front of the majority of the Java community and prevent everyone else from using these annotations in other contexts. There's no need for all of this drama and territoriality.
  48. Re: Non-Controversial?[ Go to top ]

    Bill, what do you have against this JSR? Java EE applications will be just as portable as when you had 299 only. EE classes will actually be more portable than before since they'll use the same injection annotations as non-299-specific code. The onus is on you to justify why we should put EE in front of the majority of the Java community and prevent everyone else from using these annotations in other contexts. There's no need for all of this drama and territoriality.
    Java EE needs complete IoC now. It needs common integration between the various component models (EJB, JSF, Servlet, JCA, etc.) that has been missing since the specification existed. It needs pluggable and extendible behavior so that it can be a living breathing document. The JSR-299 usergroup has worked *REALLY* hard to provide all this, and IMO, have done an excellent job. As you've said, you worked on it yourself for awhile and many of your ideas and Guice's are reflected in the 299 specification. Also much of Web Beans has existed in Seam for years so its a battle tested technology. I'm sorry you're naive to JCP politics (or even writing specifications for that matter) and don't understand how difficult it is to a) actually want to solve these problems within EE (Sun at first was hoping EE 6 would be a minor maintenance rev of EE 5) b) actually try to do something about it (don't see anybody else trying to solve these fundamental problems in EE) c) that you don't realize how difficult politically it is to get these needed, crucial, fundamental changes into the specification Bob, really, why don't you do your own thing? Why not just do an AOP Alliance-like thing outside of the JCP? If it gets traction, good for you. EE 6 can't wait another year or more for your specification to come to fruition. (People wonder why it takes so long, now they know!) This stuff isn't rocket science. I'm sure that if you really were into being non-controversial you could easily use JSR-299 annotations to implement what you wanted. Or the changes to JSR-299 annotations are probably so minor 299 could probably easily accommodate your wishes. This has nothing to do about being territorial. JBoss's track record speaks for itself. We brought Hibernate to the JCP when it was pretty much a de facto standard on its own. We didn't have to do it. JPA managed to unify the EE platform and we're all the better for it. Seam is pretty much in the same position. We didn't have to bring it to the JCP, yet we did. No, this is about fixing EE and moving the platform forward, breathing new life into it much in the same way EJB 3 and JPA did to EE 5. Trust me, I know Gavin is difficult to work with, but aren't you bigger than that? Then again, I know it would be a good learning experience for you to go through the JSR/JCP process to see that its virtually impossible to avoid compromises and virtually impossible to be autocratic. Can't you see Red hat is pushing 299 because we care about Java EE? That we want to fix it?
  49. Re: Non-Controversial?[ Go to top ]

    Bill,
    Trust me, I know Gavin is difficult to work with, but aren't you bigger than that?
    That's just it. This has nothing to do with Gavin or 299. It's narcissistic to assume otherwise. The DI community needs this spec. While configuration approaches vary widely (XML, plain Java, annotation-based like 299), we all pretty much use the same set of annotations. This spec means users will only have to annotate their classes once and tools will only need to support one set of annotations as opposed to N sets of slightly different, vendor-specific annotations.
    Then again, I know it would be a good learning experience for you to go through the JSR/JCP process to see that its virtually impossible to avoid compromises and virtually impossible to be autocratic
    I've represented Google on the JCP EC for four years now (as Josh Bloch's alternate, I attend every meeting and participate heavily). I know the JCP inside and out as a result. I was on JSR-269 which went into Java 6. I successfully submitted a language change proposal to project Coin and I worked on several others that were also accepted. I'm on JSR-294 (modules are much more contentious than DI, BTW), and I'm contributing heavily to JSR-166. If you knew more about the JCP, you'd know that you can't subset specs and therefore can't just use the annotations from 299. As for taking the AOP Alliance route, that would be silly. What would be the purpose?
    Can't you see Red hat is pushing 299 because we care about Java EE? That we want to fix it?
    Can't you see that we're not precluding JSR-299 in any way? If anything, we're helping it. These annotations are better specified. I'm not sure why you would say I'm naive to writing specifications. This specification is precise and uses BNF grammar notation. The public draft of 299 is example-driven and imprecise. That's naive. Let me be clear. When I criticize 299, I'm not trying to hurt it. We voted yes on your public draft, after all. I'm just responding to ignorant people who try to tell me that 299 should be good enough for all of my needs.
  50. Re: Non-Controversial?[ Go to top ]

    I've been following this discussion for a while and I have to jump in an say that Bob Lee's arguments are really quite convincing. If he's correct that 299 requires that "your class must have a zero-argument constructor" it's a killer argument. I don't understand why there's even an argument about this. Hasn't the Java community learned it's lesson with forcing overweight specs down everyone's throats? Not everything needs to be so complicated. If the @Inject spec is indeed a subset of 299, why fight it? What's the problem? Are 299's supporters afraid that most people really just want this subset making the rest of 299 irrelevant? That's the only motivation that comes to mind and if it's the case, then it only makes 299's case stronger.
  51. no-arg[ Go to top ]

    I agree if JSR299 is indeed forcing crap like no-arg constructor down everyone's throat, i don't want any part of it. I don't want to change my immutable objects to mutable object just because some one at jcp thought it was a good idea. You can have all your fancy and over bloated EE specs, just leave us SE people alone
  52. Re: no-arg[ Go to top ]

    If you can get passed the quadruple negatives in the prose, here's the relevant section of the 299 updated public draft spec:
    5.4.1. Unproxyable bean types Certain legal bean types cannot be proxied by the container: • classes without a non-private constructor with no parameters, • classes which are declared final or have final methods, • primitive types, • and array types. If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, an UnproxyableDependencyException is thrown by the container at deployment time.
  53. Re: no-arg[ Go to top ]

    If you can get passed the quadruple negatives in the prose, here's the relevant section of the 299 updated public draft spec:
    5.4.1. Unproxyable bean types
    Certain legal bean types cannot be proxied by the container:
    • classes without a non-private constructor with no parameters,
    • classes which are declared final or have final methods,
    • primitive types,
    • and array types.
    If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, an UnproxyableDependencyException is thrown by the container at deployment time.
    Is that saying the container must throw this exception or just that it can? If it's just saying that the container can throw this, do you mind connecting the dots for me to see why that causes a problem for containers that don't do proxies?
  54. Re: no-arg[ Go to top ]

    Is that saying the container must throw this exception or just that it can? If it's just saying that the container can throw this, do you mind connecting the dots for me to see why that causes a problem for containers that don't do proxies?
    Proxies are required:
    5.4. Client proxies Clients of a bean with a normal scope, as defined in Section 8.2, “Normal scopes and pseudo-scopes”, do not hold a direct reference to the contextual instance of the bean (the object returned by Bean.create()). Instead, their reference is to a client proxy object. A client proxy implements/extends all bean types of the bean and delegates all method calls to the current instance (as defined in Section 8.2, “Normal scopes and pseudo-scopes”) of the bean.
  55. Re: no-arg[ Go to top ]

    Proxies are required:


    5.4. Client proxies
    Clients of a bean with a normal scope, as defined in Section 8.2, “Normal scopes and pseudo-scopes”, do not hold a direct reference to the contextual instance of the bean (the object returned by Bean.create()). Instead, their reference is to a client proxy object. A client proxy implements/extends all bean types of the bean and delegates all method calls to the current instance (as defined in Section 8.2, “Normal scopes and pseudo-scopes”) of the bean.
    Sorry, I should have just pulled the spec. Thanks. That is dumb. As far as I am concerned, you win the debate. I'm sure I am not alone in thanking you for fighting for this kind of thing. Java needs modular specs. At least there's someone in the Java ecosystem that's fighting for simplicity.
  56. Re: no-arg[ Go to top ]

    That is dumb. As far as I am concerned, you win the debate.

    I'm sure I am not alone in thanking you for fighting for this kind of thing. Java needs modular specs. At least there's someone in the Java ecosystem that's fighting for simplicity.
    To be fair, the main debate here is not over the quality of JSR 299. Rather, the @Inject spec annotations are a subset (semantically) of what's already available in JSR-299. We don't want two sets of these annotations. Either 1) JSR-299 should use these @Inject annotations, or 2) the common ones should be pulled out of JSR-299 negating the need for the @Inject specification altogether. Unfortunately it seems that both of these options are difficult because of timing. Bob's ultimate DI vision for JSE seems to lie ultimately with a solution that is tied into JSR-294. This is very interesting. What is the JSE DI vision of the members of the JSR-299 EG? (I know this is an EE spec currently, but they have ambitions and opinions in this area I am sure?)
  57. Re: no-arg[ Go to top ]

    Rather, the @Inject spec annotations are a subset (semantically) of what's already available in JSR-299.
    Except they're not a subset, which is why I don't think the proposal was meant to be serious. It looks more like an excuse to argue that Guice is better than JSR-299, which is a fine debate, but not a good justification for a new JSR.
  58. Re: no-arg[ Go to top ]

    Scott,
    Except they're not a subset
    Why do you say that? What specifically must change to make them a subset?
  59. JSR-299 binding subset[ Go to top ]

    The subset would be the following annotations: @javax.inject.BindingType @javax.inject.Current @javax.annotation.NonBinding And the interface javax.inject.Instance The bind semantics would be somewhat different from your proposal (basic semantics described below.) Because the scope semantics of JSR-299 are pretty specific, it's not really possible to define common scope annotations. In JSR-299, instances are matched based on the type, and a non-empty set of @BindingType annotations. If the set would be empty, @Current is added automatically. If the injection point's bindings are a matching subset of the bean's declared bindings, the bean matches. The @NonBinding annotation is used to skip comparison of attributes of @BindingType annotations, i.e. @NonBinding works like transient. So, you'd need to do the following:
    • Drop @Inject
    • Rename @Qualifier to @BindingType
    • Add @Current and @NonBinding
    • Rename Produces to Instance
    • Drop @Named
    • And change the binding semantics to match JSR-299
    • You might also need @Specializes to match inheritance semantics, but I haven't implemented that part of the spec yet :)
    It's fine, of course, if people prefer a different binding design, but a common set of annotations would need to have a shared semantics. As I mentioned, I don't think there's a straightforward common scope semantics. It's even possible that scope-related issues might make the subset specification impossible, because the scope details might be incompatible. But at least it would be a more serious proposal.
  60. Re: JSR-299 binding subset[ Go to top ]

    Because the scope semantics of JSR-299 are pretty specific, it's not really possible to define common scope annotations.
    Actually Scott, I don't think its that difficult. Our pseudo-scopes are a pretty close match to the notion of scope in Bob's proposal, and our notion of typesafe resolution is a superset of the functionality proposed by Bob, that gives the same results for the cases which are supported by Bob's proposal. So I do think it is more or less a subset, modulo naming: * @ScopeType = @Scope * @BindingType = @Qualifier * Instance extends Provider * @Singleton is a pseudo-scope * @Named is a binding type
  61. Re: JSR-299 binding subset[ Go to top ]

    Actually Scott, I don't think its that difficult. Our pseudo-scopes are a pretty close match to the notion of scope in Bob's proposal,
    I assumed Bob did not want the proxying behavior for something like @RequestScoped. If he's happy with that, then you're right, the scope could be part of a well-defined subset of JSR-299. My concern would be using the same @ScopeType annotation and have different behavior depending on whether you're in JSR-299 or in Guice. That would defeat the whole purpose of a spec.
    and our notion of typesafe resolution is a superset of the functionality proposed by Bob, that gives the same results for the cases which are supported by Bob's proposal.
    Again, if Bob's happy with implementing the binding semantics of JSR-299, that would be great. I'd be very concerned with partial semantics, because it would be more incompatible and confusing than just accepting two ways of doing DI and letting people choose.
    So I do think it is more or less a subset, modulo naming:
    If its semantics change to JSR-299 for the subset, that's true. In other words, it's like a subgroup in abstract algebra. You can't just take a subset of a group and call it a subgroup, because a subgroup has more structure than a set and needs to match the parent group's structure. Of course, once you have @BindingType and @ScopeType, you may as well add @Produces and @Specializes :)
  62. Re: JSR-299 binding subset[ Go to top ]

    Actually Scott, I don't think its that difficult. Our pseudo-scopes are a pretty close match to the notion of scope in Bob's proposal,


    I assumed Bob did not want the proxying behavior for something like @RequestScoped.
    Right, but his proposal does not have a request scope :-) It only has two scopes: the default (our @Dependent) and @Singleton. They both can easily be treated as 299 pseudo-scopes. @Dependent is already treated that way.
    Of course, once you have @BindingType and @ScopeType, you may as well add @Produces and @Specializes :)
    Yes, in my opinion these annotations are incomplete without @Produces. But the problem is, Bob's proposal (intentionally) doesn't include any facilities for *defining* beans. And that's what @Produces is. IMO, that's just one example of why the strategy of "here's some annotations for doing injection, but we don't give you a way to define what is injectable" is problematic. You lose nice stuff like @Produces.
  63. Re: JSR-299 binding subset[ Go to top ]

    Right, but his proposal does not have a request scope :-)

    It only has two scopes: the default (our @Dependent) and @Singleton.
    But because his @Scope (our @ScopeType) is a meta-annotation, its full behavior would need to be properly defined. If a developer does create a custom scope, it needs to conform to JSR-299 behavior, if the spec is a proper sub-spec. So, the proxying behavior would need to be pulled in, because you can't leave a gap like that in a spec.
    They both can easily be treated as 299 pseudo-scopes.
    Since @Singleton is our @ApplicationScoped, there's no need to introduce a new pseudo-scope, but you're right, his predefined scopes are easy.
    Yes, in my opinion these annotations are incomplete without @Produces.

    But the problem is, Bob's proposal (intentionally) doesn't include any facilities for *defining* beans. And that's what @Produces is.

    IMO, that's just one example of why the strategy of "here's some annotations for doing injection, but we don't give you a way to define what is injectable" is problematic. You lose nice stuff like @Produces.
    True. Technically, though, it could still be a well-defined sub-spec. I'd agree it would be significantly less useful. You would need to require that any use of the annotations conform to JSR-299. So it would be okay not to use the use the annotations, but not okay to use them in incompatible ways.
  64. Re: JSR-299 binding subset[ Go to top ]

    Right, but his proposal does not have a request scope :-)

    It only has two scopes: the default (our @Dependent) and @Singleton.
    But because his @Scope (our @ScopeType) is a meta-annotation, its full behavior would need to be properly defined.
    Well, that's another problem. The JSR proposal contains neither: * a full set of useful portable scopes for the servlet environment, nor * a portable SPI for defining custom scopes. So there is no way to achieve portability for the basic set of scopes that people use every day. If you want that, you need a whole lot more machinery, like we have in 299.
    If a developer does create a custom scope, it needs to conform to JSR-299 behavior, if the spec is a proper sub-spec. So, the proxying behavior would need to be pulled in, because you can't leave a gap like that in a spec.
    No, not necessarily. You could say that in the SE spec only pseudo-scopes are supported, and normal scopes are a 299-specific extension to that. Proxying is something specific to normal scopes, as I keep having to point out to people who are intentionally trying not to appreciate this point. That's why this whole "299 is bad because there are some programming limitations for normal scopes" stuff is essentially nonsense: normal scopes are not the only kind of scopes supported in the 299 model.
    They both can easily be treated as 299 pseudo-scopes.
    Since @Singleton is our @ApplicationScoped, there's no need to introduce a new pseudo-scope, but you're right, his predefined scopes are easy.
    Well, @Singleton does not *have* to be equal to @ApplicatonScoped. We could treat them as different scopes: one a pseudo-scope, the other a normal scope. In fact, that's what I would do. They do, potentially, address subtly different use cases.
    Yes, in my opinion these annotations are incomplete without @Produces.

    But the problem is, Bob's proposal (intentionally) doesn't include any facilities for *defining* beans. And that's what @Produces is.

    IMO, that's just one example of why the strategy of "here's some annotations for doing injection, but we don't give you a way to define what is injectable" is problematic. You lose nice stuff like @Produces.
    True. Technically, though, it could still be a well-defined sub-spec. Exactly, that's what I'm arguing.
    I'd agree it would be significantly less useful.
    Also what I'm saying. It can be a well-defined subset - but the subset is too small to provide any meaningful portability between various containers.
  65. SE DI[ Go to top ]

    What is the JSE DI vision of the members of the JSR-299 EG? (I know this is an EE spec currently, but they have ambitions and opinions in this area I am sure?
    Personally, I would prefer to sit down at the end of this year, figure out a subset of 299 that is applicable to Java SE, and then define a bootstrap API for that. (The subset of 299 that applies to SE is actually pretty obvious.) This would be a *much* more complete DI solution for SE, and would enable truly portable applications. Unfortunately, I don't know how we could go about making this politically feasible. Note that we were not able to address SE injection in this rev of the spec because that was not how our JSR was originally written and approved and because - well, we already had a lot on our plate.
  66. Re: SE DI[ Go to top ]

    By the way, Pete Royle has already explained how easy it is to run the 299 RI in SE here: http://in.relation.to/Bloggers/CommentsOnAnnotationsForDependencyInjection#comment11356 I should also point out that apart from the RI there are already two other implementations of 299, one being Apache Open Web Beans, and the being Resin CanDI, which is based on OSGi and forms the core of their next-generation server. So people are already using 299 to do really cool things beyond what the spec itself says it is for.
  67. Re: SE DI[ Go to top ]

    Hi Gavin why wait for the end of the year? just sit down now and get this subset done and all will b happy i think that u will not b alone thinking, several will help as u can see it is a much needed functionality actually JSR 299 is terrific, it is a perfect spec for ee apps but we REALLY need a non EJB dependent solution thanks Joe
  68. Re: SE DI[ Go to top ]

    Hi Gavin
    why wait for the end of the year?
    just sit down now and get this subset done and all will b happy

    i think that u will not b alone thinking, several will help as u can see it is a much needed functionality
    I would be happy to do that, but seriously, the process issues and politics of that are more complex than you can possibly imagine :-/
    actually JSR 299 is terrific, it is a perfect spec for ee apps but we REALLY need a non EJB dependent solution
    Thanks, but I still claim it's not realy EJB dependent :-) Hell, we went through an incredible amount of pain and negotiations to get this new "managed bean" spec in EE that exists purely so that people can use 299 injection with plain Java classes!
  69. Re: SE DI[ Go to top ]

    Hi Gavin
    why wait for the end of the year?
    just sit down now and get this subset done and all will b happy
    Because Bob's not interested in a subset of JSR-299.
    i think that u will not b alone thinking, several will help as u can see it is a much needed functionality

    actually JSR 299 is terrific, it is a perfect spec for ee apps but we REALLY need a non EJB dependent solution
    JSR-299 doesn't depend on EJB. EJB is a layer on top of JSR 299. The spec could easily be rewritten to put all the EJB layer in an Appendix D.
  70. Re: SE DI[ Go to top ]

    JSR-299 doesn't depend on EJB. EJB is a layer on top of JSR 299. The spec could easily be rewritten to put all the EJB layer in an Appendix D.
    Hehe, yes, that's literally correct. But the spec would never be approved by the JCP if we did that. :-) Anyway, IMO, the ability to inject EJBs is very, very, very, very, very useful :-)
  71. Re: no-arg[ Go to top ]

    Proxies are required:


    5.4. Client proxies
    Clients of a bean with a normal scope, as defined in Section 8.2, “Normal scopes and pseudo-scopes”, do not hold a direct reference to the contextual instance of the bean (the object returned by Bean.create()). Instead, their reference is to a client proxy object. A client proxy implements/extends all bean types of the bean and delegates all method calls to the current instance (as defined in Section 8.2, “Normal scopes and pseudo-scopes”) of the bean.


    Sorry, I should have just pulled the spec.
    Yes you should have. It's not correct that 299 requires zero-argument constructors. And Bob demonstrates his ignorance of 299 by continually claiming that it does. This is what the spec actually says:
    Certain legal bean types cannot be proxied by the container: • classes without a non-private constructor with no parameters, • classes which are declared final or have final methods, • primitive types, • and array types.
    If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, the container automatically detects the problem and treats it as a deployment problem
    First of all, "normal scope" has a very particular technical definition in 299. In particular, the default scope in both 299 and in Guice is *not* a normal scope (it is a "pseudo-scope") and therefore this restriction does not apply at all. Secondly, the restriction applies only to the type declared at the injection point. It is not a restriction upon the implementation object at all! All it boils down to is that if the implementation has a "normal scope", for example the session scope, then you have to either: * use an interface type at the injection point, or * give the implementation a default constructor There are lots of VERY subtle issues surrounding this, which I don't have time to explain right here, and Bob is doing the community a huge disservice by oversimplifying and misrepresenting the issue and what 299 says about it. Everybody, please read the goddamn spec before jumping to conclusions!
  72. Re: no-arg[ Go to top ]

    A client proxy implements/extends all bean types of the bean
    Actually this is a mis-print in the spec. The client proxy does not need to extend *all* bean types of the bean. I need to fix that. The word "all" should not be there.
  73. Re: no-arg[ Go to top ]

    Gavin,
    It's not correct that 299 requires zero-argument constructors. And Bob demonstrates his ignorance of 299 by continually claiming that it does.
    Please cut out the personal attacks. It is correct that 299 requires a no-argument constructor if you depend on a scoped class. I said, "299 forces implementations to proxy concrete classes to support scopes and circular dependencies." Bob
  74. Re: no-arg[ Go to top ]

    Gavin,

    It's not correct that 299 requires zero-argument constructors. And Bob demonstrates his ignorance of 299 by continually claiming that it does.


    Please cut out the personal attacks. It is correct that 299 requires a no-argument constructor if you depend on a scoped class. I said, "299 forces implementations to proxy concrete classes to support scopes and circular dependencies."

    Bob
    No it is not correct Bob. Your statement was literally false. Yes there are certain cases where a default constructor is called for, but not in all the cases that you claimed. Again: 299 does *not* always require a default constructor for a scoped class. (1) If the class has a pseudo scope (which is the default), the default constructor is not required. (2) If you are referring to the class by an interface at the injection point, the default constructor is not required. Now, since 299 has an extensible context model, you can implement your own pseudo-scopes for it, and get *exactly* the semantics of Guice. OTOH, if you use the built-in scopes, you have to comply with a couple of extra restrictions, but a lot of problems will be taken care of for you: * circular dependencies in constructor injection * references from objects in serializable scopes to unserializable objects in other scopes * references from wider scopes to narrower scopes Without the special restrictions that apply to normal scopes, you would need to solve all these problems yourself.
  75. Re: no-arg[ Go to top ]

    Let me put this another way. What does *Guice* do if I have: (1) a circular dependency when we are using constructor injection? (2) an injected reference from a session-scoped bean to an un-serializable application-scoped bean? (3) an injected reference from a conversation-scoped bean to a request scoped bean? After answering these questions, are you still going to try and tell me that Guice poses no programming restrictions on scoped objects?
  76. Re: no-arg[ Go to top ]

    It is correct that 299 requires a no-argument constructor if you depend on a scoped class.
    No it is not correct Bob. Your statement was literally false. Yes there are certain cases where a default constructor is called for, but not in all the cases that you claimed.

    Again: 299 does *not* always require a default constructor for a scoped class.

    (1) If the class has a pseudo scope (which is the default), the default constructor is not required.
    When I say "scoped", I mean session scoped, request scoped, etc. If I meant pseudo-scoped, I would say pseudo-scoped.
    (2) If you are referring to the class by an interface at the injection point, the default constructor is not required.
    An interface is not a class. I said, scoped class.
    * references from objects in serializable scopes to unserializable objects in other scopes
    Serializing the proxy but not the underlying state sounds confusing. We use static injection in these cases. It's not ideal, but I do think it has the best tradeoffs.
    * references from wider scopes to narrower scopes
    I already said that I think throwing away object identity makes code more difficult to understand.
    Let me put this another way. What does *Guice* do if I have: (1) a circular dependency when we are using constructor injection?
    Guice will currently proxy interfaces, but we consider this a bug. It shouldn't proxy at all. It's highly likely that the user doesn't know the circular reference exists; the injector should notify the user, not try to guess what the user wants. To get around the error, the user could inject Provider instead of Foo at one injection point. Proxying might be the right choice for 299, but Guice prefers to be more conservative.
    (2) an injected reference from a session-scoped bean to an un-serializable application-scoped bean?
    I'd use static injection. This is a little easier for 299 right now because you assume you only have one container per deployment unit. You can have any number of injectors in a Guice application. You would need to tell the proxy which injector to use, presumably by setting a thread local injector during deserialization. There's also the issue of serializing the proxy but not the actual state. This is confusing and the proxy adds unnecessary cruft to the serialized state. While serializing proxies might be the right choice for 299, I think static injection is the right choice for Guice.
    (3) an injected reference from a conversation-scoped bean to a request scoped bean?
    The injector should generate an error at which point the the user should inject Provider instead. While a proxy might be the right choice for 299, I don't like it when a proxy dynamically looks up a backing object on each method invocation. I think object identity is useful for understanding code. If you provide some example code, I can demonstrate that the code would actually be easier to understand if you didn't proxy.
    After answering these questions, are you still going to try and tell me that Guice poses no programming restrictions on scoped objects?
    No more than plain Java, no. Guice encourages immutable types and good API designs.
    Note that we were not able to address SE injection in this rev of the spec because that was not how our JSR was originally written and approved and because - well, we already had a lot on our plate.
    You renamed your spec from "Web Beans" to "Java Contexts and Dependency Injection" and you're worried about scope creep? ;-)
    IMO, that's just one example of why the strategy of "here's some annotations for doing injection, but we don't give you a way to define what is injectable" is problematic. You lose nice stuff like @Produces
    299 can and still should define @Produces (though I would rename it to @Provides; provider methods don't always produce something). 299 isn't really the issue here though. Why do you want to prevent us from using these annotations independently of 299? This proposal precludes 299 in no way. Don't worry about the timeline; we've talked with Sun and can accommodate EE 6's time frame.
  77. Re: no-arg[ Go to top ]

    It is correct that 299 requires a no-argument constructor if you depend on a scoped class.
    No it is not correct Bob. Your statement was literally false. Yes there are certain cases where a default constructor is called for, but not in all the cases that you claimed.
    Again: 299 does *not* always require a default constructor for a scoped class.
    (1) If the class has a pseudo scope (which is the default), the default constructor is not required.
    When I say "scoped", I mean session scoped, request scoped, etc.
    You can define a session or request pseudo scope. 299 has an extensible scope model, as I'm sure you are aware.
    (2) If you are referring to the class by an interface at the injection point, the default constructor is not required.
    An interface is not a class.
    But a class can have an interface. You're trying to rationalize what you wrote after the fact, but if you look at what everyone else interpreted it to mean, they did not interpret it to mean what you now claim it means.
    * references from objects in serializable scopes to unserializable objects in other scopes


    Serializing the proxy but not the underlying state sounds confusing. We use static injection in these cases. It's not ideal, but I do think it has the best tradeoffs.
    Oh, so there are tradeoffs, really?! From your original post it did not sound like we were discussing a complex issue with various *tradeoffs*! It sounded like 299 was doing something obviously stupid! "Sounds confusing": Why? Not confusing to me. 299 handles it elegantly.
    Let me put this another way. What does *Guice* do if I have:

    (1) a circular dependency when we are using constructor injection?
    Guice will currently proxy interfaces, but we consider this a bug.
    OMG, so what Guice *actually does in practice* is what 299 defines! Is this another "tradeoff"?
    It shouldn't proxy at all. It's highly likely that the user doesn't know the circular reference exists; the injector should notify the user, not try to guess what the user wants.
    This sounds *extremely* non-obvious to me. In fact, it sounds wrong.
    To get around the error, the user could inject Provider instead of Foo at one injection point.
    Ah, so a *different* programming restriction. But still a programming restriction.
    Proxying might be the right choice for 299, but Guice prefers to be more conservative.
    "Tradeoffs" again, huh? "prefers": might other people "prefer" a different behavior?
    While serializing proxies might be the right choice for 299, I think static injection is the right choice for Guice.
    Yes, it's a "tradeoff".
    (3) an injected reference from a conversation-scoped bean to a request scoped bean?
    The injector should generate an error at which point the the user should inject Provider instead. While a proxy might be the right choice for 299, I don't like it when a proxy dynamically looks up a backing object on each method invocation.
    "should", "I don't like": another case of "prefer"? Another "tradeoff"?
    You renamed your spec from "Web Beans" to "Java Contexts and Dependency Injection" and you're worried about scope creep? ;-)
    I was asked to do this. I still prefer "Web Beans".
    Don't worry about the timeline; we've talked with Sun and can accommodate EE 6's time frame.
    Why, because you're expecting the EG to hand you a rubber stamp? Sounds like enough people in the community have concerns about this JSR that a rubber stamp is not appropriate.
  78. Re: no-arg[ Go to top ]

    P.S. Bob, I don't want to be too rude here, it's just that when you denounce a programming restriction that we added to 299 after fully considering the complex set of tradeoffs involved, without: (a) properly explaining what the restriction is, nor (b) explaining the tradeoffs involved, nor even what the restriction is for, nor (c) explaining the (different) restrictions that *your* preferred solution involves, then I don't think readers are being fairly informed of the situation. It comes off more like FUD.
  79. Re: Non-Controversial?[ Go to top ]

    Are 299's supporters afraid that most people really just want this subset making the rest of 299 irrelevant? That's the only motivation that comes to mind and if it's the case, then it only makes 299's case stronger.
    Sorry for any confusion, that should be "then it only makes 299's case weaker.
  80. On JCP and Stuff[ Go to top ]

    (disclaimer to avoid the RR:s Java EE article-dilemma: I have contributed small amounts of code the Web Beans and Seam projects) The problem with the JCP is that a JSR has to have a spec lead with the ultimate power in what is produced, imagine what happened if everyone could join but nothing could be signed off unless all members of the EG would agree on everything? So what we have left is a process that stakeholders won't joint because it would appear as if they have supported it even if they don't get all their wishes fulfilled. And when they don't join (or there are too many strong personalities in the EG) we get an outcry of "not fair" and "one man show". The JCP is a highly political arena and denying that is silly but what are the alernatives? I find it strange that proponents if this new JSR candidate highlight how non-controversial it is and it should be judged on technical merit only and in the same breath spread FUD like "oh, they are changing that in the last minute, do they even know what they are doing"? And that famous "deleted post" in in.relation.to that pretty much ended the conversation over there was everything but technical in nature but it's no longer there for viewing so I'll leave it at that. I think that most people agree that injection needs a standard but I think the timing is unfortunate and unless merged with 299 will only cause confusion. Sort of like standarding @java.Magic so that when you write some magic in your code you can easily migrate it to other places just by moving the annotation. Everyone uses magic anyway, it's time to standardize it! We all deserve magic! ;-) I hope we can find a solution that works out since the more we fight amongst ourselves, the more the .NET:ers and others thrive.
  81. Bob, will you bring in Google-Guice as the reference implementation?
  82. Frank,
    Bob, will you bring in Google-Guice as the reference implementation?
    I'm not sure. Guice, Spring and several other frameworks will support this spec right away, so we'll have no shortage of implementations to choose from. I don't care which one we choose. TMK, the only purpose of an RI is to prove that your spec is implementable. You certainly shouldn't rely on an RI to better understand the spec; the spec should stand on its own. Bob
  83. Re: Announcing @javax.inject.Inject[ Go to top ]

    Hey guys, I was just discussing dependency injection portability with a colleague the other day. It would be great to see standard DI annotations for both Java SE and EE. Bob and Gavin, you are two of the smartest guys in the industry and the Java community owes you a lot for your contributions. Please everyone remember to be polite with one another. Let's try to use this site for intellectual discussions and as a forum for creative thinking and consensus building. Ian
  84. JBOSSY[ Go to top ]

    Please everyone remember to be polite with one another. Let's try to use this site for intellectual discussions and as a forum for creative thinking and consensus building.

    Ian
    Come on Ian, I think you are a bit naive on this, They are JBOSSY. Whoever enters their territory, you deserve the insult. You can only do things in JBOSS's way with no exception and that's the reason why JPA instead of JDO in EJB3. EJB3.1 and 299 are great stuffs, however, it just comes too late. Most of the systems in production nowadays don't use EJBs and it's a good idea to have and DI embedded in the JDK. I don't understand why JBoss considers this as threat, it is indeed a good opportunity to end the spring's era.