[RFF] Java Analyzer 3.14

[Nicolas Peru]

Hi all, 

we are requesting your feedback on the new java version 3.14 aka the Pi release !

This version brings many improvement on the semantic analysis : mainly the resolution of lambas and its parameters and method references, first step towards having those not raising FP on unused private methods.

It also brings 4 new rules and numerous bug fixes.

Note also that compatibility has been upgraded to Latest LTS : 4.5.7 

Thanks Michael Gumowski for his work on this release.

Tickets fixed & Release notes

Tests can be made with this release candidate : 

https://github.com/SonarSource/sonar-java/releases/tag/3.14-RC1

As there was a lot of improvements on semantic analysis we strongly encourage you to test this version and report us any false positive or odd behavior you may encounter ! 

Thanks a lot in advance for your feedback that help us to improve the analyzer !

Vote is open until friday. 

Cheers,

--

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

[jtie...@gmail.com]

Hi,

Great to see that you guys worked on the Lambda processing, very interesting to see how those changes will affect on my personal projects (will do an analysis later on my hobby projects). Now the results on the company projects (which are significantly larger than my hobby project):

SonarQube: 5.5
Runner: maven 3.3.9

Code base: 80K (Java 8)
LGTM (No changes compared to the 3.13.1 analysis)

Code base: 200K LOC (Java 6)
Couple of new hits on the 'File.delete()' calls (expected)
One regression on 'S2259'. 3.14 reports a FP where as 3.13.1 does not (and which my logic says it's a FP).

Reproducer:

public static Field getField(final Class target, final String fieldName) throws NoSuchFieldException {
    Class<?> classToIntrospect = target;
    NoSuchFieldException error = null;

    do {
        try {
            // If target is null, it will produce a NPE here on the first iteration (You decide whether this is a FN).
            // This method either returns or throws an exception causing the flow the be disrupted.
            return classToIntrospect.getDeclaredField(fieldName);
        } catch (NoSuchFieldException nsfe) {
            // On the first exception we'll record it.
            if (error == null) {
                error = nsfe;
            }

            classToIntrospect = classToIntrospect.getSuperclass();
        }
    } while (classToIntrospect != null);

    // At this point there either has been a clean exit by the return or at least one exception, can't be null. FP
    throw error;
}

I've altered the comments to explain my reasoning to think that it's not a NPE. Feel free to comment if my logic is incorrect.

Greetings,

Johnnei.

[Michael Gumowski]

Hello Johan,

Thanks a lot for your feedback and the reproducer!

About the issue related to S2259, it's indeed a FP related to the JIRA ticket SONARJAVA-1422.

We still have to improve our handling of try-catch flows in our CFG (Control Flow Graph), but we won't be able to fix it for version 3.14.

However, note that there is no FN in your code, as we do the assumption that the provided parameter is not null (as not being annotated with @Nullable)

Regards,

Michael GUMOWSKI | SonarSource

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

--
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/a50bed63-901a-42bd-bc0c-5462fec984df%40googlegroups.com.

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

[Michael Gumowski]

@Johan: I just forgot to mention that these issues are only appearing in 3.14, as prior to this version we were not looking at throw statements for potential NPEs.

This has been fixed while resolving JIRA ticket SONARJAVA-1649, but it also revealed a flaw in our CFG.

Michael GUMOWSKI | SonarSource

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

[arjen.v...@gmail.com]

Hi,

Since the plugin now only supports 4.5.7, and my servers are still on 4.5.4, I can't test it for my projects on the short term.

So I tried to see if the unit-tests of my custom rules still work.

But those now provide an error 'failed to download json file for rule ...' on the line:

JavaCheckVerifier.verify(testFile, new UnitSizeCheck());

Any ideas what went wrong ?

Regards,

Arjen

Op woensdag 18 mei 2016 12:13:53 UTC+2 schreef Nicolas Peru:

[Nicolas Peru]

Hi Arjen, 

Thanks for the feedback. I am pretty sure it is linked to https://jira.sonarsource.com/browse/SONARJAVA-1431 

Would you be able to share the full stack trace of the error ? 

Thanks,

Cheers, 

--

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/df7b800e-dc23-4c7f-817e-9c1cb5d0fd84%40googlegroups.com.

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

[arjen.v...@gmail.com]

Sure, 

java.lang.AssertionError: Failed to open json file for rule UnitSizeMarker 

at org.fest.assertions.Fail.failure(Fail.java:228)

at org.fest.assertions.Fail.fail(Fail.java:198)

at org.sonar.java.checks.verifier.CheckVerifier.isLinear(CheckVerifier.java:205)

at org.sonar.java.checks.verifier.CheckVerifier.assertMultipleIssue(CheckVerifier.java:177)

at org.sonar.java.checks.verifier.CheckVerifier.checkIssues(CheckVerifier.java:170)

at org.sonar.java.checks.verifier.JavaCheckVerifier.scanFile(JavaCheckVerifier.java:237)

at org.sonar.java.checks.verifier.JavaCheckVerifier.scanFile(JavaCheckVerifier.java:220)

at org.sonar.java.checks.verifier.JavaCheckVerifier.scanFile(JavaCheckVerifier.java:216)

at org.sonar.java.checks.verifier.JavaCheckVerifier.verify(JavaCheckVerifier.java:99)

at sonarplugin.checks.TestViolations.detectedSize(TestViolations.java:25)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:483)

at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)

at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)

at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)

at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)

at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)

at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)

at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)

at org.junit.runners.ParentRunner.run(ParentRunner.java:309)

at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)

at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

Caused by: java.io.IOException

at org.sonar.java.checks.verifier.CheckVerifier.isLinear(CheckVerifier.java:200)

... 30 more

Op vrijdag 20 mei 2016 10:50:56 UTC+2 schreef Nicolas Peru:

[Nicolas Peru]

Hi, 

Thanks a _lot_ for this one ! This is linked to the ticket I mentioned where we migrated rule metadatas in external files to automate their handling. 

The issue is that doing so I introduced some verification which are failing a bit too much regarding the current API you are using (to put it clearly: I broke the API). This is the relevant piece of code.

Ticket created and I'll fix it right away and create a new RC. 

Once again, thanks for catching this one ! 

Cheers, 

Le ven. 20 mai 2016 à 10:46, <arjen.v...@gmail.com> a écrit :

--

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/df7b800e-dc23-4c7f-817e-9c1cb5d0fd84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Gumowski]

Hey all,

We fixed the API used to check custom rules, and are consequently providing a new version as release candidate.

This versions also fix FPs related to unused local variables in try-catch blocks (SONARJAVA-1690).

Tests can be made with this 2nd release candidate : 

https://github.com/SonarSource/sonar-java/releases/tag/3.14-RC2

Regards,

Michael GUMOWSKI | SonarSource

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/CAFHtbL2pzfJZTRTJ4VPoF7wG3bhqVwYn8LROdcgquBr4DzJp5g%40mail.gmail.com.

[arjen.v...@gmail.com]

Hi,

The unit-tests of my custom rules are working again with RC-2.

Regards,

Arjen

Op vrijdag 20 mei 2016 15:29:54 UTC+2 schreef Michael Gumowski:

[jtie...@gmail.com]

Executed the scans again on the company projects and on my hobby project: LGTM.

[Nicolas Peru]

Hi all, 

Feedback period is now over, thanks a lot for all your precious feedback.

(Thanks especially to Johnnei and Arjen) 

Release should happen shortly. 

A side note : This version will be the last one compatible with SonarQube LTS 4.5.7 , next java plugin release will require SonarQube LTS 5.6 which is in feedback period at the time I am writing this email.

Cheers,