[
https://issues.apache.org/jira/browse/LANG-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579505#action_12579505
]
Paul Benedict commented on LANG-416:
------------------------------------
I also agree with Niall. I do not understand why Lang would want to import --
read as clone -- existing code. Wouldn't then BeanUtils have a dependency on
Commons Lang? I don't mind that personally, but it's something to clearly note.
If you import it, then BeanUtils should no longer keep it's copy of the code. I
believe a migration strategy is required here because both code bases will be
in maintenance mode and merging may have to happen often. Sounds like some sort
of coordination plan is required.
> Import MethodUtils and ConstructorUtils from BeanUtils
> ------------------------------------------------------
>
> Key: LANG-416
> URL: https://issues.apache.org/jira/browse/LANG-416
> Project: Commons Lang
> Issue Type: New Feature
> Affects Versions: 2.4
> Reporter: Matt Benson
> Fix For: 3.0
>
>
> Mentioned on the mailing list... After we release 2.4 I'd like to:
> - import ConstructorUtils
> - make CU.getMatchingAccessibleConstructor() public
> - import MethodUtils
> - factor best-match calculation code out of MethodUtils into abstract
> superclass MemberUtils, make ConstructorUtils extend MemberUtils and use the
> same code (be on the lookout for ways to improve best-match calcs; my
> original description was based on javadoc that said the first matching method
> encountered was used, but this comment seems to have been outdated).
> - merge any other duplicate (or near-duplicate) code from CU/MethodU into
> MemberU and remove anything else that doesn't make sense in the context of
> Lang.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
