> -----Original Message----- > From: Henri Yandell [mailto:flame...@gmail.com] > Sent: Saturday, March 14, 2009 2:21 AM > To: Commons Developers List > Subject: [lang] 3.0, what's in; what's out > > Starting up a thread for cleanup discussions on Lang. Thanks for taking the lead :)
> > 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. This is going to be painful for our team at work. We are in the process of converting _some_ of our [lang] Enums to Java 5 enums but we will probably not get around to fixing everything. Unlike migrating to chained exceptions, migrating to J5 enums is not trivial. While our HEAD code has already moved to Java 6, we are sitting on a huge pile of legacy code. It would be a shame for us to be stuck on [lang] 2.x as we modernize the rest of our code with generics and other APIs. So for now, keeping emums would help, perhaps in a separate package? I suppose we could have both 2.x and 3.x on the classpath... Now that I think about it, we might have to just to satisfy some third party dependency. Hm. > > 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. +1. > 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. +1 > > Some of the Date code is tempting to delete. Either due to buginess, > or general 'this isn't that cool' ness. +1 and point to Joda-Time. > > 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. -1 It seems fine in [lang] IMO. Would [math] use it internally? If not, why shove it to the side there. In my Smalltalk days of old, you could not get away from using Fraction, the runtime would just give you one as soon as you divided anything, no loss of precision. > > WordUtils and StringEscapeUtils both strike me as 'desirable but > flawed'. We should consider overhauls. +1 I've always felt these were never at home in [lang]. It feels like we need a Commons Text project. > > 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. +1 > > 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
