You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Sebastien Doyon <do...@yahoo.ca.INVALID> on 2022/05/18 15:57:16 UTC
Proposing various improvements
Hi,
Recently I found some small potential improvements that could help clean the maven code. I would be glad to contribute it back to my most useful Java project, if you find it of interest.
The changes are mostly :
- Use of Collections.emptyList() instead of new ArrayList() when possible.
- Use of Collections.emptyMap() instead of new concrete Map object when possible
- Use of Collections.singletonList() instead of new concrete List object when possible
- Guarding logging statements with conditionals on isXXXXEnabled() to avoid garbage
- Replacing StringBuilder or StringBuffer usage when + operator is more appropriate
- Various small improvements
Please tell me if this is something that can be contributed to the Maven project and I will proceed with the creation a Jira ticket and GitHub PR. You can find the changes on this branch :
https://github.com/sebastien-doyon/maven/tree/codeImprovements2022
Please note that this would be my first contribution to the project and I would like to do more in the futur. I am looking forward for your comment/review.
Regards
Sebastien Doyon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Proposing various improvements
Posted by Gary Gregory <ga...@gmail.com>.
I am a Maven user and we have custom plugins we wrote over at Apache
Commons and this type of change has been painful in the past, see
https://issues.apache.org/jira/browse/MNG-7316
I do not think we can make a blanket statement like "everything is
immutable" without causing a world of pain.
Gary
On Thu, May 19, 2022, 07:32 Doyon Sebastien <se...@gmail.com> wrote:
> Hi Garry,
>
> I understand what you are saying. I though that there was a discussion
> about making the API immutable for mvn4. I also read that to modify some
> values on the API, the best practice was to replace the value (collection?)
> with a new one and not modify the actual one. What do you think?
>
> Regards
>
> > Le 19 mai 2022 à 13:23, Gary Gregory <ga...@gmail.com> a écrit :
> >
> > Bad idea unless you can look at each call site and _guarantee_ that you
> > want an immutable Collection instead of a mutable one... which I do not
> see
> > how you can do especially once a Collection escapes an API. Unless you're
> > ok with breaking behavioral compatibility...
> >
> > Gary
> >
> > On Thu, May 19, 2022, 02:34 Sebastien Doyon <do...@yahoo.ca.invalid>
> > wrote:
> >
> >> Hi,
> >>
> >> Recently I found some small potential improvements that could help clean
> >> the maven code. I would be glad to contribute it back to my most useful
> >> Java project, if you find it of interest.
> >>
> >> The changes are mostly :
> >>
> >> - Use of Collections.emptyList() instead of new ArrayList() when
> possible.
> >> - Use of Collections.emptyMap() instead of new concrete Map object when
> >> possible
> >> - Use of Collections.singletonList() instead of new concrete List object
> >> when possible
> >> - Guarding logging statements with conditionals on isXXXXEnabled() to
> >> avoid garbage
> >> - Replacing StringBuilder or StringBuffer usage when + operator is more
> >> appropriate
> >> - Various small improvements
> >>
> >> Please tell me if this is something that can be contributed to the Maven
> >> project and I will proceed with the creation a Jira ticket and GitHub
> PR.
> >> You can find the changes on this branch :
> >>
> >> https://github.com/sebastien-doyon/maven/tree/codeImprovements2022
> >>
> >> Please note that this would be my first contribution to the project and
> I
> >> would like to do more in the futur. I am looking forward for your
> >> comment/review.
> >>
> >> Regards
> >>
> >> Sebastien Doyon
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Proposing various improvements
Posted by Doyon Sebastien <se...@gmail.com>.
Hi Garry,
I understand what you are saying. I though that there was a discussion about making the API immutable for mvn4. I also read that to modify some values on the API, the best practice was to replace the value (collection?) with a new one and not modify the actual one. What do you think?
Regards
> Le 19 mai 2022 à 13:23, Gary Gregory <ga...@gmail.com> a écrit :
>
> Bad idea unless you can look at each call site and _guarantee_ that you
> want an immutable Collection instead of a mutable one... which I do not see
> how you can do especially once a Collection escapes an API. Unless you're
> ok with breaking behavioral compatibility...
>
> Gary
>
> On Thu, May 19, 2022, 02:34 Sebastien Doyon <do...@yahoo.ca.invalid>
> wrote:
>
>> Hi,
>>
>> Recently I found some small potential improvements that could help clean
>> the maven code. I would be glad to contribute it back to my most useful
>> Java project, if you find it of interest.
>>
>> The changes are mostly :
>>
>> - Use of Collections.emptyList() instead of new ArrayList() when possible.
>> - Use of Collections.emptyMap() instead of new concrete Map object when
>> possible
>> - Use of Collections.singletonList() instead of new concrete List object
>> when possible
>> - Guarding logging statements with conditionals on isXXXXEnabled() to
>> avoid garbage
>> - Replacing StringBuilder or StringBuffer usage when + operator is more
>> appropriate
>> - Various small improvements
>>
>> Please tell me if this is something that can be contributed to the Maven
>> project and I will proceed with the creation a Jira ticket and GitHub PR.
>> You can find the changes on this branch :
>>
>> https://github.com/sebastien-doyon/maven/tree/codeImprovements2022
>>
>> Please note that this would be my first contribution to the project and I
>> would like to do more in the futur. I am looking forward for your
>> comment/review.
>>
>> Regards
>>
>> Sebastien Doyon
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Proposing various improvements
Posted by Gary Gregory <ga...@gmail.com>.
Bad idea unless you can look at each call site and _guarantee_ that you
want an immutable Collection instead of a mutable one... which I do not see
how you can do especially once a Collection escapes an API. Unless you're
ok with breaking behavioral compatibility...
Gary
On Thu, May 19, 2022, 02:34 Sebastien Doyon <do...@yahoo.ca.invalid>
wrote:
> Hi,
>
> Recently I found some small potential improvements that could help clean
> the maven code. I would be glad to contribute it back to my most useful
> Java project, if you find it of interest.
>
> The changes are mostly :
>
> - Use of Collections.emptyList() instead of new ArrayList() when possible.
> - Use of Collections.emptyMap() instead of new concrete Map object when
> possible
> - Use of Collections.singletonList() instead of new concrete List object
> when possible
> - Guarding logging statements with conditionals on isXXXXEnabled() to
> avoid garbage
> - Replacing StringBuilder or StringBuffer usage when + operator is more
> appropriate
> - Various small improvements
>
> Please tell me if this is something that can be contributed to the Maven
> project and I will proceed with the creation a Jira ticket and GitHub PR.
> You can find the changes on this branch :
>
> https://github.com/sebastien-doyon/maven/tree/codeImprovements2022
>
> Please note that this would be my first contribution to the project and I
> would like to do more in the futur. I am looking forward for your
> comment/review.
>
> Regards
>
> Sebastien Doyon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Proposing various improvements
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Sebastien,
On 18.05.22 17:57, Sebastien Doyon wrote:
> Hi,
>
> Recently I found some small potential improvements that could help clean the maven code. I would be glad to contribute it back to my most useful Java project, if you find it of interest.
>
> The changes are mostly :
>
> - Use of Collections.emptyList() instead of new ArrayList() when possible.
> - Use of Collections.emptyMap() instead of new concrete Map object when possible
> - Use of Collections.singletonList() instead of new concrete List object when possible
It depends on where this changes can/should be done?..
> - Guarding logging statements with conditionals on isXXXXEnabled() to avoid garbage
In which way?
> - Replacing StringBuilder or StringBuffer usage when + operator is more appropriate
> - Various small improvements
>
> Please tell me if this is something that can be contributed to the Maven project and I will proceed with the creation a Jira ticket and GitHub PR. You can find the changes on this branch :
I would suggest that you first create a JIRA issue and start with small
improvements... and create a PR for that to start the process..
>
> https://github.com/sebastien-doyon/maven/tree/codeImprovements2022
I've taken a look at that repo but unfortunately I can't see any
change... apart from that the repo is not in sync with the current
master of Maven.
BTW: You email does not work..
Kind regards
Karl Heinz
>
> Please note that this would be my first contribution to the project and I would like to do more in the futur. I am looking forward for your comment/review.
>
> Regards
>
> Sebastien Doyon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org