Henri Yandell a écrit : > 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.
There is already a Fraction class in [math]. I'm not sure if it should be removed from [lang]. If it was put there at the first place, it was needed by someone. Pushing users towards [math] may be difficult for such a small class. Luc > > 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
