Re: [LANG] [DISCUSS] Java Modularity support in commons-lang3
Hi Mark, On 9.12.2024 17:37, Mark Struberg wrote: c) try using this on a class which contains e.g. an ArrayList, a Set or a Map. It will e.g. use List#equals() which also does equals() on it's items (btw, I explained this to you already...). Which is NOT what users expect. Instead it should iterate over the List and use ReflectionEquals on the elements. This is exactly what the PR does (amongst other things). Why would a user expect to use `reflectionEquals` on the elements of an internal list field? IMHO, if you run `reflectionEquals` on two objects of type A: * the caller must ensure that the fields of A are accessible. This requirement didn't change: previously the caller had to set the appropriate `SecurityManager` permissions, now he needs to set the appropriate JPMS permissions. * internal fields that are NOT of type A or Collection, should be compared using `equals()`. * internal fields that are of type A or Collection, can be compared using `reflectionEquals` if the users requests it. Piotr
Subject: Proposal: Standardizing String Concatenation in Apache Commons
Dear Apache Commons Community, In my recent PR #1332, I replaced a StringBuilder usage with string concatenation in a toString method for improved readability. During the review, it was suggested this change should align with a broader project standard. Would the community support using string concatenation over StringBuilder for simple cases? Modern JDKs (8+) optimize string concatenation efficiently, making it both concise and performant. If agreed, I can implement consistent changes across the codebase. Looking forward to your feedback! PR - https://github.com/apache/commons-lang/pull/1332
Re: Subject: Proposal: Standardizing String Concatenation in Apache Commons
Hello serwserw...@gmail.com, Thank you for your email. Here are a few questions: What passes the criteria of "simple cases"? Should this be enforced or can it be enforced? With Checkstyle? Somethings else? Considering: - that we support Java 8 and up to the current version. - that we don't say which Java vendor we support. - that the JLS (which version...) only suggests that a vendor could implement string concatenation using one of the Java stock classes. Is there a risk that changing to not using our unsynchronized class have performance side-effects? Ty! Gary On Sat, Dec 14, 2024, 10:08 AM Serw wrote: > Dear Apache Commons Community, > > In my recent PR #1332, I replaced a StringBuilder usage with string > concatenation in a toString method for improved readability. During the > review, it was suggested this change should align with a broader project > standard. > > Would the community support using string concatenation over StringBuilder > for simple cases? Modern JDKs (8+) optimize string concatenation > efficiently, making it both concise and performant. > > If agreed, I can implement consistent changes across the codebase. > > Looking forward to your feedback! > > PR - https://github.com/apache/commons-lang/pull/1332 >
Re: Subject: Proposal: Standardizing String Concatenation in Apache Commons
Hi Serw, On 13.12.2024 22:08, Serw wrote: Would the community support using string concatenation over StringBuilder for simple cases? Modern JDKs (8+) optimize string concatenation efficiently, making it both concise and performant. Since the Javac compiler replaces string concatenation with StringBuilder, I wouldn't expect any performance improvement (at least until we keep the JRE 8 compatibility). Personally I find concatenated strings more concise and easy to read, so I would be +1 for this change. There is even an OpenRewrite recipe[1] that can apply it automatically. Piotr [1] https://docs.openrewrite.org/recipes/staticanalysis/replacestringbuilderwithstring
Re: Subject: Proposal: Standardizing String Concatenation in Apache Commons
Hi Gary, On 14.12.2024 17:45, Gary Gregory wrote: What passes the criteria of "simple cases"? I would classify all sequences of `new StringBuilder()`, `append` and `toString` without any branching or loops as simple cases. Should this be enforced or can it be enforced? With Checkstyle? Somethings else? This can be enforced by running the OpenRewrite rule I mentioned before[1] on a regular basis and check that nothing was actually rewritten. The only problem with applying OpenRewrite rule is that they can break the formatting of the source code. Do we have an automated way to reformat the source code to conform to the CheckStyle rules? [1] https://docs.openrewrite.org/recipes/staticanalysis/replacestringbuilderwithstring Considering: - that we support Java 8 and up to the current version. - that we don't say which Java vendor we support. - that the JLS (which version...) only suggests that a vendor could implement string concatenation using one of the Java stock classes. Is there a risk that changing to not using our unsynchronized class have performance side-effects? There is no bytecode equivalent to string concatenation, so it is up to the compiler to translate string concatenations in methods calls. If you compile for Java 8 you'll end up using `StringBuilder`. If you compile for Java 9 or higher, you'll end up with a specialized lambda. Piotr
Re: Subject: Proposal: Standardizing String Concatenation in Apache Commons
On Sat, Dec 14, 2024 at 1:56 PM Piotr P. Karwasz wrote: > > Hi Gary, > > On 14.12.2024 17:45, Gary Gregory wrote: > > What passes the criteria of "simple cases"? > > I would classify all sequences of `new StringBuilder()`, `append` and > `toString` without any branching or loops as simple cases. Sounds reasonable. Maybe "no control flow" is "simple". > > > Should this be enforced or can it be enforced? With Checkstyle? Somethings > > else? > > This can be enforced by running the OpenRewrite rule I mentioned > before[1] on a regular basis and check that nothing was actually rewritten. > > The only problem with applying OpenRewrite rule is that they can break > the formatting of the source code. Do we have an automated way to > reformat the source code to conform to the CheckStyle rules? We do not. I use Eclipse, and some components have an Eclipse-formatted XML config file. This is not great and not as good as something like Spotless, which is used nowhere in Commons. It could be introduced in commons-parent. Gary > > [1] > https://docs.openrewrite.org/recipes/staticanalysis/replacestringbuilderwithstring > > > Considering: > > - that we support Java 8 and up to the current version. > > - that we don't say which Java vendor we support. > > - that the JLS (which version...) only suggests that a vendor could > > implement string concatenation using one of the Java stock classes. > > > > Is there a risk that changing to not using our unsynchronized class have > > performance side-effects? > > There is no bytecode equivalent to string concatenation, so it is up to > the compiler to translate string concatenations in methods calls. If you > compile for Java 8 you'll end up using `StringBuilder`. If you compile > for Java 9 or higher, you'll end up with a specialized lambda. > > Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Subject: Proposal: Standardizing String Concatenation in Apache Commons
On Sat, Dec 14, 2024 at 3:08 PM Serw wrote: > Would the community support using string concatenation over StringBuilder > for simple cases? Modern JDKs (8+) optimize string concatenation > efficiently, making it both concise and performant. Interesting. Do you have a reference for that? -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Subject: Proposal: Standardizing String Concatenation in Apache Commons
I presume this is referring to https://openjdk.org/jeps/280 (JEP 280: Indify String Concatenation) which was implemented in Java 9. On Sat, Dec 14, 2024, 6:26 PM Elliotte Rusty Harold wrote: > On Sat, Dec 14, 2024 at 3:08 PM Serw wrote: > > > Would the community support using string concatenation over StringBuilder > > for simple cases? Modern JDKs (8+) optimize string concatenation > > efficiently, making it both concise and performant. > > Interesting. Do you have a reference for that? > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
