S2629: "Preconditions" and logging arguments should not require evaluation --> effectively-final

[Sandra Knerer]

Hi together,

I found a problem in rule S2629 ("Preconditions" and logging arguments should not require evaluation). The rule raises an issue, when it is not possible to use it as a Supplier. If a variable isn't final or effectively-final it cannot be used in a Supplier.




SonarJava: 4.10.0.10260
SonarQube: 6.4.0.25310

Greetings Sandra


[Michael Gumowski]

Hello Sandra,

I'm not sure to follow you, as far as I can tell, your screenshot does not show a FP from the SonarJava rule itself, but the error message provided by eclipse IDE on a code which does not compile (of course due to "test" being not effectively final).

I guess you ended up with this code after modifying the code, but it would have been maybe easier if you would have provided the code generating the SonarJava issue, prior to the modification. I guess it's something similar to this:

In such case, the issue message is indeed not relevant and using a Supplier won't be possible. 

Now, the essence of the rule is to not evaluate logging arguments, in order to not needlessly impact performance. As suggested in the compliant solutions from rule descriptions, another approach is to check log level before actually logging:

if(LOGGER.isLoggable(Level.FINE)) {
  LOGGER.fine("test = " + test);
}

This code won't raise an issue of S2629.

Anyway, I created the following ticket to reword issue messages in such case: SONARJAVA-2380

Cheers,

Michael

On Mon, 10 Jul 2017 at 11:39 Sandra Knerer <sandra...@gmail.com> wrote:

Hi together,

I found a problem in rule S2629 ("Preconditions" and logging arguments should not require evaluation). The rule raises an issue, when it is not possible to use it as a Supplier. If a variable isn't final or effectively-final it cannot be used in a Supplier.

SonarJava: 4.10.0.10260
SonarQube: 6.4.0.25310

Greetings Sandra


--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/3a6aa709-ea7c-4527-b941-2f539e4fdf1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael Gumowski | SonarSource

Software Developer, Language Team
http://sonarsource.com

[Sandra Knerer]

Hi Michael,

you understand me right. Yesterday I spoke with my colleagues and they said that it's very easy to make a variable effectively-final. It is quite sufficient to assign the value of the variable to a new variable.This costs less performance than if a string has to be assembled each time. Thanks a lot for you detailed reply.

Greeting Sandra

[Michael Gumowski]

Hello Sandra,

Thanks for the followup. I also figured out that another approach could have been to use the following syntax, allowing usage of the variable without requiring it to be effectively final:

java.util.logging.Logger.getLogger(A.class.getName()).log(java.util.logging.Level.FINE, "test = {}", test);

I updated description of the rule to also contain a case similar to yours, with this solution.

Cheers,

Michael

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/4e8e2481-6a9b-48b9-b405-4a021e79fda8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.