[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:
----------------------------------
[~atijms] Do you mean {{java.util.Optional}}? It's final and not serializable. So you can't use it for passivating scopes.
> 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, 7 months
[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
arjan tijms commented on CDI-565:
---------------------------------
Just one other option to take into account; next to {{Instance<T>}}, what about {{Optional<T>}}?
That would more or less function like {{Instance}} does today, but with the difference that it would only provide 0 or 1 instances. If more than 1 bean would eligible it's ambiguous and the familiar exception would be thrown during deployment. {{Optional<T>}} may also be more familiar to developers (eventually when JDK 8 is more used), and has a somewhat easier syntax.
Perhaps needless to say but programmatically using the bean manager API the 0 or 1 is of course already possible. We use something like this in OmniSecurity with this admittedly not superbly coded [getReferenceOrNull|https://github.com/omnifaces/omnisecurity/blob/master/...] method.
> 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, 7 months
[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-565:
---------------------------------
I think the suggestion is to change the DeploymentException to NullPointerException during runtime. I would rather my application is not starting rather than failing with NPE during runtime. In this way, if my application starts, I know it will behave correctly rather than half cooked. I am not a fun of NullPointerException. I cannot see the real issue of this, rather than changing Instance<> to @Inject @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, 7 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 edited comment on CDI-565 at 10/9/15 9:39 AM:
---------------------------------------------------------------
Emily, good to have you here. You wrote:
{quote}
.. optional injection forces the end users to check for null, which is boilerplate code in most scenarios and confusing.
{quote}
I must say that this statement is just wrong. The user doesn't have to do anything. With the proposed change, all CDI applications remain the same. We are talking about trading a "premature" CDI specific exception type, {{DeploymentException}} for the more specialized and well known {{NullPointerException}} during runtime. The fallacy in the CDI specification is that it treat an unsatisfied dependency as a problem. Section "5.2.2. Unsatisfied and ambiguous dependencies"
{quote}
If an unsatisfied .. dependency exists, the container automatically detects the problem and treats it as a deployment problem.
{quote}
But we know an unsatisfied dependency cannot always be treated as a problem. Contrary to what you stated, I had hoped all experienced Java developers abide to the principle of not writing "paranoid" null checks all over the code unless null is expected. Because +if+ and +when+ null is a problem, we will face a NPE exactly +where+ that problem surface. In a sense, nothing could ever be more clear or easily debugged and understood. If you don't agree with me, please share your thoughts. Until then, I say that checking for null, which is what all CDI implementations currently do, is the boilerplate code. It saddens me that they are enforced to act in this way with quite possibly the only result achieved being a reduced feature set offered to the application developer.
Today, when the application want to have an optional dependency, then he has to write, yeah that's right: *boilerplate code*.. to circumvent the normal lookup mechanism and take the route through {{Instance}} which is not the first API most people learn about. Even more so, {{Instance}} will provide you with all the available injection targets. If your application only expected one to be present, any more than so would be ambiguous, then the application has to add it's own {{@PostContruct}} method that crash bean initialization if more than just one target was found. Compare all this *boilerplate code* to the simple use of one annotation {{@Inject}} which automatically, and with all right, treat many targets of the same kind being ambiguous.
So if this proposition goes through, the "intuitive" approach would enrich CDI:s service offer and vastly reduce boilerplate code that all those applications in need of optional dependencies has to write. Like any other normal Java application, those that do require their dependency to be present will face the world's most known exception type: NPE. I say we reach out a hand to them by introducing the {{@Required}} annotation. Today, I believe that in this context, CDI work in an unintuitive way only to destroy its own usability and API simplicity. Again, the real question for us to answer, or vote on, is what the most intuitive approach is. If the most intuitive approach break backward compatibility, then the change has to wait to the next major release. Me personally, I would also like someone to give their view as to why CDI:s injection mechanism is semantically different from {{Map.get()}}?
was (Author: martin.andersson):
Emily, good to have you here. You wrote:
{quote}
.. optional injection forces the end users to check for null, which is boilerplate code in most scenarios and confusing.
{quote}
I must say that is just wrong. The user doesn't have to do anything. With the proposed change, all CDI applications remain the same. We are talking about trading a "premature" CDI specific exception type, {{DeploymentException}} for the more specialized and well known {{NullPointerException}} during runtime. The fallacy in the CDI specification is that it treat an unsatisfied dependency as a problem. Section "5.2.2. Unsatisfied and ambiguous dependencies"
{quote}
If an unsatisfied .. dependency exists, the container automatically detects the problem and treats it as a deployment problem.
{quote}
But we know an unsatisfied dependency cannot always be treated as a problem. Contrary to what you stated, I had hoped all experienced Java developers abide to the principle of not writing "paranoid" null checks all over the code unless null is expected. Because +if+ and +when+ null is a problem, we will face a NPE exactly +where+ that problem surface. In a sense, nothing could ever be more clear or easily debugged and understood. If you don't agree with me, please share your thoughts. Until then, I say that checking for null, which is what all CDI implementations currently do, is the boilerplate code. It saddens me that they are enforced to act in this way with quite possibly the only result achieved being a reduced feature set offered to the application developer.
Today, when the application want to have an optional dependency, then he has to write, yeah that's right: *boilerplate code*.. to circumvent the normal lookup mechanism and take the route through {{Instance}} which is not the first API most people learn about. Even more so, {{Instance}} will provide you with all the available injection targets. If your application only expected one to be present, any more than so would be ambiguous, then the application has to add it's own {{@PostContruct}} method that crash bean initialization if more than just one target was found. Compare all this *boilerplate code* to the simple use of one annotation {{@Inject}} which automatically, and with all right, treat many targets of the same kind being ambiguous.
So if this proposition goes through, the "intuitive" approach would enrich CDI:s service offer and vastly reduce boilerplate code that all those applications in need of optional dependencies has to write. Like any other normal Java application, those that do require their dependency to be present will face the world's most known exception type: NPE. I say we reach out a hand to them by introducing the {{@Required}} annotation. Today, I believe that in this context, CDI work in an unintuitive way only to destroy its own usability and API simplicity. Again, the real question for us to answer, or vote on, is what the most intuitive approach is. If the most intuitive approach break backward compatibility, then the change has to wait to the next major release. Me personally, I would also like someone to give their view as to why CDI:s injection mechanism is semantically different from {{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, 7 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:
--------------------------------------
Emily, good to have you here. You wrote:
{quote}
.. optional injection forces the end users to check for null, which is boilerplate code in most scenarios and confusing.
{quote}
I must say that is just wrong. The user doesn't have to do anything. With the proposed change, all CDI applications remain the same. We are talking about trading a "premature" CDI specific exception type, {{DeploymentException}} for the more specialized and well known {{NullPointerException}} during runtime. The fallacy in the CDI specification is that it treat an unsatisfied dependency as a problem. Section "5.2.2. Unsatisfied and ambiguous dependencies"
{quote}
If an unsatisfied .. dependency exists, the container automatically detects the problem and treats it as a deployment problem.
{quote}
But we know an unsatisfied dependency cannot always be treated as a problem. Contrary to what you stated, I had hoped all experienced Java developers abide to the principle of not writing "paranoid" null checks all over the code unless null is expected. Because +if+ and +when+ null is a problem, we will face a NPE exactly +where+ that problem surface. In a sense, nothing could ever be more clear or easily debugged and understood. If you don't agree with me, please share your thoughts. Until then, I say that checking for null, which is what all CDI implementations currently do, is the boilerplate code. It saddens me that they are enforced to act in this way with quite possibly the only result achieved being a reduced feature set offered to the application developer.
Today, when the application want to have an optional dependency, then he has to write, yeah that's right: *boilerplate code*.. to circumvent the normal lookup mechanism and take the route through {{Instance}} which is not the first API most people learn about. Even more so, {{Instance}} will provide you with all the available injection targets. If your application only expected one to be present, any more than so would be ambiguous, then the application has to add it's own {{@PostContruct}} method that crash bean initialization if more than just one target was found. Compare all this *boilerplate code* to the simple use of one annotation {{@Inject}} which automatically, and with all right, treat many targets of the same kind being ambiguous.
So if this proposition goes through, the "intuitive" approach would enrich CDI:s service offer and vastly reduce boilerplate code that all those applications in need of optional dependencies has to write. Like any other normal Java application, those that do require their dependency to be present will face the world's most known exception type: NPE. I say we reach out a hand to them by introducing the {{@Required}} annotation. Today, I believe that in this context, CDI work in an unintuitive way only to destroy its own usability and API simplicity. Again, the real question for us to answer, or vote on, is what the most intuitive approach is. If the most intuitive approach break backward compatibility, then the change has to wait to the next major release. Me personally, I would also like someone to give their view as to why CDI:s injection mechanism is semantically different from {{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, 7 months
HttpSession failover from cdi 1.0 impl to cdi 1.2 impl
by Emily Jiang
I am investigating the HttpSession failover for SessionScoped or
ConversationScoped beans. I think it is not easy to failover from the CDI
1.0 impl to CDI1.2 impl, as the bean proxies instead of the raw bean was
serialised and the proxies are different between cdi 1.0 and cdi 1.2. Has
anyone have any thoughts on this? If not possible, this is a big limitation
for CDI as EJB container has no such limitation.
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
8 years, 7 months
[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-565:
---------------------------------
+1 for not breaking backward compatibility. Introducing the optional injection forces the end users to check for null, which is boilerplate code in most scenarios and confusing.
+1 for using Instance to cater for the optional injection is the right way to go.
> 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, 7 months
[JBoss JIRA] (CDI-433) AdminEvent example has redundant qualifiers.
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-433?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-433:
---------------------------------
https://github.com/cdi-spec/cdi/pull/260
> AdminEvent example has redundant qualifiers.
> --------------------------------------------
>
> Key: CDI-433
> URL: https://issues.jboss.org/browse/CDI-433
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: John Ament
> Priority: Minor
>
> In the CDI 1.2 spec, the following text appears:
> For example, this injected Event has specified type LoggedInEvent and specified qualifier @Admin:
> {{@Inject @Admin Event<LoggedInEvent> any;}}
> The select() method returns a child Event for a given specified type and additional specified qualifiers. If no specified type is given, the specified type is the same as the parent.
> For example, this child Event has required type AdminLoggedInEvent and additional specified qualifier {{@Admin}}:
> {noformat}
> Event<AdminLoggedInEvent> admin = any.select(
> AdminLoggedInEvent.class,
> new AdminQualifier() );
> {noformat}
> The problem is that the injection point any already is qualified @Admin, so the use is duplicate here. I believe the intention was that the injection point would read
> {{@Inject Event<LoggedInEvent> any;}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 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:
------------------------------------
There are several examples of existing APIs either accepting or returning {{null}} values. The point is one can not simply change their "behavior" (API contract). If one decides for {{java.until.Map#get}} e.g. to throw a NoSuchElementException in case if absent key, one would break the contract that was asserted beforehand. Changing a existing contract is possible, but one should have a good reason for doing so. Optional injection points are from my point of view not worth changing the existing contract for injection point validation during startup.
> 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, 7 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 edited comment on CDI-565 at 10/7/15 5:11 PM:
---------------------------------------------------------------
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. 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()}}?
was (Author: martin.andersson):
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, 7 months
