[cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods

[Romain Manni-Bucau (JIRA)]

    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13142275#comment-13142275 ] 

Romain Manni-Bucau commented on CDI-527:
----------------------------------------

Think we should stay close to java there and don't abuse of bytecode generation since we can end up in a state were we break java (extending classes and proxying final method is already). Proxying types need a no-op constructor for instance even if protected and this one is far more a real constraint when coding than final methods IMHO so users already know what is the technical impl (and implied constraints) so staying aligned on java keeps things understandable I think.

More specifically on the new API: this proxying is not always possible for java.* cause some API are not "exposed enough" so it is a super risky hyposthesis and even if the new API is not used on producer code itself the user would need to flag it anyway so the portability of legacy applications is already not free and suppose you hit this issue, what's the fastest? Modifying your code with a Ctrl+R (replace) or checking the spec and implementation for a feature which is maybe not reliable?


> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)