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