commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Benson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LANG-416) Import MethodUtils and ConstructorUtils from BeanUtils
Date Mon, 17 Mar 2008 17:08:24 GMT

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

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

I understand where you're coming from, but I really don't see a big problem here.  "Fundamental
stuff to help Java developers work with the core APIs" sounds like the mission statement of
Lang to me.  If you check the SVN history of MethodUtils in BeanUtils, RBD commented in there
five years ago to the effect that Lang wanted MethodUtils.  Seems like this is long overdue.
 I'm sure there are other examples of small code duplications among Commons subprojects to
avoid dependencies like the one BeanUtils already doesn't have on Lang.  It is possible to
introduce the dependency, of course, but it is equally possible to augment the documentation
of these classes in BeanUtils to indicate that they are intended primarily for use in conjunction
with, or preferably by, BeanUtils and that more general-purpose replacement classes are to
be found in Commons Lang.  Bottom line is, if you need this code, BeanUtils is a fairly focused
API from which to have to get it.  I conceptualize Commons projects as being tiered anyway:
 Lang, IO, Collections, Pool... these are bottom-tier projects that basically just provide
library code.  On the next tier you have things like JXPath, DBCP, Configuration that depend
upon other Commons APIs.  These are more convenient APIs which, when used as simply as possible,
still DO something, if you will.  BeanUtils is somewhere in between, IMO.  It doesn't do much,
relative to some of the true "second-tier" components, but it arguably does more than Lang
or IO.  MethodUtils, etc. seem to fall into that first-tier category.  BeanUtils is relatively
much to "inherit" just to use these classes.

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


Mime
View raw message