--- On Sat, 3/14/09, Gary Gregory <ggreg...@seagullsoftware.com> wrote:
> From: Gary Gregory <ggreg...@seagullsoftware.com> > Subject: RE: [lang] 3.0, what's in; what's out > To: "Commons Developers List" <dev@commons.apache.org> > Date: Saturday, March 14, 2009, 2:19 PM > > -----Original Message----- > > From: Matt Benson [mailto:gudnabr...@yahoo.com] > > Sent: Saturday, March 14, 2009 11:57 AM > > To: Commons Developers List > > Subject: Re: [lang] 3.0, what's in; what's out > > > > > > I'd like to add a TypeUtils to the reflect subpackage, > to provide as much > > help as possible for discovering type parameters of > generic types. I > > I thought that type erasure made this impossible? Can you > define what the class would do please? Based on the research I have done thus far, type erasure makes it impossible to determine the parameters of a given object, but you can still learn certain things about type parameters of methods, fields, and superclasses that may be helpful. The idea is under development, but it's based on James's code from [proxy]'s 2.0 branch. Thanks for your concern though! ;) -Matt > > Thanks, > Gary > > > recently commented in ClassUtils that a 3.0, > Java5-compatible assignable > > test should assume autoboxing == true (since one would > think the > > assignable test would normally be used in preparation > for e.g. a > > reflection-based method call autoboxing should have > been a safe assumption > > to begin with, but anyway...). > > > > -Matt > > > > --- On Sat, 3/14/09, Henri Yandell <flame...@gmail.com> > wrote: > > > > > From: Henri Yandell <flame...@gmail.com> > > > Subject: [lang] 3.0, what's in; what's out > > > To: "Commons Developers List" <dev@commons.apache.org> > > > Date: Saturday, March 14, 2009, 4:21 AM > > > Starting up a thread for cleanup > > > discussions on Lang. > > > > > > I've removed the enum (was a blocker on JDK 5) > and enums > > > (people need > > > to use real enums now) packages from Lang's trunk > and moved > > > them to a > > > lang-backcompat sibling component. I've not made > it a > > > branch, it lives > > > at the same level as trunk and will need its > future to be > > > decided. > > > > > > An EnumUtils class has been added to the main > lang > > > package. > > > > > > I also think the exception package should go. > Again - the > > > JDK has > > > support for this now and there's no strong value > in Lang > > > having an > > > alternative to stop people thinking about JDK > 1.5. The > > > ExceptionUtils > > > class should move up to the main lang package and > needs to > > > have the > > > Nestable Lang code removed from it. Presumably it > still has > > > value. > > > > > > Some of the Date code is tempting to delete. > Either due to > > > buginess, > > > or general 'this isn't that cool' ness. > > > > > > JVMRandom should go. I'm not convinced it's had > much use. > > > > > > IDKey should move to package scoping - I've not > seen an > > > argument made > > > yet for it being public. > > > > > > Fraction is up for debate. Do we cede this to > Commons Math. > > > Sure it > > > might add another jar to some people's code, but > probably > > > good for > > > them to be more aware of Math. > > > > > > WordUtils and StringEscapeUtils both strike me > as > > > 'desirable but > > > flawed'. We should consider overhauls. > > > > > > The Security requiring stuff in builder for > reflection > > > needs to go > > > away imo. Makes it less than useful. > > > > > > We need a PackageUtils in reflect. > > > > > > We need to consider if there are any annotations > that are > > > valuable to > > > be pseudo-standard. > > > > > > I'm still partial to a RegexUtils. > > > > > > Plus general generifying, varargs, autoboxing. > > > > > > Deletion of all deprecated methods/classes. > > > > > > And the various other backwards incompatible > changes that > > > people have > > > been requesting. > > > > > > Hen > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
