Hi guys, Re-reading materials and all our discussion on CDI-527, I think there's an option we didn't explore Instead of introducing a new annotation, we could loose rules on proxied bean creation for class having final methods. Today if you declare a class requiring a proxy (because of scope or AOP) you'll get an exception, so nobody declares a bean with such a feature since the app wouldn't deploy. It's the same for producer: you won't declare an @ApplicationScoped producer for a type having final method since your app won't deploy. So in today existing code, final method are in non cdi code or in cdi code that doesn't requires proxy (@Dependent without AOP) If we decide to loose the rules in "3.15 Unproxyable bean types" [1] it won't have impact on existing code (unless I missed something), since you can't have proxied bean with final method without deployment error. It would only allow new proxied bean with final method in it. Change should also be made in "7.2. Container invocations and interception" [2] to explicitly exclude final methods from the list of business method. This change could be seen as not backward compatible, but since current code cannot have proxied bean with final class it doesn't change existing behavior but allow new usage. It also allow code with producer for class of the JDK introducing final in their code to continue working seamlessly in CDI 2.0. Finally that prevent us to introduce specific annotation or configuration looking like a hack. In the past we already introduce behavior changes when we changed the list of bean defining annotation in CDI 1.2 or when we loose usage of certain beanManager method in AfterBeanDiscovery event (I see this proposal very like this last example). Wdyt ? Antoine [1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#unproxyable [2] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.