[LANG] Thoughts about Lang 4.0

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[LANG] Thoughts about Lang 4.0

Benedikt Ritter-4
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
Reply | Threaded
Open this post in threaded view
|

RE: [LANG] Thoughts about Lang 4.0

dbrosIus
Might want to drop commons-date  as well. Want people to use java.time 

-------- Original message --------
From: Benedikt Ritter <[hidden email]>
Date: 5/21/17  7:56 PM  (GMT-05:00)
To: Commons Developers List <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

garydgregory
On Sun, May 21, 2017 at 5:16 PM, dbrosIus <[hidden email]> wrote:

> Might want to drop commons-date  as well. Want people to use java.time
>

Or Joda-Time if you're on Java < 8.

Gary


>
> -------- Original message --------
> From: Benedikt Ritter <[hidden email]>
> Date: 5/21/17  7:56 PM  (GMT-05:00)
> To: Commons Developers List <[hidden email]>
> 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
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

garydgregory
In reply to this post by Benedikt Ritter-4
One thought for a multi module 4.0 would be to cover Java 8.

Gary

On May 21, 2017 4:57 PM, "Benedikt Ritter" <[hidden email]> 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?
Benedikt
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Rob Tompkins
In reply to this post by Benedikt Ritter-4

> On May 21, 2017, at 7:56 PM, Benedikt Ritter <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Matt Sicker
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 <[hidden email]> wrote:

>
> > On May 21, 2017, at 7:56 PM, Benedikt Ritter <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

garydgregory
On Mon, May 22, 2017 at 8:55 AM, Matt Sicker <[hidden email]> wrote:

> 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.
>

+1 to Java 8 and covering java.time.

It seems like the 3.x line will be alive for a long time and that we might
want to stick to bug fixes only there once 4.0 is out, depending on who
might volunteer to RM.

Gary


>
> 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 <[hidden email]> wrote:
>
> >
> > > On May 21, 2017, at 7:56 PM, Benedikt Ritter <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Matt Sicker <[hidden email]>
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Pascal Schumacher
In reply to this post by Matt Sicker
Am 22.05.2017 um 17:55 schrieb Matt Sicker:
> 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>.
Well there are already good Apache 2.0 licensed java libraries for
tuples and functions, e.g.:

https://github.com/jOOQ/jOOL (up to 16)

https://github.com/vavr-io/vavr (up to 8)

(both of course offer more that just tuples and functions).

Just saying.

Cheers,
Pascal

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

garydgregory
Yes, but tuples are generally useful outside of lambdas, well, at least the
size 2 kind.

Gary

On Mon, May 22, 2017 at 11:24 AM, Pascal Schumacher <
[hidden email]> wrote:

> Am 22.05.2017 um 17:55 schrieb Matt Sicker:
>
>> 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>.
>>
> Well there are already good Apache 2.0 licensed java libraries for tuples
> and functions, e.g.:
>
> https://github.com/jOOQ/jOOL (up to 16)
>
> https://github.com/vavr-io/vavr (up to 8)
>
> (both of course offer more that just tuples and functions).
>
> Just saying.
>
> Cheers,
> Pascal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

AW: [LANG] Thoughts about Lang 4.0

Jan Matèrne (jhm)
In reply to this post by Matt Sicker
> 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>.

One benefit of having an ASF commons "tuple library" is .... it's from the ASF.
I am not joking. An ASF library promisses to have a community and a life cycle you can
precognize. In contrast a "simple" github library is just a peace of code.



> 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.

I think converter functions between java.util.Date and java.time could be helpful.
Think of "old" modules of your application (maybe 3rd party libs) which require the one
and other parts which require the other.


Jan


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Matt Sicker
On 22 May 2017 at 14:35, Jan Matèrne (jhm) <[hidden email]> wrote:
>
> One benefit of having an ASF commons "tuple library" is .... it's from the
> ASF.
> I am not joking. An ASF library promisses to have a community and a life
> cycle you can
> precognize. In contrast a "simple" github library is just a peace of code.


This is a great point, honestly. I don't like using random tuple util
classes from my dependencies (other than in Scala now since they have it in
their standard library) in any public code (though it's usable in private
methods, etc.). Given a nice enough tuple library, it may be possible to
see it start to replace all the random tuple utils elsewhere.


> I think converter functions between java.util.Date and java.time could be
> helpful.
> Think of "old" modules of your application (maybe 3rd party libs) which
> require the one
> and other parts which require the other.


Like these?
https://docs.oracle.com/javase/8/docs/api/java/util/Date.html#from-java.time.Instant-
https://docs.oracle.com/javase/8/docs/api/java/util/Date.html#toInstant--


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

