[VOTE] Java plugin version 3.9

[Michael Gumowski]

Hello all,

We would like to release version 3.9 of the Java plugin.

Evgeny Mandrikov, Massimo Paladin, Didier Besset, Nicolas Peru and myself contributed to the version. Thanks for your work!

This version brings the following features:

• New set of 4 rules targeting maven pom files (tagged with "maven").
• S3419: Group ids should follow a naming convention
• S3420: Artifact ids should follow a naming convention
• S3422: Dependencies should not have "system" scope
• S3423: pom elements should be in the recommended order

Note: the feature requires the import of XML files to play the rules, which can be done by two approach:

• With SQ 5.1+, by turning on the import of unknown files for your projects (sonar.import_unknown_files=true).
• With any version of SQ: by installing our open source XML plugin, which will index any XML files, including maven pom files.

• Improved Symbolic Execution engine (incl. handling of try-catches), with major improvements regarding behavior of rules:
• S2583: Conditions should not unconditionally evaluate to "TRUE" or to "FALSE"
• S2222: Locks should be released
• S2095: Resources should be closed

• New API to simplify usage of Java Version in checks (org.sonar.plugins.java.api.JavaVersion)

• Numerous other bug fix and improvements, including notably:
• Analysis of nested binary expression will not raise parse time exponentially any more, thanks to Evgeny Mandrikov!
• Annotation on array type used as type parameters are now properly handled, thanks to Marc-Andre Laperle for raising the point!

Jira release note:

https://jira.sonarsource.com/jira/secure/ReleaseNote.jspa?projectId=10973&version=12852

You can test this version using the following snapshot:

https://github.com/SonarSource/sonar-java/releases/download/3.9-RC1/sonar-java-plugin-3.9-SNAPSHOT.jar

This vote will be open until the beginning of next year.

The java team wishes you a Merry Christmas and a happy new year!

Cheers,

Michael GUMOWSKI | SonarSource

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

[Massimo Paladin]

Hello,

we would like to change the version subject to vote with this new RC2 version:

https://github.com/SonarSource/sonar-java/releases/download/3.9-RC2/sonar-java-plugin-3.9-SNAPSHOT.jar

This second release candidate brings bug fixes, deprecation and removal of some API methods (SONARJAVA-1439 and SONARJAVA-1440), enable precise issue location on many rules (SONARJAVA-1437).

This vote will be open until the beginning of next year.

The java team wishes you a Merry Christmas and a happy new year!

Cheers,

Massimo PALADIN | 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/CABGmqnnzVRjgzP1mrMuC9q-jmgogNr2vMn72eoSckgH3jNPOkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Nicolas Peru]

Hi all, 

Vote is now closed and pass by lazy consensus. 

Release will happen shortly. 

Cheers, 

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

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

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

A little late, but I just did a test with the new version.

My custom plugin broke on the now removed complexity method, which used to be deprecated since 3.6.

I understand that at some point deprecated methods are removed, although I would have preferred if it was on major releases 3.x -> 4.x.

Since the alternative complexity method is not available in 3.1-.3.5, I either have to use a hack (reflection) or drop support for those versions.

The new rules did hit a lot on one of my projects. A JavaFX application we develop has a lot of hits on the rules:

- Inheritance tree of classes should not be too deep 

-> On UI classes that are extended and on exceptions hierarchy.

- Multiple variables should not be declared on the same line -> On classes that represent a table-pane, we declare all columns on one line.

It also found two new 'Resources should be closed', of which one is correct and one false positive (at first sight)

Op maandag 4 januari 2016 10:44:12 UTC+1 schreef Nicolas Peru:

[Nicolas Peru]

Hi Arjen, 

Thanks a lot for the feedback. A little bit late to the party for us to do anything on some of this. 

• Deprecation policy : We actually have no real deprecation policy on plugin side. Thanks for pointing this out, we will try to clarify that to avoid the same kind of pain in the near future (as 3.9 deprecates some methods reporting issues). 
• If you have differences in issue etc, would you mind detailing a bit where it is bothering you exactly. It is hard to pin point your issue from your message in order to eventually create a ticket for resolution (ideally, open a thread for each topic so we can close this one). Please also provide some code example if possible (and relevant). 

Cheers,

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/fb7e038d-7289-4b26-96f7-9e1b146acc9d%40googlegroups.com.

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

Hi,

I'm sorry, the last part of my reaction got lost. I would have voted positive for the release.

For the Depth of Inheritance Tree rule, the new issues are correct, I don't consider them false positive. We won't solve them, but I think the rule is ok.

- For UI related classes I think the rule is accurate, yes the inheritance of baseUI-classes does impose complexity, and you don't have much choice, but sometimes you just need to accept that as design choice (of a framework provider).

- You could however maybe make exceptions in the rule for 'extending Exceptions'. Since these are normally relative small classes, and the complexity of inheritance is limited.

The rule for 'Multiple variables should not be declared on the same line' is now disabled on my UI project. I think this is more of a style related rule, which I think has a purpose in most of my projects, but in UI classes it is better to have the declarations on one-line sometimes.

So this rule is also ok, just not applicable to all my projects.

The false positive on 'Resources should be closed' is something that maybe needs a fix.

The strange thing to me is that it does only complain about outputStream not inputStream.

        InputStream inputStream = null;

        FileOutputStream outputStream = null;

        try {

            inputStream = FileHelper.class.getResourceAsStream(resourceFile);

            outputStream = new FileOutputStream(file);

            // some copy code

        } finally {

            close(outputStream);

            close(inputStream);

        }

Regards,

Arjen

Op dinsdag 5 januari 2016 16:25:56 UTC+1 schreef Nicolas Peru: