[VOTE] Java Plugin version 2.3

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[VOTE] Java Plugin version 2.3

Nicolas Peru
Hi to all, 

This email is to launch the vote for the java plugin version 2.2.1

* This version contains improvement on semantic analysis based on bytecode allowing to provide some new rules such as : 
https://jira.codehaus.org/browse/SONARJAVA-497 Objects should be compared with "equals()"
https://jira.codehaus.org/browse/SONARJAVA-462 Java 8 : Use @FunctionalInterface annotation
https://jira.codehaus.org/browse/SONARJAVA-261 Method parameter should be used.


* Issues solved : 

You can test using the following snapshots : 










Vote is open for three days.

Thanks for your Feedback

Nicolas PERU | SonarSource
Senior Developer
http://sonarsource.com

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Java Plugin version 2.3

Nicolas Peru
Hi to all, 
Of course you should have read java plugin version 2.3. Sorry for typo.
Main improvement of this version is the adding of more than 10 rules (among which the ones mentioned in previous message). 

Vote is still open till wednesday. 
Thanks for your feedback. 




Nicolas PERU | SonarSource
Senior Developer
http://sonarsource.com



2014-06-20 16:07 GMT+02:00 Nicolas Peru <[hidden email]>:
Hi to all, 

This email is to launch the vote for the java plugin version 2.2.1

* This version contains improvement on semantic analysis based on bytecode allowing to provide some new rules such as : 
https://jira.codehaus.org/browse/SONARJAVA-497 Objects should be compared with "equals()"
https://jira.codehaus.org/browse/SONARJAVA-462 Java 8 : Use @FunctionalInterface annotation
https://jira.codehaus.org/browse/SONARJAVA-261 Method parameter should be used.


* Issues solved : 

You can test using the following snapshots : 










Vote is open for three days.

Thanks for your Feedback

Nicolas PERU | SonarSource
Senior Developer
http://sonarsource.com


Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Java Plugin version 2.3

Dennis Hartrampf
Hello Nicolas,

I am curious to see and test the new version, but all of your download links give a 404 error page.

Regards
Dennis
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Java Plugin version 2.3

Nicolas Peru
Hi dennis, 

Those links are usually available only three days sorry for that, you can download latest snapshot here : 







Cheers, 

Nicolas PERU | SonarSource
Senior Developer
http://sonarsource.com



2014-06-24 8:29 GMT+02:00 Dennis Hartrampf <[hidden email]>:
Hello Nicolas,

I am curious to see and test the new version, but all of your download links
give a 404 error page.

Regards
Dennis



--
View this message in context: http://sonarqube.15.x6.nabble.com/VOTE-Java-Plugin-version-2-3-tp5025918p5025987.html
Sent from the SonarQube Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Java Plugin version 2.3

Nicolas Peru
Hi to all, 

Vote is now closed and pass by lazy consensus. 
Release will follow shortly.

Cheers

Nicolas PERU | SonarSource
Senior Developer
http://sonarsource.com



2014-06-24 9:37 GMT+02:00 Nicolas Peru <[hidden email]>:
Hi dennis, 

Those links are usually available only three days sorry for that, you can download latest snapshot here : 







Cheers, 

Nicolas PERU | SonarSource
Senior Developer
http://sonarsource.com



2014-06-24 8:29 GMT+02:00 Dennis Hartrampf <[hidden email]>:

Hello Nicolas,

I am curious to see and test the new version, but all of your download links
give a 404 error page.

Regards
Dennis



--
View this message in context: http://sonarqube.15.x6.nabble.com/VOTE-Java-Plugin-version-2-3-tp5025918p5025987.html
Sent from the SonarQube Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Javascript SSLR rule help

Christoph Rönsch

Hi,

 

