You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by f....@virgilio.it.INVALID on 2019/07/30 08:53:57 UTC
[lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Dear Developers,
we are members of the ZEST research group (Zurich Empirical Software Engineering Team) based at the University of Zurich and the Delft University of Technology. We are conducting an investigation on the diffusion of innovations and we focus on the adoption of new language features. Our research is focused on how API producers adapt their interfaces to introduce support for Java 8’s lambdas. During the course of our investigation, we manually inspected commons-collections, commons-text, and commons-lang’s source code and documentations to understand whether Java’s lambdas have widespread adoption. We would like to have your feedback on our findings.
Our study focuses primarily on Functional Interfaces and Lambda Expressions as these new features were introduced by the Java language and adopted the Java JDK API, as they reduce implementation complexity, improve readability, offer performance benefits and improve security contextualization.
Our analysis showed that though commons-collection 4.2, commons-text 1.7, and commons-lang3 3.9 did not explicitly introduce support for functional interfaces (e.g. by using the @FunctionalInterface annotation). We noticed that the APIs provide compatibility with Java 8+ features, including lambda expressions (since the APIs’s build platform is now on JDK 1.8+). We would like to better understand as to why no major change was necessitated to facilitate the usage of lambda expressions with the API.
In most cases, developers choose to move to new releases to satisfy particular dependency requirements, to take advantage of new Java features (like streams and functional interfaces in the case of Java 8), or just to standardize their implementation to align the API with the Java JDK API. Can you provide us with more information about this?
How did you and your team tackle the choice to change the version of Java supported?
Which factors did you take into account when doing this?
Are there any documented sources (e.g. Jira tickets, or issue tracker issues) about that discussion you can provide us with?
Why were no explicit changes made to the interface to support lambda expressions?
Are there any future plans in place to make larger changes to the API such that lambda expressions would be supported?
We thank you for taking the time to answer our questions. If you would like to be posted about the results of this study, please let us know!
Kind Regards,
Fernando Petrulio.
[photo-logo]
Fernando Petrulio
PhD Student University of Zurich UZH
Department of Informatics
[linkedin] https://www.linkedin.com/in/fernando-petrulio
Re: [lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le mar. 30 juil. 2019 à 17:59, Matt Sicker <bo...@gmail.com> a écrit :
>
> On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski <gi...@gmail.com> wrote:
> > I certainly agree with Gary as to why "Commons" is not there being a
> > practical issue (of no concerted road map and lacking developers to
> > implement it). However, did I understand correctly that you consider
> > such a development to be useless? I.e. rather than updating "Commons"
> > do you suggest that application developers should not use it?
>
> I meant that writing Commons libraries for functional programming
> still isn't possible with Java's limited generics and type system. I'm
> talking about higher kinded types, dependent types, monads, functors,
> etc. While there are some Java libraries out there that attempt to do
> this [1] [2], there's no "natural" way to express type classes and
> other functional programming concepts in Java. Considering the lack of
> Kotlin and Scala libraries in Commons at the moment, I'd conclude that
> this isn't the most appropriate place for functional programming
> libraries at the moment. Or maybe more accurately, Commons doesn't
> have any libraries for this yet (not like we're limited to purely Java
> here).
IIUC, the OP says that "Commons" is lagging behind JDK 8, while
you say that even more recent JDKs lacks the required features.
[Assuming that we *are* limited to Java if the purpose is to provide
tools for Java programmers.]
Thanks for the pointers. I only had a very brief look; IIUC, it means
that what "Commons" could do in the direction pointed at by the OP,
is already available elsewhere (?).
If so, does it suggest that we must somehow interoperate with those
libraries (rather than expend effort to duplicate the functionality)?
> However, that isn't to say that Commons libraries can't offer anything
> useful that relies on lambda functions, streams, completable futures,
> etc., but that is a fairly limited subset of functional programming,
> and any academic study looking at this should know that due to
> familiarity with languages like Haskell where "real" functional
> programming tends to take place still. Or maybe I'm misunderstanding
> the point of this question entirely.
I'm surely missing it too.
But the answer to the question "Where is Commons heading to?"
would useful to know. :-)
Regards,
Gilles
> [1]: https://www.functionaljava.org/
> [2]: https://www.vavr.io/
>
> --
> Matt Sicker <bo...@gmail.com>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Posted by Matt Sicker <bo...@gmail.com>.
Commons Functor <https://commons.apache.org/proper/commons-functor/>
looks more like Java 8 functional programming, that's for sure. I'd
never looked at that before.
On Wed, 31 Jul 2019 at 01:05, Bruno P. Kinoshita <ki...@apache.org> wrote:
>
> Hi,
>
> >Or maybe more accurately, Commons doesn't have any libraries for this yet (not like we're limited to purely Javahere).
> We have the unreleased Commons Functor. I believe this was the intention of the project, though it lost momentum. But some interesting code there that could be simplified and released if there's still interest.
>
> Bruno
>
> On Wednesday, 31 July 2019, 3:59:25 am NZST, Matt Sicker <bo...@gmail.com> wrote:
>
> On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski <gi...@gmail.com> wrote:
> > I certainly agree with Gary as to why "Commons" is not there being a
> > practical issue (of no concerted road map and lacking developers to
> > implement it). However, did I understand correctly that you consider
> > such a development to be useless? I.e. rather than updating "Commons"
> > do you suggest that application developers should not use it?
>
> I meant that writing Commons libraries for functional programming
> still isn't possible with Java's limited generics and type system. I'm
> talking about higher kinded types, dependent types, monads, functors,
> etc. While there are some Java libraries out there that attempt to do
> this [1] [2], there's no "natural" way to express type classes and
> other functional programming concepts in Java. Considering the lack of
> Kotlin and Scala libraries in Commons at the moment, I'd conclude that
> this isn't the most appropriate place for functional programming
> libraries at the moment. Or maybe more accurately, Commons doesn't
> have any libraries for this yet (not like we're limited to purely Java
> here).
>
> However, that isn't to say that Commons libraries can't offer anything
> useful that relies on lambda functions, streams, completable futures,
> etc., but that is a fairly limited subset of functional programming,
> and any academic study looking at this should know that due to
> familiarity with languages like Haskell where "real" functional
> programming tends to take place still. Or maybe I'm misunderstanding
> the point of this question entirely.
>
> [1]: https://www.functionaljava.org/
> [2]: https://www.vavr.io/
>
> --
> Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Posted by Matt Sicker <bo...@gmail.com>.
I just noticed there's no 1.0 release, so I suppose it doesn't even
need to change the version yet.
On Sat, 3 Aug 2019 at 12:24, Matt Sicker <bo...@gmail.com> wrote:
>
> Oh I’d be interested in a functor2 that’s adapted for Java 8. I might work on a proof of concept proposal first.
>
> On Fri, Aug 2, 2019 at 20:09, Bruno P. Kinoshita <ki...@apache.org> wrote:
>>
>> Hi Gilles
>> I can't speak for others, but I agree we would need to remove most of the code that is now available in Java 8. I think [functor] would need more a place for functional code that does not belong to lang, but is still useful to other devs & components.
>>
>> Bruno
>>
>>
>> On Saturday, 3 August 2019, 1:48:50 am NZST, Gilles Sadowski <gi...@gmail.com> wrote:
>>
>> Hello Bruno.
>>
>> Le mer. 31 juil. 2019 à 08:05, Bruno P. Kinoshita <ki...@apache.org> a écrit :
>> >
>> > Hi,
>> >
>> > >Or maybe more accurately, Commons doesn't have any libraries for this yet (not like we're limited to purely Javahere).
>> > We have the unreleased Commons Functor. I believe this was the intention of the project, though it lost momentum.
>>
>> The site is outdated: link to the source repository returns 404.[1]
>>
>> > But some interesting code there that could be simplified and released if there's still interest.
>>
>> From a quick browsing of the documentation[2], it seems that a large chunk
>> is now covered by the JDK's "java.util.function" package. If so, the first step
>> would probably be a purge of everything that duplicates functionality available
>> in standard classes.
>>
>> It would be most interesting to read what the developers who contributed
>> to that component think.[3]
>>
>> Regards,
>> Gilles
>>
>> [1] https://commons.apache.org/proper/commons-functor/source-repository.html
>> [2] https://commons.apache.org/proper/commons-functor/apidocs/index.html
>> [3] https://commons.apache.org/proper/commons-functor/team-list.html
>>
>> >
>> > Bruno
>> >
>> > On Wednesday, 31 July 2019, 3:59:25 am NZST, Matt Sicker <bo...@gmail.com> wrote:
>> >
>> > On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski <gi...@gmail.com> wrote:
>> > > I certainly agree with Gary as to why "Commons" is not there being a
>> > > practical issue (of no concerted road map and lacking developers to
>> > > implement it). However, did I understand correctly that you consider
>> > > such a development to be useless? I.e. rather than updating "Commons"
>> > > do you suggest that application developers should not use it?
>> >
>> > I meant that writing Commons libraries for functional programming
>> > still isn't possible with Java's limited generics and type system. I'm
>> > talking about higher kinded types, dependent types, monads, functors,
>> > etc. While there are some Java libraries out there that attempt to do
>> > this [1] [2], there's no "natural" way to express type classes and
>> > other functional programming concepts in Java. Considering the lack of
>> > Kotlin and Scala libraries in Commons at the moment, I'd conclude that
>> > this isn't the most appropriate place for functional programming
>> > libraries at the moment. Or maybe more accurately, Commons doesn't
>> > have any libraries for this yet (not like we're limited to purely Java
>> > here).
>> >
>> > However, that isn't to say that Commons libraries can't offer anything
>> > useful that relies on lambda functions, streams, completable futures,
>> > etc., but that is a fairly limited subset of functional programming,
>> > and any academic study looking at this should know that due to
>> > familiarity with languages like Haskell where "real" functional
>> > programming tends to take place still. Or maybe I'm misunderstanding
>> > the point of this question entirely.
>> >
>> > [1]: https://www.functionaljava.org/
>> > [2]: https://www.vavr.io/
>> >
>> > --
>> > Matt Sicker <bo...@gmail.com>
>
> --
> Matt Sicker <bo...@gmail.com>
--
Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Posted by Matt Sicker <bo...@gmail.com>.
Oh I’d be interested in a functor2 that’s adapted for Java 8. I might work
on a proof of concept proposal first.
On Fri, Aug 2, 2019 at 20:09, Bruno P. Kinoshita <ki...@apache.org> wrote:
> Hi Gilles
> I can't speak for others, but I agree we would need to remove most of the
> code that is now available in Java 8. I think [functor] would need more a
> place for functional code that does not belong to lang, but is still useful
> to other devs & components.
>
> Bruno
>
>
> On Saturday, 3 August 2019, 1:48:50 am NZST, Gilles Sadowski <
> gilleseran@gmail.com> wrote:
>
> Hello Bruno.
>
> Le mer. 31 juil. 2019 à 08:05, Bruno P. Kinoshita <ki...@apache.org> a
> écrit :
> >
> > Hi,
> >
> > >Or maybe more accurately, Commons doesn't have any libraries for this
> yet (not like we're limited to purely Javahere).
> > We have the unreleased Commons Functor. I believe this was the intention
> of the project, though it lost momentum.
>
> The site is outdated: link to the source repository returns 404.[1]
>
> > But some interesting code there that could be simplified and released if
> there's still interest.
>
> From a quick browsing of the documentation[2], it seems that a large chunk
> is now covered by the JDK's "java.util.function" package. If so, the
> first step
> would probably be a purge of everything that duplicates functionality
> available
> in standard classes.
>
> It would be most interesting to read what the developers who contributed
> to that component think.[3]
>
> Regards,
> Gilles
>
> [1]
> https://commons.apache.org/proper/commons-functor/source-repository.html
> [2] https://commons.apache.org/proper/commons-functor/apidocs/index.html
> [3] https://commons.apache.org/proper/commons-functor/team-list.html
>
> >
> > Bruno
> >
> > On Wednesday, 31 July 2019, 3:59:25 am NZST, Matt Sicker <
> boards@gmail.com> wrote:
> >
> > On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski <gi...@gmail.com>
> wrote:
> > > I certainly agree with Gary as to why "Commons" is not there being a
> > > practical issue (of no concerted road map and lacking developers to
> > > implement it). However, did I understand correctly that you consider
> > > such a development to be useless? I.e. rather than updating "Commons"
> > > do you suggest that application developers should not use it?
> >
> > I meant that writing Commons libraries for functional programming
> > still isn't possible with Java's limited generics and type system. I'm
> > talking about higher kinded types, dependent types, monads, functors,
> > etc. While there are some Java libraries out there that attempt to do
> > this [1] [2], there's no "natural" way to express type classes and
> > other functional programming concepts in Java. Considering the lack of
> > Kotlin and Scala libraries in Commons at the moment, I'd conclude that
> > this isn't the most appropriate place for functional programming
> > libraries at the moment. Or maybe more accurately, Commons doesn't
> > have any libraries for this yet (not like we're limited to purely Java
> > here).
> >
> > However, that isn't to say that Commons libraries can't offer anything
> > useful that relies on lambda functions, streams, completable futures,
> > etc., but that is a fairly limited subset of functional programming,
> > and any academic study looking at this should know that due to
> > familiarity with languages like Haskell where "real" functional
> > programming tends to take place still. Or maybe I'm misunderstanding
> > the point of this question entirely.
> >
> > [1]: https://www.functionaljava.org/
> > [2]: https://www.vavr.io/
> >
> > --
> > Matt Sicker <bo...@gmail.com>
--
Matt Sicker <bo...@gmail.com>
Re: [lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Posted by "Bruno P. Kinoshita" <ki...@apache.org>.
Hi Gilles
I can't speak for others, but I agree we would need to remove most of the code that is now available in Java 8. I think [functor] would need more a place for functional code that does not belong to lang, but is still useful to other devs & components.
Bruno
On Saturday, 3 August 2019, 1:48:50 am NZST, Gilles Sadowski <gi...@gmail.com> wrote:
Hello Bruno.
Le mer. 31 juil. 2019 à 08:05, Bruno P. Kinoshita <ki...@apache.org> a écrit :
>
> Hi,
>
> >Or maybe more accurately, Commons doesn't have any libraries for this yet (not like we're limited to purely Javahere).
> We have the unreleased Commons Functor. I believe this was the intention of the project, though it lost momentum.
The site is outdated: link to the source repository returns 404.[1]
> But some interesting code there that could be simplified and released if there's still interest.
From a quick browsing of the documentation[2], it seems that a large chunk
is now covered by the JDK's "java.util.function" package. If so, the first step
would probably be a purge of everything that duplicates functionality available
in standard classes.
It would be most interesting to read what the developers who contributed
to that component think.[3]
Regards,
Gilles
[1] https://commons.apache.org/proper/commons-functor/source-repository.html
[2] https://commons.apache.org/proper/commons-functor/apidocs/index.html
[3] https://commons.apache.org/proper/commons-functor/team-list.html
>
> Bruno
>
> On Wednesday, 31 July 2019, 3:59:25 am NZST, Matt Sicker <bo...@gmail.com> wrote:
>
> On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski <gi...@gmail.com> wrote:
> > I certainly agree with Gary as to why "Commons" is not there being a
> > practical issue (of no concerted road map and lacking developers to
> > implement it). However, did I understand correctly that you consider
> > such a development to be useless? I.e. rather than updating "Commons"
> > do you suggest that application developers should not use it?
>
> I meant that writing Commons libraries for functional programming
> still isn't possible with Java's limited generics and type system. I'm
> talking about higher kinded types, dependent types, monads, functors,
> etc. While there are some Java libraries out there that attempt to do
> this [1] [2], there's no "natural" way to express type classes and
> other functional programming concepts in Java. Considering the lack of
> Kotlin and Scala libraries in Commons at the moment, I'd conclude that
> this isn't the most appropriate place for functional programming
> libraries at the moment. Or maybe more accurately, Commons doesn't
> have any libraries for this yet (not like we're limited to purely Java
> here).
>
> However, that isn't to say that Commons libraries can't offer anything
> useful that relies on lambda functions, streams, completable futures,
> etc., but that is a fairly limited subset of functional programming,
> and any academic study looking at this should know that due to
> familiarity with languages like Haskell where "real" functional
> programming tends to take place still. Or maybe I'm misunderstanding
> the point of this question entirely.
>
> [1]: https://www.functionaljava.org/
> [2]: https://www.vavr.io/
>
> --
> Matt Sicker <bo...@gmail.com>
Re: [lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello Bruno.
Le mer. 31 juil. 2019 à 08:05, Bruno P. Kinoshita <ki...@apache.org> a écrit :
>
> Hi,
>
> >Or maybe more accurately, Commons doesn't have any libraries for this yet (not like we're limited to purely Javahere).
> We have the unreleased Commons Functor. I believe this was the intention of the project, though it lost momentum.
The site is outdated: link to the source repository returns 404.[1]
> But some interesting code there that could be simplified and released if there's still interest.
From a quick browsing of the documentation[2], it seems that a large chunk
is now covered by the JDK's "java.util.function" package. If so, the first step
would probably be a purge of everything that duplicates functionality available
in standard classes.
It would be most interesting to read what the developers who contributed
to that component think.[3]
Regards,
Gilles
[1] https://commons.apache.org/proper/commons-functor/source-repository.html
[2] https://commons.apache.org/proper/commons-functor/apidocs/index.html
[3] https://commons.apache.org/proper/commons-functor/team-list.html
>
> Bruno
>
> On Wednesday, 31 July 2019, 3:59:25 am NZST, Matt Sicker <bo...@gmail.com> wrote:
>
> On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski <gi...@gmail.com> wrote:
> > I certainly agree with Gary as to why "Commons" is not there being a
> > practical issue (of no concerted road map and lacking developers to
> > implement it). However, did I understand correctly that you consider
> > such a development to be useless? I.e. rather than updating "Commons"
> > do you suggest that application developers should not use it?
>
> I meant that writing Commons libraries for functional programming
> still isn't possible with Java's limited generics and type system. I'm
> talking about higher kinded types, dependent types, monads, functors,
> etc. While there are some Java libraries out there that attempt to do
> this [1] [2], there's no "natural" way to express type classes and
> other functional programming concepts in Java. Considering the lack of
> Kotlin and Scala libraries in Commons at the moment, I'd conclude that
> this isn't the most appropriate place for functional programming
> libraries at the moment. Or maybe more accurately, Commons doesn't
> have any libraries for this yet (not like we're limited to purely Java
> here).
>
> However, that isn't to say that Commons libraries can't offer anything
> useful that relies on lambda functions, streams, completable futures,
> etc., but that is a fairly limited subset of functional programming,
> and any academic study looking at this should know that due to
> familiarity with languages like Haskell where "real" functional
> programming tends to take place still. Or maybe I'm misunderstanding
> the point of this question entirely.
>
> [1]: https://www.functionaljava.org/
> [2]: https://www.vavr.io/
>
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Posted by "Bruno P. Kinoshita" <ki...@apache.org>.
Hi,
>Or maybe more accurately, Commons doesn't have any libraries for this yet (not like we're limited to purely Javahere).
We have the unreleased Commons Functor. I believe this was the intention of the project, though it lost momentum. But some interesting code there that could be simplified and released if there's still interest.
Bruno
On Wednesday, 31 July 2019, 3:59:25 am NZST, Matt Sicker <bo...@gmail.com> wrote:
On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski <gi...@gmail.com> wrote:
> I certainly agree with Gary as to why "Commons" is not there being a
> practical issue (of no concerted road map and lacking developers to
> implement it). However, did I understand correctly that you consider
> such a development to be useless? I.e. rather than updating "Commons"
> do you suggest that application developers should not use it?
I meant that writing Commons libraries for functional programming
still isn't possible with Java's limited generics and type system. I'm
talking about higher kinded types, dependent types, monads, functors,
etc. While there are some Java libraries out there that attempt to do
this [1] [2], there's no "natural" way to express type classes and
other functional programming concepts in Java. Considering the lack of
Kotlin and Scala libraries in Commons at the moment, I'd conclude that
this isn't the most appropriate place for functional programming
libraries at the moment. Or maybe more accurately, Commons doesn't
have any libraries for this yet (not like we're limited to purely Java
here).
However, that isn't to say that Commons libraries can't offer anything
useful that relies on lambda functions, streams, completable futures,
etc., but that is a fairly limited subset of functional programming,
and any academic study looking at this should know that due to
familiarity with languages like Haskell where "real" functional
programming tends to take place still. Or maybe I'm misunderstanding
the point of this question entirely.
[1]: https://www.functionaljava.org/
[2]: https://www.vavr.io/
--
Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Posted by Gary Gregory <ga...@gmail.com>.
I would love to see Kotlin and Java libraries in Commons.
Gary
On Tue, Jul 30, 2019, 11:59 Matt Sicker <bo...@gmail.com> wrote:
> On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski <gi...@gmail.com>
> wrote:
> > I certainly agree with Gary as to why "Commons" is not there being a
> > practical issue (of no concerted road map and lacking developers to
> > implement it). However, did I understand correctly that you consider
> > such a development to be useless? I.e. rather than updating "Commons"
> > do you suggest that application developers should not use it?
>
> I meant that writing Commons libraries for functional programming
> still isn't possible with Java's limited generics and type system. I'm
> talking about higher kinded types, dependent types, monads, functors,
> etc. While there are some Java libraries out there that attempt to do
> this [1] [2], there's no "natural" way to express type classes and
> other functional programming concepts in Java. Considering the lack of
> Kotlin and Scala libraries in Commons at the moment, I'd conclude that
> this isn't the most appropriate place for functional programming
> libraries at the moment. Or maybe more accurately, Commons doesn't
> have any libraries for this yet (not like we're limited to purely Java
> here).
>
> However, that isn't to say that Commons libraries can't offer anything
> useful that relies on lambda functions, streams, completable futures,
> etc., but that is a fairly limited subset of functional programming,
> and any academic study looking at this should know that due to
> familiarity with languages like Haskell where "real" functional
> programming tends to take place still. Or maybe I'm misunderstanding
> the point of this question entirely.
>
> [1]: https://www.functionaljava.org/
> [2]: https://www.vavr.io/
>
> --
> Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Posted by Matt Sicker <bo...@gmail.com>.
On Tue, 30 Jul 2019 at 08:50, Gilles Sadowski <gi...@gmail.com> wrote:
> I certainly agree with Gary as to why "Commons" is not there being a
> practical issue (of no concerted road map and lacking developers to
> implement it). However, did I understand correctly that you consider
> such a development to be useless? I.e. rather than updating "Commons"
> do you suggest that application developers should not use it?
I meant that writing Commons libraries for functional programming
still isn't possible with Java's limited generics and type system. I'm
talking about higher kinded types, dependent types, monads, functors,
etc. While there are some Java libraries out there that attempt to do
this [1] [2], there's no "natural" way to express type classes and
other functional programming concepts in Java. Considering the lack of
Kotlin and Scala libraries in Commons at the moment, I'd conclude that
this isn't the most appropriate place for functional programming
libraries at the moment. Or maybe more accurately, Commons doesn't
have any libraries for this yet (not like we're limited to purely Java
here).
However, that isn't to say that Commons libraries can't offer anything
useful that relies on lambda functions, streams, completable futures,
etc., but that is a fairly limited subset of functional programming,
and any academic study looking at this should know that due to
familiarity with languages like Haskell where "real" functional
programming tends to take place still. Or maybe I'm misunderstanding
the point of this question entirely.
[1]: https://www.functionaljava.org/
[2]: https://www.vavr.io/
--
Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le mar. 30 juil. 2019 à 15:38, Matt Sicker <bo...@gmail.com> a écrit :
>
> Yeah, Commons libraries are almost intentionally behind the times in order
> to provide functionality to the most people. Sometimes, Java even adds
> things that make a Commons library somewhat redundant in theory (like NIO2
> from Java 7 which could theoretically replace Commons VFS as an API).
>
> I can also say that personally, I can’t even think of a good Commons
> functional programming library that would be possible with the current
> limitations of the Java type system. Scala and now even Kotlin have a lot
> of interesting libraries in that space.
I certainly agree with Gary as to why "Commons" is not there being a
practical issue (of no concerted road map and lacking developers to
implement it). However, did I understand correctly that you consider
such a development to be useless? I.e. rather than updating "Commons"
do you suggest that application developers should not use it?
Regards,
Gilles
> On Tue, Jul 30, 2019 at 06:39, Gary Gregory <ga...@gmail.com> wrote:
>
> > Fernando,
> >
> > In general, it feels to me the Apache Commons community is split and slow
> > moving to adopt newer version of Java. Currently, updating the platform
> > requirements of a component to Java 8 causes some people to react with
> > "What about people running on Java 7?!" comments, or "What Java 8 features
> > are required? Why update Java if we don't need to?". Others, like me, would
> > prefer to move to Java 8 as the base version for all components, and build
> > on that, showing contributors that we are set up to accept code that
> > use modern language constructs like lambdas. We've had to reject or rework
> > some PRs because they depended on Java 8 APIs when the component was still
> > on Java 7, not a great position IMO.
> >
> > Argument for whether or not lambdas "improve readability" or is a debate I
> > care not to enter ;-)
> >
> > Gary
> >
> > On Tue, Jul 30, 2019 at 4:54 AM <f....@virgilio.it.invalid> wrote:
> >
> > > Dear Developers,
> > >
> > > we are members of the ZEST research group (Zurich Empirical Software
> > > Engineering Team) based at the University of Zurich and the Delft
> > > University of Technology. We are conducting an investigation on the
> > > diffusion of innovations and we focus on the adoption of new language
> > > features. Our research is focused on how API producers adapt their
> > > interfaces to introduce support for Java 8’s lambdas. During the course
> > of
> > > our investigation, we manually inspected commons-collections,
> > commons-text,
> > > and commons-lang’s source code and documentations to understand whether
> > > Java’s lambdas have widespread adoption. We would like to have your
> > > feedback on our findings.
> > >
> > > Our study focuses primarily on Functional Interfaces and Lambda
> > > Expressions as these new features were introduced by the Java language
> > and
> > > adopted the Java JDK API, as they reduce implementation complexity,
> > improve
> > > readability, offer performance benefits and improve security
> > > contextualization.
> > > Our analysis showed that though commons-collection 4.2, commons-text 1.7,
> > > and commons-lang3 3.9 did not explicitly introduce support for functional
> > > interfaces (e.g. by using the @FunctionalInterface annotation). We
> > noticed
> > > that the APIs provide compatibility with Java 8+ features, including
> > lambda
> > > expressions (since the APIs’s build platform is now on JDK 1.8+). We
> > would
> > > like to better understand as to why no major change was necessitated to
> > > facilitate the usage of lambda expressions with the API.
> > >
> > > In most cases, developers choose to move to new releases to satisfy
> > > particular dependency requirements, to take advantage of new Java
> > features
> > > (like streams and functional interfaces in the case of Java 8), or just
> > to
> > > standardize their implementation to align the API with the Java JDK API.
> > > Can you provide us with more information about this?
> > > How did you and your team tackle the choice to change the version of Java
> > > supported?
> > > Which factors did you take into account when doing this?
> > > Are there any documented sources (e.g. Jira tickets, or issue tracker
> > > issues) about that discussion you can provide us with?
> > > Why were no explicit changes made to the interface to support lambda
> > > expressions?
> > > Are there any future plans in place to make larger changes to the API
> > such
> > > that lambda expressions would be supported?
> > >
> > > We thank you for taking the time to answer our questions. If you would
> > > like to be posted about the results of this study, please let us know!
> > >
> > > Kind Regards,
> > > Fernando Petrulio.
> > >
> > >
> > > [photo-logo]
> > > Fernando Petrulio
> > > PhD Student University of Zurich UZH
> > > Department of Informatics
> > >
> > > [linkedin] https://www.linkedin.com/in/fernando-petrulio
> > >
> >
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Posted by Matt Sicker <bo...@gmail.com>.
Yeah, Commons libraries are almost intentionally behind the times in order
to provide functionality to the most people. Sometimes, Java even adds
things that make a Commons library somewhat redundant in theory (like NIO2
from Java 7 which could theoretically replace Commons VFS as an API).
I can also say that personally, I can’t even think of a good Commons
functional programming library that would be possible with the current
limitations of the Java type system. Scala and now even Kotlin have a lot
of interesting libraries in that space.
On Tue, Jul 30, 2019 at 06:39, Gary Gregory <ga...@gmail.com> wrote:
> Fernando,
>
> In general, it feels to me the Apache Commons community is split and slow
> moving to adopt newer version of Java. Currently, updating the platform
> requirements of a component to Java 8 causes some people to react with
> "What about people running on Java 7?!" comments, or "What Java 8 features
> are required? Why update Java if we don't need to?". Others, like me, would
> prefer to move to Java 8 as the base version for all components, and build
> on that, showing contributors that we are set up to accept code that
> use modern language constructs like lambdas. We've had to reject or rework
> some PRs because they depended on Java 8 APIs when the component was still
> on Java 7, not a great position IMO.
>
> Argument for whether or not lambdas "improve readability" or is a debate I
> care not to enter ;-)
>
> Gary
>
> On Tue, Jul 30, 2019 at 4:54 AM <f....@virgilio.it.invalid> wrote:
>
> > Dear Developers,
> >
> > we are members of the ZEST research group (Zurich Empirical Software
> > Engineering Team) based at the University of Zurich and the Delft
> > University of Technology. We are conducting an investigation on the
> > diffusion of innovations and we focus on the adoption of new language
> > features. Our research is focused on how API producers adapt their
> > interfaces to introduce support for Java 8’s lambdas. During the course
> of
> > our investigation, we manually inspected commons-collections,
> commons-text,
> > and commons-lang’s source code and documentations to understand whether
> > Java’s lambdas have widespread adoption. We would like to have your
> > feedback on our findings.
> >
> > Our study focuses primarily on Functional Interfaces and Lambda
> > Expressions as these new features were introduced by the Java language
> and
> > adopted the Java JDK API, as they reduce implementation complexity,
> improve
> > readability, offer performance benefits and improve security
> > contextualization.
> > Our analysis showed that though commons-collection 4.2, commons-text 1.7,
> > and commons-lang3 3.9 did not explicitly introduce support for functional
> > interfaces (e.g. by using the @FunctionalInterface annotation). We
> noticed
> > that the APIs provide compatibility with Java 8+ features, including
> lambda
> > expressions (since the APIs’s build platform is now on JDK 1.8+). We
> would
> > like to better understand as to why no major change was necessitated to
> > facilitate the usage of lambda expressions with the API.
> >
> > In most cases, developers choose to move to new releases to satisfy
> > particular dependency requirements, to take advantage of new Java
> features
> > (like streams and functional interfaces in the case of Java 8), or just
> to
> > standardize their implementation to align the API with the Java JDK API.
> > Can you provide us with more information about this?
> > How did you and your team tackle the choice to change the version of Java
> > supported?
> > Which factors did you take into account when doing this?
> > Are there any documented sources (e.g. Jira tickets, or issue tracker
> > issues) about that discussion you can provide us with?
> > Why were no explicit changes made to the interface to support lambda
> > expressions?
> > Are there any future plans in place to make larger changes to the API
> such
> > that lambda expressions would be supported?
> >
> > We thank you for taking the time to answer our questions. If you would
> > like to be posted about the results of this study, please let us know!
> >
> > Kind Regards,
> > Fernando Petrulio.
> >
> >
> > [photo-logo]
> > Fernando Petrulio
> > PhD Student University of Zurich UZH
> > Department of Informatics
> >
> > [linkedin] https://www.linkedin.com/in/fernando-petrulio
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [lang3][collection4][text] Investigation on the diffusion of
innovation along with java releases
Posted by Gary Gregory <ga...@gmail.com>.
Fernando,
In general, it feels to me the Apache Commons community is split and slow
moving to adopt newer version of Java. Currently, updating the platform
requirements of a component to Java 8 causes some people to react with
"What about people running on Java 7?!" comments, or "What Java 8 features
are required? Why update Java if we don't need to?". Others, like me, would
prefer to move to Java 8 as the base version for all components, and build
on that, showing contributors that we are set up to accept code that
use modern language constructs like lambdas. We've had to reject or rework
some PRs because they depended on Java 8 APIs when the component was still
on Java 7, not a great position IMO.
Argument for whether or not lambdas "improve readability" or is a debate I
care not to enter ;-)
Gary
On Tue, Jul 30, 2019 at 4:54 AM <f....@virgilio.it.invalid> wrote:
> Dear Developers,
>
> we are members of the ZEST research group (Zurich Empirical Software
> Engineering Team) based at the University of Zurich and the Delft
> University of Technology. We are conducting an investigation on the
> diffusion of innovations and we focus on the adoption of new language
> features. Our research is focused on how API producers adapt their
> interfaces to introduce support for Java 8’s lambdas. During the course of
> our investigation, we manually inspected commons-collections, commons-text,
> and commons-lang’s source code and documentations to understand whether
> Java’s lambdas have widespread adoption. We would like to have your
> feedback on our findings.
>
> Our study focuses primarily on Functional Interfaces and Lambda
> Expressions as these new features were introduced by the Java language and
> adopted the Java JDK API, as they reduce implementation complexity, improve
> readability, offer performance benefits and improve security
> contextualization.
> Our analysis showed that though commons-collection 4.2, commons-text 1.7,
> and commons-lang3 3.9 did not explicitly introduce support for functional
> interfaces (e.g. by using the @FunctionalInterface annotation). We noticed
> that the APIs provide compatibility with Java 8+ features, including lambda
> expressions (since the APIs’s build platform is now on JDK 1.8+). We would
> like to better understand as to why no major change was necessitated to
> facilitate the usage of lambda expressions with the API.
>
> In most cases, developers choose to move to new releases to satisfy
> particular dependency requirements, to take advantage of new Java features
> (like streams and functional interfaces in the case of Java 8), or just to
> standardize their implementation to align the API with the Java JDK API.
> Can you provide us with more information about this?
> How did you and your team tackle the choice to change the version of Java
> supported?
> Which factors did you take into account when doing this?
> Are there any documented sources (e.g. Jira tickets, or issue tracker
> issues) about that discussion you can provide us with?
> Why were no explicit changes made to the interface to support lambda
> expressions?
> Are there any future plans in place to make larger changes to the API such
> that lambda expressions would be supported?
>
> We thank you for taking the time to answer our questions. If you would
> like to be posted about the results of this study, please let us know!
>
> Kind Regards,
> Fernando Petrulio.
>
>
> [photo-logo]
> Fernando Petrulio
> PhD Student University of Zurich UZH
> Department of Informatics
>
> [linkedin] https://www.linkedin.com/in/fernando-petrulio
>