Might want to drop commons-date as well. Want people to use java.time -------- Original message -------- From: Benedikt Ritter <brit...@apache.org> Date: 5/21/17 7:56 PM (GMT-05:00) To: Commons Developers List <dev@commons.apache.org> Subject: [LANG] Thoughts about Lang 4.0
Hi, I think the time has come to start thinking about Lang 4.0. A new major release is a chance to clean up stuff and get rid of APIs we don’t need anymore/don’t want to maintain anymore. Lang has become rather large. It’s description still is „Lang provides a host of helper utilities for the java.lang API […]" When I look at Lang I see a lot of stuff which has nothing to do with the java.lang package. I think our aim for 4.0 should be to get back to that again. I like the approach we took with math. Splitting a large package down into smaller individual components is a good idea. So my proposal is to split out more new components from Lang like we did with commons-text and deprecate that stuff in lang. Then we can start with Lang 4.0 and remove all that stuff. Here are some components I think we could extract from Lang: - commons-system: a library focused on working with system properties and detection of the operation system, system’s architecture and Java version - commons-concurrent: a library providing additional abstractions and implementations for the java.util.concurrent package - commons-reflect: a library which helps working with reflection (where is the line to beanutils here?) - commons-date: a library which helps working with the java.util.Date and java.util.Calendar APIs Furthermore I’d remove the o.a.c.lang3.event package. The stuff in o.a.c.lang3.math could maybe find a new home in one of the commons-math components. The o.a.c.lang3.builder package fits into Lang 4.0 but I’d rename it to o.a.c.lang4.object (if that’s possible). Further more I’d remove the Builder interface. The o.a.c.lang3.mutable and o.a.c.lang3.tuple package as well as the o.a.c.lang3.exception package can stay as they are. WDYT? Benedikt
