[ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.sys... ] Antonin Stefanutti edited comment on CDI-45 at 9/1/14 5:14 PM: --------------------------------------------------------------- Then one potential compromise would be to enrich the existing abstractions, either {{Instance}} or {{Provider}} with the equivalent semantic that of {{Optional}}. For example: {code} @Inject Provider<MyBean> bean; if (bean.isPresent()) bean.get(); {code} Or if we think {{Optional}} is a convenient abstraction: {code} @Inject Provider<MyBean> bean; bean.getOptional(); {code} In any case, I think that a {{isSatisfied()}} / {{isResolvable()}} method is missing on the {{Instance}} interface when alternatives are enabled for example and that would avoid writing {{!isUnsatisfied() && !isAmbiguous()}}. As per backward compatibility for these interfaces, are they really meant to be implemented aside from the implementations? That would avoid introducing another interface. If not maybe default method in Java 8 could help. was (Author: stefanutti): Then one potential compromise would be to enrich the existing abstractions, either {{Instance}} or {{Provider}} with the equivalent semantic that of {{Optional}}. For example: {code} @Inject Provider<MyBean> bean; if (bean.isPresent()) bean.get(); {code} In any case, I think that a {{isSatisfied()}} / {{isResolvable()}} method is missing on the {{Instance}} interface when alternatives are enabled for example and that would avoid writing {{!isUnsatisfied() && !isAmbiguous()}}. As per backward compatibility for these interfaces, are they really meant to be implemented aside from the implementations? That would avoid introducing another interface. If not maybe default method in Java 8 could help. -- This message was sent by Atlassian JIRA (v6.3.1#6329)