commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Benson (JIRA)" <>
Subject [jira] Commented: (LANG-416) Import MethodUtils and ConstructorUtils from BeanUtils
Date Tue, 18 Mar 2008 13:57:24 GMT


Matt Benson commented on LANG-416:

@Hen:  I was a little confused by "as they're there there's no point duplicating"  (Nice use
of three consecutive homophones, btw).  Do I interpret that correctly to say your preference
is to preserve the status quo _if_ BeanUtils continues to be relevant enough to warrant ongoing

@Stephen:  I assume you mean [clazz].  Even after I found the true reflection-based code,
I never found code that could do the hardest part (IMO) of what MethodUtils does:  implementing
compile-time overloaded method selection at runtime.  The story of what happened to [clazz]
is certainly one I'd like to hear.  (Why are the core interfaces not represented in the Javadoc?)

I still have a hard time swallowing that any project wanting some help with Method/Constructor
related code should be encumbered by a dependency as focused (and therefore conceptually,
if not actually, "heavy") as BeanUtils in order to get it.  As usual, however, we'll arrive
at a consensus by majority opinion/vote and act accordingly.  While we're here, however, I
will also point out the fact that overlap already exists between parts of [beanutils] MethodUtils
and [lang] ClassUtils, in both directions.

> Import MethodUtils and ConstructorUtils from BeanUtils
> ------------------------------------------------------
>                 Key: LANG-416
>                 URL:
>             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.

View raw message