clarify the definition of the (unrestricted) set of bean types

[Ladicek]

For managed bean, the unrestricted set of bean types is defined as:

The unrestricted set of bean types for a managed bean contains the bean class, every superclass and all interfaces it implements directly or indirectly.

Similar wording exists for producer methods and fields.

This is imprecise, because classes don't extend classes and implement interfaces -- they extend class types and implement interface types! This distinction matters in presence of parameterized types and also raw types.

For example, if I have a class class MyList extends ArrayList<String> { ... }, then its superclass is ArrayList, but its superclass type is ArrayList<String>.

It is clear from the examples in the specification, as well as from tests in the TCK, that the intended meaning is that the unrestricted set of bean types contains all supertypes of the bean class as defined by the Java Language Specification. Specificially for the text above, I'd suggest this rewording:

The unrestricted set of bean types for a managed bean contains the type of the bean class and all its direct and indirect supertypes, as defined by the Java Language Specification.

EDIT: actually not supertypes, but superclass types and superinterface types. Supertypes are something slightly different (for example, each parameterized type G<T1, T2, ..., Tn> has the raw type G as its supertype).

It might also be beneficial to highlight the following provision from the JLS:

The superclass types (respectively, superinterface types) of a raw type are the erasures of the superclass types (superinterface types) of the named class or interface.

However, we shouldn't really copy half of JLS into CDI, so this is perhaps a bit too much. Delegating to JLS should be enough, in any case.

[mkouba]

It is clear from the examples in the specification, as well as from tests in the TCK,...

See also the related https://issues.redhat.com/browse/CDITCK-416 and https://issues.redhat.com/browse/WELD-1740.

However, we shouldn't really copy half of JLS into CDI, so this is perhaps a bit too much. Delegating to JLS should be enough, in any case.

👍

[jeanouii]

@mkouba The CDITCK project isn't visible anymore. It would be great if it could become visible again, because it has a lot of history and discussions. Does it still exist?

[mkouba]

@mkouba The CDITCK project isn't visible anymore. It would be great if it could become visible again, because it has a lot of history and discussions. Does it still exist?

🤷 @manovotn?

[manovotn]

It still exists; as far as I know, it's read-only. Maybe you need to be logged in?
No clue why though, that sure isn't my doing :-D

[jeanouii]

Yes I'm logged in, I created an account.
Even if it's read only, that'd be great if it could be visible. Here is what I get.

[Ladicek]

That's weird. When I log into the Red Hat JIRA, I can see CDITCK-416 just fine. I even get a warning that This is a public project. 🤷

[Ladicek]

Maybe it isn't accessible to non-Red Hat people because the project is also archived...?

[manovotn]

Same here, I can see it after login.
I found this as Atlassian info on archiving projects, but it's not awfully helpful - https://confluence.atlassian.com/adminjiraserver0820/archiving-a-project-1095777329.html
In fact according to that article it should still work 🤔

[jeanouii]

Amazingly, I can see https://issues.redhat.com/browse/CDI even without being logged in. But logged in or not, I can't access https://issues.redhat.com/browse/CDITCK

[manovotn]

I've tried to reach out to the administration team of JIRA to see what's happening but I have no idea how long it may take to get an answer or a fix.

[manovotn]

The JIRA accessibility issue should now be solved - it can be viewed again even without logging in.
It still (intentionally) remains read-only.