i wrote two SSLR rules (https://gist.github.com/croensch/5424bc6fc3024d94bf1f)

 

now, it seems sometimes the rule for matching assignments

(//initialiser|//assignmentExpression)//unaryExpression//IDENTIFIER[@tokenValue="undefined"]

 

also matches the checks like

if(nachricht == undefined){

  nachricht = data['nachricht'];

}

 

With the checking rule matching as well, I got two errors for one problem.

 

However it does only do that IN SonarQube on real code.

It does work as expected if I copy it into the SSLR toolkit…

 

Only sometimes tough… this works fine again (same rule)

if(object[name]['error'] == undefined){

    object[name]['error'] = new Array();

}

 

Not a big deal tough because we’ll get rid of any of this and I use both rules.

Just wanted to know if there is some differences between SSLR & Sonar itself (tested on 1.5 and 2.1)

 

Greetings,

Christoph




--
Hella Gutmann Solutions GmbH * Unternehmensform: Gesellschaft mit beschraenkter Haftung *
Firmensitz: 79241 Ihringen * Eingetragen im Handelsregister: AG Freiburg i.Br., HRB 290194 *
Geschaeftsfuehrer: Alfred Mayer, Bjoern Rietschel * USt-IdNr.: DE142208666
Reply | Threaded
Open this post in threaded view
|

Re: Javascript SSLR rule help

Linda Martin
Hi Christoph,

I was not able to reproduce the issue. Could you provide a screenshot please ?

To answer your question: there is no difference between the SSLR toolkit and Sonar itself, it uses exactly the same "engine".


Best regards,

-- 
Linda.


On 2 September 2014 14:59, Christoph Rönsch <[hidden email]> wrote:

Hi,

 

i wrote two SSLR rules (https://gist.github.com/croensch/5424bc6fc3024d94bf1f)

 

now, it seems sometimes the rule for matching assignments

(//initialiser|//assignmentExpression)//unaryExpression//IDENTIFIER[@tokenValue="undefined"]

 

also matches the checks like

if(nachricht == undefined){

  nachricht = data['nachricht'];

}

 

With the checking rule matching as well, I got two errors for one problem.

 

However it does only do that IN SonarQube on real code.

It does work as expected if I copy it into the SSLR toolkit…

 

Only sometimes tough… this works fine again (same rule)

if(object[name]['error'] == undefined){

    object[name]['error'] = new Array();

}

 

Not a big deal tough because we’ll get rid of any of this and I use both rules.

Just wanted to know if there is some differences between SSLR & Sonar itself (tested on 1.5 and 2.1)

 

Greetings,

Christoph




--
Hella Gutmann Solutions GmbH * Unternehmensform: Gesellschaft mit beschraenkter Haftung *
Firmensitz: 79241 Ihringen * Eingetragen im Handelsregister: AG Freiburg i.Br., HRB 290194 *
Geschaeftsfuehrer: Alfred Mayer, Bjoern Rietschel * USt-IdNr.: DE142208666

Reply | Threaded
Open this post in threaded view
|

AW: [sonar-user] Javascript SSLR rule help

Christoph Rönsch

Hi Linda,

 

i hope the screenshot is going out as attached. It also matches against a function call.

 

May it have something to do with the way I use the OR “( … | … )” ?

 

Best Regards,

Christoph

 

Von: Linda Martin [mailto:[hidden email]]
Gesendet: Mittwoch, 3. September 2014 14:50
An: [hidden email]
Betreff: Re: [sonar-user] Javascript SSLR rule help

 

Hi Christoph,

 

I was not able to reproduce the issue. Could you provide a screenshot please ?

 

To answer your question: there is no difference between the SSLR toolkit and Sonar itself, it uses exactly the same "engine".

 


Best regards,

 

-- 

Linda.

 

On 2 September 2014 14:59, Christoph Rönsch <[hidden email]> wrote:

Hi,

 

i wrote two SSLR rules (https://gist.github.com/croensch/5424bc6fc3024d94bf1f)

 

now, it seems sometimes the rule for matching assignments

(//initialiser|//assignmentExpression)//unaryExpression//IDENTIFIER[@tokenValue="undefined"]

 

also matches the checks like

if(nachricht == undefined){

  nachricht = data['nachricht'];

}

 

With the checking rule matching as well, I got two errors for one problem.

 

However it does only do that IN SonarQube on real code.

It does work as expected if I copy it into the SSLR toolkit…

 

Only sometimes tough… this works fine again (same rule)

if(object[name]['error'] == undefined){

    object[name]['error'] = new Array();

}

 

Not a big deal tough because we’ll get rid of any of this and I use both rules.

Just wanted to know if there is some differences between SSLR & Sonar itself (tested on 1.5 and 2.1)

 

Greetings,

Christoph

 



--
Hella Gutmann Solutions GmbH * Unternehmensform: Gesellschaft mit beschraenkter Haftung *
Firmensitz: 79241 Ihringen * Eingetragen im Handelsregister: AG Freiburg i.Br., HRB 290194 *
Geschaeftsfuehrer: Alfred Mayer, Bjoern Rietschel * USt-IdNr.: DE142208666

 




--
Hella Gutmann Solutions GmbH * Unternehmensform: Gesellschaft mit beschraenkter Haftung *
Firmensitz: 79241 Ihringen * Eingetragen im Handelsregister: AG Freiburg i.Br., HRB 290194 *
Geschaeftsfuehrer: Alfred Mayer, Bjoern Rietschel * USt-IdNr.: DE142208666


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

CheckVsAssigned.png (244K) Download Attachment
FunctionVsAssigned.png (93K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Javascript SSLR rule help

Linda Martin
Hi Christoph,

I got the screenshot thanks! 

So we need to zoom out a little bit from the code snippet you gave in the first mail. According to your screenshot we have the following:
component.search = function () {
    if (lastRequest !== undefined){
       //...
    }
}

So actually your XPath query works as expected because your if statement is nested in a function expression which itself is part of an assignment expression.
So it will result to a tree shaped like: 
. . .
|-- assignmentExpression
   |-- leftHandSideExpression
   |-- EQ
   |-- unaryExpression
     . . .
         |-- functionExpression
             |-- equalityExpression
              . . .
                 |-- unaryExpresion
                  . . .
                     |-- IDENTIFIER [tokenValue=Undefined]


which satisfies your XPath query.

A solution would be to explicitly define the whole path from assignmentExpression to the identifier (see below). But there will be some false negatives and it makes the query less readable: 
(//initialiser|//assignmentExpression)/unaryExpression/postfixExpression/leftHandSideExpression/newExpression/memberExpression/primaryExpression/IDENTIFIER[@tokenValue="undefined"]


Best regards,

-- 
Linda.


On 3 September 2014 17:45, Christoph Rönsch <[hidden email]> wrote:

Hi Linda,

 

i hope the screenshot is going out as attached. It also matches against a function call.

 

May it have something to do with the way I use the OR “( … | … )” ?

 

Best Regards,

Christoph

 

Von: Linda Martin [mailto:[hidden email]]
Gesendet: Mittwoch, 3. September 2014 14:50
An: [hidden email]
Betreff: Re: [sonar-user] Javascript SSLR rule help

 

Hi Christoph,

 

I was not able to reproduce the issue. Could you provide a screenshot please ?

 

To answer your question: there is no difference between the SSLR toolkit and Sonar itself, it uses exactly the same "engine".

 


Best regards,

 

-- 

Linda.

 

On 2 September 2014 14:59, Christoph Rönsch <[hidden email]> wrote:

Hi,

 

i wrote two SSLR rules (https://gist.github.com/croensch/5424bc6fc3024d94bf1f)

 

now, it seems sometimes the rule for matching assignments

(//initialiser|//assignmentExpression)//unaryExpression//IDENTIFIER[@tokenValue="undefined"]

 

also matches the checks like

if(nachricht == undefined){

  nachricht = data['nachricht'];

}

 

With the checking rule matching as well, I got two errors for one problem.

 

However it does only do that IN SonarQube on real code.

It does work as expected if I copy it into the SSLR toolkit…

 

Only sometimes tough… this works fine again (same rule)

if(object[name]['error'] == undefined){

    object[name]['error'] = new Array();

}

 

Not a big deal tough because we’ll get rid of any of this and I use both rules.

Just wanted to know if there is some differences between SSLR & Sonar itself (tested on 1.5 and 2.1)

 

Greetings,

Christoph

 



--
Hella Gutmann Solutions GmbH * Unternehmensform: Gesellschaft mit beschraenkter Haftung *
Firmensitz: 79241 Ihringen * Eingetragen im Handelsregister: AG Freiburg i.Br., HRB 290194 *
Geschaeftsfuehrer: Alfred Mayer, Bjoern Rietschel * USt-IdNr.: DE142208666

 




--
Hella Gutmann Solutions GmbH * Unternehmensform: Gesellschaft mit beschraenkter Haftung *
Firmensitz: 79241 Ihringen * Eingetragen im Handelsregister: AG Freiburg i.Br., HRB 290194 *
Geschaeftsfuehrer: Alfred Mayer, Bjoern Rietschel * USt-IdNr.: DE142208666


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email