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 <[email protected]> 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 <[email protected]> > 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
