Enforce validation of return type of observer methods

Currently, CDI doesn’t mandate that OM have certain return type. However, since those methods are invoked by CDI, user has no means to obtain whatever return type/value it has. It might be worth considering to enforce that the return type is void through validation.

Note that in theory, CDI doesn’t prohibit users from invoking these methods manually. Due to this, it would be potentially breaking change as some application might be using that. Though all parameters (except event param OFC) of OM are injection points so manual invocation IMO makes little sense.

The only impact of this issue for CDI would be enforcing good practices in CDI applications.

[Ladicek]

The specific context we had in mind is programmers declaring asynchronous observers that return CompletionStage<Void> or similar asynchronous types. To a lot of users, that gives the impression that the CDI container will wait for the completion stage to complete before returning from fireAsyncwill arrange the CompletionStage returned from fireAsync to only complete once the CompletionStages returned from the observers complete, which is not the case. My intuitive reaction to that was: we should treat non-void observer methods as definition errors (and I was surprised that the spec doesn’t mandate that).

We discussed this issue on the CDI call today and didn’t really reach any conclusion AFAICT. I’m tempted to propose that we just close this, citing Hyrum’s Law as the main reason 😃

[Ladicek]

That’s a very creative combination of interceptors and observers indeed. The specification says that observer method invocations are business method invocations and hence are intercepted, so it seems perfectly valid.