For the tuple classes, it would be possible to make an entire tuples
library. Might be handy to generate code for it as it'd be useful to
support tuples up to, say, 22 fields (Scala has tuple classes and anonymous
function classes up to 22 arguments, for example). See <
https://www.scala-lang.org/api/current/scala/Tuple22.html>.

If we go to Java 8 as a base line (which would make sense), we don't need a
commons-date library anymore, though if we did, it would be based on the
java.time API instead. Not sure which functionality would be useful here.

For commons-concurrent and -system, I like the ideas. As for -reflection
versus -beanutils, perhaps some exploration toward merging the two could be
made?

On 22 May 2017 at 06:47, Rob Tompkins <chtom...@gmail.com> wrote:

>
> > On May 21, 2017, at 7:56 PM, Benedikt Ritter <brit...@apache.org> wrote:
> >
> > 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?
>
> The only thing that occurs to me is that we should make sure that Java 9
> is fully in general availability before releasing 4.0.
>
> > Benedikt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Matt Sicker <boa...@gmail.com>

Reply via email to