jochen-2
In reply to this post by Rob Tompkins
On Mon, May 22, 2017 at 1:47 PM, Rob Tompkins <[hidden email]> wrote:

>> - 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

I am -0 to -1 regarding the introduction of new components. I'd rather
see us redefine the purpose of commons-lang. The experience of
commons-math has demonstrated, IMO, that such new components will most
likely increase the noise without an associated increase of the
output.

IMO, c-lang is running well, as it is.

Jochen



--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

jodastephen
On 23 May 2017 at 10:13, Jochen Wiedmann <[hidden email]> wrote:
> I am -0 to -1 regarding the introduction of new components. I'd rather
> see us redefine the purpose of commons-lang. The experience of
> commons-math has demonstrated, IMO, that such new components will most
> likely increase the noise without an associated increase of the
> output.
>
> IMO, c-lang is running well, as it is.

I'm not personally convinced that smaller components solves anything.
It gives end users more dependencies to manage, with more potential
for clashes. Plus, no-one should be adding a dependency for just a
couple of simple methods - thus [lang] needs to be a certain size to
have enough useful methods to justify itself. The "competition" is
Guava, and that is also a decent size library.

Looking to Java 10 and beyond, we might see a way to have one artifact
(jar file) contain multiple modules, allowing end-users to depend on
parts of [lang] package by package. In such a scenario, it would
actually be better to lump more into a single jar file, not less.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Emmanuel Bourg-3
In reply to this post by jochen-2
Le 23/05/2017 à 11:13, Jochen Wiedmann a écrit :

> IMO, c-lang is running well, as it is.

+1

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

jodastephen
In reply to this post by Benedikt Ritter-4
On 22 May 2017 at 00:56, Benedikt Ritter <[hidden email]> wrote:
> I think the time has come to start thinking about Lang 4.0.

As I outlined in another thread, Lang 3.5 uses PropertyChangeListener,
which in module terms pulls in the whole of Swing and AWT. For a
library like [lang] that is a bad thing and should really be fixed.

Fixing it properly requires a major release, which implies that Lang
4.0 is still Java 1.7 and should use the `org.apache.commons.lang3`
package name. Yes, the versioning a bit of a mess, but you are where
you are.

More broadly, it needs to be established if a lang release for Java 8
is needed? What would it enable? Would a new commons project be a
better place for them (ie. a new [core] or [eight] project)?

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Gilles Sadowski
In reply to this post by jochen-2
On Tue, 23 May 2017 11:13:21 +0200, Jochen Wiedmann wrote:

> On Mon, May 22, 2017 at 1:47 PM, Rob Tompkins <[hidden email]>
> wrote:
>
>>> - 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
>
> I am -0 to -1 regarding the introduction of new components. I'd
> rather
> see us redefine the purpose of commons-lang. The experience of
> commons-math has demonstrated, IMO, that such new components will
> most
> likely increase the noise without an associated increase of the
> output.

Can you be explicit with what counts as "noise"?

If "output" is total number of lines of code, then you are right; I'm
trying to reduce it for "Commons Math", in the hope that the project
will be better off on all other counts besides plain size.

> IMO, c-lang is running well, as it is.

Sure; hence the talk about fixing its dependency on Swing (IIUC)...
Finer-grained and modular components are much easier to manage. Its
an improvement, especially for users who need to control their
dependencies.


Regards,
Gilles

>
> Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

sebb-2-2
In reply to this post by jodastephen
On 23 May 2017 at 11:05, Stephen Colebourne <[hidden email]> wrote:

> On 22 May 2017 at 00:56, Benedikt Ritter <[hidden email]> wrote:
>> I think the time has come to start thinking about Lang 4.0.
>
> As I outlined in another thread, Lang 3.5 uses PropertyChangeListener,
> which in module terms pulls in the whole of Swing and AWT. For a
> library like [lang] that is a bad thing and should really be fixed.
>
> Fixing it properly requires a major release, which implies that Lang
> 4.0 is still Java 1.7 and should use the `org.apache.commons.lang3`
> package name.

I think that depends on whether the API is backwards-compatible or not.

If it *is* backwards-compatible, then do we need a major release?

If *not*, then 4.0 needs a new package.

Why?

Suppose code A depends on a LANG 3 method not present in 4
and code B depends on some new feature in LANG 4

It's not possible to use A and B together on the same classpath.

In which case 4.0 must use a new package and Maven coordinates.

> Yes, the versioning a bit of a mess, but you are where you are.
>
> More broadly, it needs to be established if a lang release for Java 8
> is needed? What would it enable? Would a new commons project be a
> better place for them (ie. a new [core] or [eight] project)?
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

jodastephen
On 23 May 2017 at 11:54, sebb <[hidden email]> wrote:

