[sonar-dev] Custom rule : Establishing the class hierarchy

[Alix LOURME]

Hi,

 

I try to optimize some custom rules about our company framework.

To apply some check, I need to verify if class extends a class (directly, or indirectly … the complex case).

 

In debug I can see that the “Classpath analyzed by Squid“ contains “target/classes” and my project Jars.

In unit test (Eclipse or Maven), this snippet works:

---

// Sample ...

Class.forName(tree.superClass().symbolType().fullyQualifiedName())

---

 

But on a real “mvn sonar:sonar”, the Classloader seems not to be the same … and  I have some ClassNotFoundException on the class in target/classes or jars.

 

=> Is there a way to establish the class hierarchy natively from java plugin (symbol, …), or a way to retrieve the squid classloader for the Class.forname ?

 

NB: java.class.path property contains only plexus-classworlds-2.5.1.jar  => root cause seems to be a Maven problem … but perhaps is there a solution J.

 

Thanks in advance.

Best Regards.

Alix.

[Nicolas Peru]

Hi Alix, 

I may have not understand very well what is your issue here but in order to verify the class hierarchy you can rely on semantic and use isSubtypeOf method like here : https://github.com/SonarSource/sonar-java/blob/master/java-checks/src/main/java/org/sonar/java/checks/IteratorNextExceptionCheck.java#L80

This will check if the type is a child of the verified type. 

Then if you have an issue with the provided bytecode, could you precise which versions of java plugin and maven plugin you are using ? 

Thanks. 

2015-05-05 18:55 GMT+02:00 ALIX LOURME <[hidden email]>:

Hi,

 

I try to optimize some custom rules about our company framework.

To apply some check, I need to verify if class extends a class (directly, or indirectly … the complex case).

 

In debug I can see that the “Classpath analyzed by Squid“ contains “target/classes” and my project Jars.

In unit test (Eclipse or Maven), this snippet works:

---

// Sample ...

Class.forName(tree.superClass().symbolType().fullyQualifiedName())

---

 

But on a real “mvn sonar:sonar”, the Classloader seems not to be the same … and  I have some ClassNotFoundException on the class in target/classes or jars.

 

=> Is there a way to establish the class hierarchy natively from java plugin (symbol, …), or a way to retrieve the squid classloader for the Class.forname ?

 

NB: java.class.path property contains only plexus-classworlds-2.5.1.jar  => root cause seems to be a Maven problem … but perhaps is there a solution J.

 

Thanks in advance.

Best Regards.

Alix.

[Alix LOURME]

Hi Nicolas,

 

Many thanks for this answer; this is exactly what I need!

It works perfectly ... this plugin is wonderful :-).

 

To precise my issue on the old "workaround method", with java plugin 3.2 and sonar-maven-plugin 2.6, I have this behavior on Class.forname:

---

// Works => framework class is in Squid classpath

tree.symbol().type().isSubtypeOf("com.company.MyFrameworkClass");

 

// Throw a ClassNotFoundException => strange ?

Class.forName("com.company.MyFrameworkClass");

---

But this is just for your information ... perhaps this classloader behavior (squid vs execution) is normal.

 

Best Regards.

De : Nicolas Peru [mailto:[hidden email]]
Envoyé : mercredi 6 mai 2015 08:19
À : /!\ Public dev ML
Objet : Re: [sonar-dev] Custom rule : Establishing the class hierarchy

 

Hi Alix, 

 

I may have not understand very well what is your issue here but in order to verify the class hierarchy you can rely on semantic and use isSubtypeOf method like here : https://github.com/SonarSource/sonar-java/blob/master/java-checks/src/main/java/org/sonar/java/checks/IteratorNextExceptionCheck.java#L80

This will check if the type is a child of the verified type. 

 

Then if you have an issue with the provided bytecode, could you precise which versions of java plugin and maven plugin you are using ? 

 

Thanks. 

 

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

 

 

2015-05-05 18:55 GMT+02:00 ALIX LOURME <[hidden email]>:

Hi,

 

I try to optimize some custom rules about our company framework.

To apply some check, I need to verify if class extends a class (directly, or indirectly … the complex case).

 

In debug I can see that the “Classpath analyzed by Squid“ contains “target/classes” and my project Jars.

In unit test (Eclipse or Maven), this snippet works:

---

// Sample ...

Class.forName(tree.superClass().symbolType().fullyQualifiedName())

---

 

But on a real “mvn sonar:sonar”, the Classloader seems not to be the same … and  I have some ClassNotFoundException on the class in target/classes or jars.

 

=> Is there a way to establish the class hierarchy natively from java plugin (symbol, …), or a way to retrieve the squid classloader for the Class.forname ?

 

NB: java.class.path property contains only plexus-classworlds-2.5.1.jar  => root cause seems to be a Maven problem … but perhaps is there a solution J.

 

Thanks in advance.

Best Regards.

Alix.

 

[Nicolas Peru]

2015-05-06 10:24 GMT+02:00 ALIX LOURME <[hidden email]>:

Hi Nicolas,

Hi, 

 

Many thanks for this answer; this is exactly what I need!

It works perfectly ... this plugin is wonderful :-).

Thanks :) 

 

 

To precise my issue on the old "workaround method", with java plugin 3.2 and sonar-maven-plugin 2.6, I have this behavior on Class.forname:

---

// Works => framework class is in Squid classpath

tree.symbol().type().isSubtypeOf("com.company.MyFrameworkClass");

 

// Throw a ClassNotFoundException => strange ?

Class.forName("com.company.MyFrameworkClass");

---

But this is just for your information ... perhaps this classloader behavior (squid vs execution) is normal.

 

Yes this is expected ! I understand now the confusion. 

We do not handle your project classpath as the analysis classpath (with the (big) exception for the jdk classes). This means that when we are reading semantic infromation from the classes you provided we are reading them as binary files and load them into our semantic model, we are not using any classloader mechanism for this. 

This allows us to avoid issues of conflicting libraries (Like if you are using a version of guava different of one of ours for instance)  that could lead to wrong semantic analysis. 

Cheers,