Re: Proposing various improvements
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 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 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 > > 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 isEnabled() 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-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Proposing various improvements
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 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 > 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 isEnabled() 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-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposing various improvements
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 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 isEnabled() 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-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: JDK 18 Release Candidate builds & JDK 19 Early-Access builds
Hi David, I just noticed that https://wiki.openjdk.java.net/display/quality/Quality+Outreach the Maven status for Java17 should be green. Confirmed via https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/ We used to test for LTS, current and next ea, but it seems the set has been reduced. I'll leave it up to the team if we can restore that. In the past we've already seen that doing that we could early respond to unexpected changes. thanks, Robert -- Oorspronkelijke bericht -- Van "David Delabassee" Aan rfscho...@apache.org CC dev@maven.apache.org Datum 28-2-2022 21:25:11 Onderwerp JDK 18 Release Candidate builds & JDK 19 Early-Access builds Robert, All, The Release Candidates of JDK 18 have been released [1]. At this stage, only P1 issues will be evaluated [2]. And with the JDK 18 General Availability sets for March 22nd, it is now time to shift the focus to JDK 19. I'd like to thank those of you who have already provided feedback on the early Early Builds of JDK 19. Feedback is always extremely useful, even more, when it comes early in the development cycle. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006404.html [2] https://openjdk.java.net/jeps/3 ## JDK 18 Release Candidate The Release Candidate builds of JDK 18 are now available [3], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [4]. [3] https://jdk.java.net/18/ [4] https://jdk.java.net/18/release-notes ## JDK 19 Early-Access builds JDK 19 Early-Access builds 11 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6]. [5] https://jdk.java.net/19/ [6] https://jdk.java.net/19/release-notes Recent changes that maybe of interest: * JDK-8278067: Make HttpURLConnection default keep alive timeout configurable * JDK-8281000: ClassLoader::registerAsParallelCapable throws NPE if caller is null * JDK-8282279: Interpret case-insensitive string locale independently * JDK-8176706: Support CLDR's Additional (Skeleton) Date-Time Formats * JDK-5041655: (ch) FileLock: negative param and overflow issues * JDK-8255266: Update Public Suffix List to 3c213aa * JDK-8280958: G1/Parallel: Unify marking code structure * JDK-8072070: Improve interpreter stack banging * JDK-8277175: Add a parallel multiply method to BigInteger * JDK-8278947: Support for array constants in constant table * JDK-8281462: Annotation toString output for enum not reusable for source input * JDK-8281175: Add a -providerPath option to jarsigner * JDK-8277795: ldap connection timeout not honoured under contention * JDK-8279842: HTTPS Channel Binding support for Java GSS/Kerberos * JDK-8280744: Allow SuppressWarnings to be used in all declaration contexts * JDK-8272984: javadoc support for reproducible builds * JDK-8272317: jstatd has dependency on Security Manager which needs to be removed ## New Project Loom Early-Access builds Project Loom Early-Access builds19-loom+4-115 (2022/2/13) are available [7] with the related Javadoc [8]. These EA builds are based on JDK 19 (jdk-19+9). In those builds, the APIs for Structured Concurrency and Scope Locals have been moved into the `jdk.incubator.concurrent` incubator module. Note that the module name may change later. To use those APIs, simply use `--add-modules jdk.incubator.concurrent` at compile and runtime. Those EA builds are provided under the GNU General Public License, version 2, with the Classpath Exception and are produced for the purpose of gathering feedback. Use for any other purpose is at your own risk. Proper feedback should be sent to the `loom-dev` mailing list [9]. [7] https://jdk.java.net/loom/ [8] https://download.java.net/java/early_access/loom/docs/api/ [9] https://mail.openjdk.java.net/mailman/listinfo/loom-dev ## Topics of Interest * JDK 18 - Card Table Card Size Shenanigans https://tschatzl.github.io/2022/02/15/card-table-card-size.html * Compiled & Tested Code In Javadoc - Inside Java Newscast #20 https://inside.java/2022/02/10/insidejava-newscast-020/ * New candidate JEP: 423: Region Pinning for G1 https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006368.html * Refactoring Java 8 code with Java 17 new features - JEP Café #9 https://inside.java/2022/02/01/jepcafe9/ As always, let us know if you find any issues while testing your projects on the latest JDK Early Access builds. Thanks for your support! --David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Final reminder: ApacheCon North America call for presentations closing soon
[Note: You're receiving this because you are subscribed to one or more Apache Software Foundation project mailing lists.] This is your final reminder that the Call for Presetations for ApacheCon North America 2022 will close at 00:01 GMT on Monday, May 23rd, 2022. Please don't wait! Get your talk proposals in now! Details here: https://apachecon.com/acna2022/cfp.html --Rich, for the ApacheCon Planners - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposing various improvements
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 isEnabled() 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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