>> Fixing it properly requires a major release, which implies that Lang
>> 4.0 is still Java 1.7 and should use the `org.apache.commons.lang3`
>> package name.
>
> I think that depends on whether the API is backwards-compatible or not.
>
> If it *is* backwards-compatible, then do we need a major release?
>
> If *not*, then 4.0 needs a new package.
>
> Why?
>
> Suppose code A depends on a LANG 3 method not present in 4
> and code B depends on some new feature in LANG 4
>
> It's not possible to use A and B together on the same classpath.
>
> In which case 4.0 must use a new package and Maven coordinates.

The change to remove PropertyChangeListener will be incompatible.
Thus, if you want to be strict then you have to have a new package and
maven co-ordinates. But IMO, this would simply cause end-user projects
to have v2.x, v3.x and v4.x on the classpath - its bad enough with two
versions right now, I don't personally think removing these two
methods is enough to justify a new package/maven co-ordinate and the
downstream mess that ensues.

I will note that the JDK is removing methods due to exactly the same
issue - modular Java is quite disruptive..

Options that leave the methods in:

1) Add module-info for v3.x that "requires java.desktop" and accept
that end-users get Swing/AWT

2) Add module-info for v3.x that "requires static java.desktop" (an
optional dependency) and accept that users of circuit breaker must
manually "require java.desktop".

Options that remove the methods:

3) Make a backwards incompatible change to remove the bad methods in
v3.7 (no package name change)

4) Make a backwards incompatible change to remove the bad methods in
v4.0 (no package name change)

5) Make a backwards incompatible change to remove the bad methods in
v4.0 (with package name change)

If you do #4 or #5, you also need #1 or #2 for the v3.x branch. #3 is
aggressive but gets rid of the issue in the fastest way.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Bruno P. Kinoshita-3
I think +0 for #1, +1 for #2, and +1 for (#4 or #5). -1 for #3 (though +1 for a 3.7 deprecating these methods).

For 4.0, I wonder if we could find a replacement for the property listeners from java.beans, or might be simpler just remove the property listeners, and have a simple interface for specifying the possible life cycle of a circuit breaker (similar to what Elastic Search does).


I believe I was possibly responsible for introducing it in [lang], so happy to prepare as many development cycles as necessary to help sorting this out, and perhaps stepping up as a release manager for the first time to prepare some releases of lang.

Cheers
Bruno________________________________
From: Stephen Colebourne <[hidden email]>
To: Commons Developers List <[hidden email]>
Sent: Tuesday, 23 May 2017 11:18 PM
Subject: Re: [LANG] Thoughts about Lang 4.0



On 23 May 2017 at 11:54, sebb <[hidden email]> wrote:

>> Fixing it properly requires a major release, which implies that Lang
>> 4.0 is still Java 1.7 and should use the `org.apache.commons.lang3`
>> package name.
>
> I think that depends on whether the API is backwards-compatible or not.
>
> If it *is* backwards-compatible, then do we need a major release?
>
> If *not*, then 4.0 needs a new package.
>
> Why?
>
> Suppose code A depends on a LANG 3 method not present in 4
> and code B depends on some new feature in LANG 4
>
> It's not possible to use A and B together on the same classpath.
>
> In which case 4.0 must use a new package and Maven coordinates.

The change to remove PropertyChangeListener will be incompatible.
Thus, if you want to be strict then you have to have a new package and
maven co-ordinates. But IMO, this would simply cause end-user projects
to have v2.x, v3.x and v4.x on the classpath - its bad enough with two
versions right now, I don't personally think removing these two
methods is enough to justify a new package/maven co-ordinate and the
downstream mess that ensues.

I will note that the JDK is removing methods due to exactly the same
issue - modular Java is quite disruptive..

Options that leave the methods in:

1) Add module-info for v3.x that "requires java.desktop" and accept
that end-users get Swing/AWT

2) Add module-info for v3.x that "requires static java.desktop" (an
optional dependency) and accept that users of circuit breaker must
manually "require java.desktop".

Options that remove the methods:

3) Make a backwards incompatible change to remove the bad methods in
v3.7 (no package name change)

4) Make a backwards incompatible change to remove the bad methods in
v4.0 (no package name change)

5) Make a backwards incompatible change to remove the bad methods in
v4.0 (with package name change)

If you do #4 or #5, you also need #1 or #2 for the v3.x branch. #3 is
aggressive but gets rid of the issue in the fastest way.


Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

jochen-2
In reply to this post by Gilles Sadowski
On Tue, May 23, 2017 at 12:19 PM, Gilles <[hidden email]> wrote:

> Can you be explicit with what counts as "noise"?

Lets start with the number of threads, shall we? Or the number of
"What  depends on what" discussions? Or questions like "Which belongs
to what?" (Feel free to suggest another measure.)

Jochen


--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123