[ 
https://issues.apache.org/jira/browse/LANG-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580101#action_12580101
 ] 

Matt Benson commented on LANG-416:
----------------------------------

Thanks for your candor, Niall.  I am very enthusiastic that Morph has the 
capacity to be split into the right components to be a nice next-gen for 
BeanUtils.  We'll see.  As for [reflect], it doesn't show up on the dormant nor 
sandbox sections of the site, so I had missed it originally, thanks for the 
pointer.  Looks small, and somewhat telling that it contains a CommonsLang 
class, which "Avoids dependency on Commons Lang by copying code to this class." 
 I understand the motivation here, but is [reflect] simply too damned small?  
:)  Is it possible Commons Lang (Reflect) could be a subset jar produced by 
[lang]?  Or could svn externals create [reflect] from [lang]'s code without 
ongoing synchronization?  I'm going to keep going down the road I've been going 
down for now, and we can then retire the discussion of [reflect] vs. [lang] vs. 
[door #3] to the dev list before making any permanent decisions wrt Lang 
2.5/3.0.  How's that?

> 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.

Reply via email to