[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by Martin Andersson (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
Martin Andersson commented on CDI-565:
--------------------------------------
I'm not sure I fully understood you on that "dropping behavior"-thing. NPE:s is kind of what I try to advertise here =)
{{null}} is and will always be a valid candidate to represent the absence, or lack of, a value. *YES*, we all agree that it is easy to misuse {{null}} and {{null}} should be avoided if we so can. My point is definitely not that {{null}} is a god sent gift. Please reread my comments and see if you can answer the questions I asked, for example, what is the difference between {{Map}} and the CDI container (when it comes to dependency lookup)? Also compare {{EntityManager.find()}} from the JPA specification which I believe is another comparable interface.
Everything is an API. I don't understand this notion really or how it relates to the topic of discussion. I googled the CDI specification, {{null}} return values are used everywhere. Would you like to advocate that we setup tens of new exception types into our type system instead?
Speaking of API:s, I would appreciate an {{Optional}} return type from a service only if it is conceivable and often enough the case that no return value is present. For example: {{tryCatchAFish()}}, {{getLotteryWinner()}}. Or, if it is conceivably so that the client doesn't bother about the presence of the value, he's sole intent is to pass it around somewhere. For example: {{myDataSource.getSomeData().ifPresent(someValueContainer::setThatField)}}. I myself overused {{Optional}} once it was out in JDK 8, singing praise to Jesus every minute of the day. Only to discover that my overuse of it introduced complex boilerplate code. Eventually I got so lazy that I dereferenced those optionals anyway ({{Optional.get().doSomething()}} and so it was only a matter of time before I found myself back in square one. But this time, not only did I have NPE:s, all my clients had to make an extra method call all over the place for no apparent gain. More than anything else, I learnt by my own mistake that if a parameter is optional for the client, then accept {{null}}. Don't force the clients to type {{Optional.empty()}} instead of the oh so simple blueish keyword {{null}}. Null as parameters make the life easier for the implementations too.
Also, if you know a "modern language" that had any success avoiding {{null}}, please let me know. That would be interesting. For example, how would I create a new 10 element array? Am I required to have all ten elements right of the bat?
Guys, what is the most intuitive thing to do here? Why do you believe that the dependency lookup should have different semantics than {{Map.get()}}?
> 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)
8 years, 6 months
[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt edited comment on CDI-565 at 10/7/15 11:41 AM:
--------------------------------------------------------------
Though this suggestion might not break backward compability with regards to runtime, it would break with the existing expectations of CDI users. Currently CDI implementations assert injection point validation during startup. Dropping this behavior will possible introduce some nice NPE in the future.
I was not aware there is a part of the java community advocating in favor of null values as part of api contracts, as modern typed languages i know of managed to handle nullable types different than java to avoid NPEs at all.
Long story short: +1 for extending either {{Provider}} or {{Instance}}.
was (Author: tzwoenn):
Though this suggestion might not break backward compability with regards to runtime, it would break with the existing expectations of CDI users. Currently CDI implementations assert injection point validation during startup. Dropping this behavior will possible introduce some nice NPE in the future.
I was not aware there is a part of the java community advocating in favor of null values as part of api contracts, as modern typed languages i know of managed to avoid NPEs at all.
Long story short: +1 for extending either {{Provider}} or {{Instance}}.
> 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)
8 years, 6 months
[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt commented on CDI-565:
------------------------------------
Though this suggestion might not break backward compability with regards to runtime, it would break with the existing expectations of CDI users. Currently CDI implementations assert injection point validation during startup. Dropping this behavior will possible introduce some nice NPE in the future.
I was not aware there is a part of the java community advocating in favor of null values as part of api contracts, as modern typed languages i know of managed to avoid NPEs at all.
Long story short: +1 for extending either {{Provider}} or {{Instance}}.
> 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)
8 years, 6 months
[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by Martin Andersson (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
Martin Andersson commented on CDI-565:
--------------------------------------
Or {{java.util.Optional}} since JDK 8.
Yeah, I think we all agree that the ideal world make a minimal use of {{null}}. But I sure don't think we can ever manage without {{null}}. In fact, {{null}} has some really good use cases. What would you think if {{Map.get(Object)}} threw an exception instead of returning {{null}} when the mapping doesn't exist? Well, the CDI container is one huge map. I ask for a mapped value given a set of types and/or qualifiers - the keys. What is the difference? Even if you do think {{null}} is absolute evil, then it is with us already for better or worse. Convenience, or what we together believe is the most intuitive approach, has to take precedence.
Fail-fast is a good practice, but having it implemented just because one can may be a brutal way of enforcing dogma upon others. I see this "fail-fast" approach as both braking intuition and reducing the service offer. I'm not saying I am right. I am trying to find out why some of us developers has to pay the price, for what benefit, for what gain?
You say it "helps developers" by "avoiding surprising NPE:s at runtime". All exceptions not handled is a surprise, whether that happens during deployment or runtime. But let me point out that if anything is a surprise, then it is the exception types CDI define and all vendor-specific messages the application servers output in the log file, and you know I am right on this point. New developers in particular will have to walk though a lot of struggles until they have a solid understanding of the CDI vocabulary like "ambiguous" and "unsatisified". Compare that with a a {{java.lang.NullPointerException}} in the log file with a clear stack trace to the exact source code line where the reference was dereferenced. What a NPE is and how to deal with it is probably what all new developers learn on their very first day.
Non-developers like to praise programmers as being some kind of super humans. What I often find myself saying in response to my friends, and experiences I think you share with me, is that I am lazy. I am not really a problem solver. I am not really smart. I'm trying to find the best architecture such that the design can do the thinking for me. I am trying to reduce complexity, trying to simplify and automate everything. Most importantly, I will not try to fix a problem before I have one. And that is super important. By trying to fix a problem before I have it, I might end up introducing one instead. Been there done that many times over. Recognize the situation? That's why we are having this discussion. "Premature optimization is the root of all evil" and ya'll know it =) Least you can do is {{@Optional}}.
> 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)
8 years, 6 months
[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-565:
----------------------------------
Ok, there is a lot of discussions about {{null}} and its usefulness. Some people even think it's a bad practice and that's why {{com.google.common.base.Optional}} and friends exist. But that's not the point here. I think the validation of dependencies during deployment (and fail fast) is a great feature which helps most of the developers most of the time (mostly to avoid surprising NPEs in the runtime). In other words, having an unsatisfied dependency which is OK is not a typical use case. It's more like an exception or corner case. And that's why "simple" {{Instance}} API exists.
> 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)
8 years, 6 months
[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by Martin Andersson (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
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)
8 years, 6 months
[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by Martin Andersson (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
Martin Andersson commented on CDI-565:
--------------------------------------
erm, now that I think of it. Changing the behavior such that {{null}} is injected instead of having the deployment crash isn't breaking backward compatibility. All old applications deployed has obviously resolved all their unsatisfied dependencies, right? Question is what type of behavior do we want to see for future applications (deployments)?
I have talked to several Java developers at this point. They all agree with my comments made about {{null}} earlier. The most intuitive thing is to inject {{null}}, leaving the application a fair chance to actually manage this situation which provingly, is a good feature to have from time to time without complex workarounds using "guru" API:s like {{Instance}}.
To turn things around, which issue are we trying to solve, or how exactly are we trying to "help" developers by failing the deployment for unsatisfied dependencies? I can only see the down sides of this behavior. If we know what's right, then as men (and women for some of us!), we are obliged to do the right thing without paying attention to the "fear of change". I cannot stress enough that Java EE is a complex technology stack and if we are to stand a chance in a competitive environment, we have to stop looking for quick fixes and workarounds.
Isn't it possible to cast a vote on the JBoss forum or something, asking people that don't already know the answer, what they think should happen to an unsatisfied dependency? That is what I asked my developers. All but one new guy said {{null}}.
> 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)
8 years, 6 months
[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by Thomas Andraschko (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
Thomas Andraschko commented on CDI-565:
---------------------------------------
Yeah, thats a possible way but via something like @Optional, it would be MUCH EASIER for the enduser!
> 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)
8 years, 6 months