Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods

There are other use cases beside produces e.g. @ApplicationScoped class MyClass extends ClassWithFinalMethods But if we add this as well, then there is no other use case left! You could also go on and remove the whole rule in that case. But that is exactly what we don’t like, right? Because Random Joe would fall into this trap way too easily. Pretty hard for an average user to do. And would also trump backward compatibility. LieGrue, strub > Am 13.02.2016 um 22:21 schrieb David Blevins <david.blevins(a)gmail.com&gt;: > > Read what I could get my hands on. Unfortunately the JIRA itself has 36 comments which won’t load/expand in Safari or Chrome. But I think I get the summary. > > High level, I agree with both Mark and Martin. > > - Agree with Mark: Where I see this feature being important is in our EJB/CDI alignment efforts. This appears to be the rare case where the CDI spec is more strict than the EJB spec and a speed bump in someone’s efforts to port an EJB application to CDI. For that reason, this to me upgrades from nice-to-have to we-must-find-a-way. > > - Agree with Martin: I also strongly dislike the use of beans.xml in any fashion and system properties even more. Aside from being cumbersome for users, I’m particularly against setting a trend of using system properties to bail us out of hard API design issues. This concern trumps the above and I would -1 this vote as-is. > > That said, I’m not sure if this approach is workable in any way, but here goes: > > We keep the default rule of beans with final methods being unproxyable unless explicit action in code is taken and the class is: > > > Effectively the BeanManager would continue to ignore beans with final methods as proxyable in a classpath scan, but the application could “go back” and explicitly put them into the BeanManager as proxyable. > > > Thoughts? Big holes in there? > > > -David