Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <1166141611.1205773704301.JavaMail.jira@brutus>
Date: Mon, 17 Mar 2008 10:08:24 -0700 (PDT)
From: "Matt Benson (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (LANG-416) Import MethodUtils and
 ConstructorUtils from BeanUtils
In-Reply-To: <913609979.1204927426194.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/LANG-416?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D125795=
12#action_12579512 ]=20

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 his=
tory 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 h=
ave on Lang.  It is possible to introduce the dependency, of course, but it=
 is equally possible to augment the documentation of these classes in BeanU=
tils to indicate that they are intended primarily for use in conjunction wi=
th, or preferably by, BeanUtils and that more general-purpose replacement c=
lasses are to be found in Commons Lang.  Bottom line is, if you need this c=
ode, BeanUtils is a fairly focused API from which to have to get it.  I con=
ceptualize 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 t=
hat depend upon other Commons APIs.  These are more convenient APIs which, =
when used as simply as possible, still DO something, if you will.  BeanUtil=
s is somewhere in between, IMO.  It doesn't do much, relative to some of th=
e 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 sup=
erclass MemberUtils, make ConstructorUtils extend MemberUtils and use the s=
ame code (be on the lookout for ways to improve best-match calcs; my origin=
al description was based on javadoc that said the first matching method enc=
ountered was used, but this comment seems to have been outdated).=20
> - 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.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.