[cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?

[Martin Andersson (JIRA)]

    [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115580#comment-13115580 ] 

Martin Andersson commented on CDI-565:
--------------------------------------

What do we expect to happen here:

{code}
Person person = new Person();
String name = person.getName();
{code}

Yeah, only a problem if we try to dereference the name! =) CDI is one huge "getter". No difference. Most if not all getter methods we write every day return {{null}} and let the client deal with it. If the client require a value and rather have his application blow up with a more specialized exception, then he probably call a more niche method:

{code}
String name = person.requireName();
{code}

I.e, here's what I believe we should do if and only if we want the deployment to fail:

{code}
@Inject
@Required
String name;
{code}

Or maybe even more straight forward:

{code}
@Inject
@DeploymentRequired
String name;
{code}

This way, we can even configure a bit how we want the deployment to fail:

{code}
@Inject
@Required(throwClass=MySuperAwesomeException.class)
String name;
{code}

This "issue" really comes down to what we think is the most intuitive behavior and, whether or not it really brake backward compatbility and if so, how bad would that actually be. I believe 1) {{null}} is the most intuitive thing to do here and it is a good thing leaving the application to deal with it. 2) We don't brake backward compatibility at all. Let me know what you think.

> Unsatisfied dependency should be null?
> --------------------------------------
>
>                 Key: CDI-565
>                 URL: https://issues.jboss.org/browse/CDI-565
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>            Reporter: Martin Andersson
>
> What if I am writing a component that call a collaborator only if that class exist during runtime? It is amazingly intuitive to write code like this:
> {code:java}
> class MyComponent
> {
>     @Inject
>     SomeCollaborator collaborator;
>     public void someMethod() {
>         // .. do something
>         if (collaborator != null) {
>             collaborator.callback();
>         }
>     }
> }
> {code}
> But the specification currently says in section "5.2.2. Unsatisfied and ambiguous dependencies" that this code should cause a "deployment problem". IIRC, GlassFish 4.1 and WildFly 9 doesn't actually crash during deployment. They will inject {{null}}. WebLogic 12, I just learned, do crash during deployment.
> I believe it is unfortunate to have this null value logic for no apparent reason. It is inevitably so that the application code would crash anyways as soon as it tries to dereference a null reference. And you probably agree with me that there's a general guideline established in the developer community which say you shouldn't do null pointer checks all over the code because null pointers will crash exactly when and where the absence of a value really is a problem.
> The work around is to inject an {{Instance}} of my type and iterate through all of them, or do any other form of programmatic lookup. However, me personally, I've had this requirement far too many times now. It is often the case that a component I write has a "subframework" in place such that when I want to affect how the application performs, I can just add in new classes of a particular type and it is scoped up. Please don't even make the notion of a design smell out of your own lack of creativity, if you want to see a concrete example then of course I am more than happy to provide you with that. Just saying =)
> Something so intuitive and present in our every day coding life as a "null return value" should be present in the CDI specification too. I mean that is what the specification in essence is; one huge {{lookupInstanceOf(class)}}-method. Reading this method name, would you really expect it to crash, or return {{null}}?
> How about adding in a new annotation such that the injection point accept null values for unsatisfied dependencies, but if the injection point has an annotation {{@Required}}, then an unsatisfied dependency do crash for this injection point?
> You will probably say "let's do it the other way around so that we don't brake backward compatibility" by creating an {{@Optional}} annotation. Hey, if I am abusive to my wife and she divorce me. Should I continue to be abusive to my next wife so that I don't break backward compatibility? Our number one goal should be to define the most awesome specification and API possible - nothing else. If we keep leaving small piles of poo everywhere, then we will inevitably end up deep in shit.
> Thank you all for your hard work and time devoted to making all of our lives so much greater.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)