Clarify "contains" meaning in "Legal bean types" specification. (CDI-502)

[ljnelson]

I happened to notice that CDI-502 does not seem to have any resolution in the current version of the CDI specification.

Following the rules described in the issue, which read:

The CDI project is part ofJakarta and uses GitHub issues as it's [sic] issue tracking system.
Therefore, all issues in CDI JIRA project are being bulk-closed as described in #479.
If you feel like this particular issue deserves ongoing discussion, investigation or fixes in CDI/CDI TCK, please create a new issue under GitHub repository and include a link to this JIRA.
For specification related question/issues, please use - https://github.com/eclipse-ee4j/cdi/issues
For CDI TCK related questions/issues, please use - https://github.com/eclipse-ee4j/cdi-tck/issues

…I am filing this issue to resurrect CDI-502. (I've used https://github.com/jakartaee/cdi/issues as https://github.com/eclipse-ee4j/cdi/issues has redirected here for a while now.)

The original issue reads:

CDI 1.1, section 2.2.1. Legal bean types says:

A parameterized type that contains a wildcard type parameter is not a legal bean type.

[Note that the most recent version of the specification (4.1) still says the same thing.]

Does it means [sic] direct containment or deep/recursive containment?

I understand this is clearly illegal:

List<?> produceList(){
//...
}

But, are those [sic] two bean definitions legal:

List<Optional<?>> produceList(){
//...
}

// Bean types: MyList, List<Optional<?>>, Object
// or
// Bean types: MyList, Object
@Dependent
MyList extends List<Optional<?>> {
//...
}

(The issue's comment section seems to imply that the original poster's vague notion of "deep/recursive containment" is what is meant, obviously to the extent that it is well-formed.)

The last comment in the bulk-closed issue says (effectively):

Should I report it as a clarification or bug?

Yes, clarification probably.

As far as I can tell this wasn't done, or at least the issue wasn't resolved. My only selfish reason for reopening the never-really-closed issue is that I've been burned by this "nested wildcard" issue several times in the past.

Additionally, it is worth noting from the original issue the strange assignment that is permitted by CDI rules but not by the Java language. Maybe that's a separate issue?

Additionally additionally, this comment that supports the "deep/recursive containment" interpretation of the specification's language here is the only place where "actual type" is ever defined by anyone in any context, as far as I can tell (including in the specification and the JLS). It reads:

An actual type is a type that is not a wildcard nor [sic] an unresolved [sic] type variable.

(Clearly this cannot be the case since things like the javax.lang.model.type.* hierarchy and its corresponding locations in the JLS speak about things such as NoTypes of various kinds etc., but this general, vague, hazy, not-rigorous gist is at least not utterly murky.)

Is that also a separate issue?

Additionally additionally additionally, the CDI specification often uses "parameterized type" to mean (badly) "a type that in some hazy vaguely intuitive unspecified way can take type arguments" (e.g. List<String>[], which is not, according to the JLS, a parameterized type). Does that come into play here? Haven't thought about that yet.