Custom Rule Plugin - CompilationUnitTreeImpl ClassCastException

[Michael (Michael Gumowski)]

@jmcnally2020

Immediately out of the gate, the “JavaSymbol” class is no longer recognized (shown below). Do you have any API recommendations for doing the same thing with something that is supported with 6.1?

Yep, JavaSymbol was again an implementation class which has been dropped. Use Symbol.MethodSymbol instead (the same way you are using Symbol.TypeSymbol a few lines below).

@jmcnally2020

Would this do the trick in your opinion (or is best approach using your API)? Will be testing soon; however from your perspective, would this have an adverse impact?

That would do the trick, and that should not have any adverse impact. If you can not use anymore some method, it was anyway wrong, because these methods should have never been used at first.

@jmcnally2020

Secondly, do we need to have this dependency in our custom plugin? Currently it isn’t there and other than the issue we had, things worked fine.

Like I said earlier, you should have this ${java.plugin.version} property defined somewhere, or it would simply not work.

@jmcnally2020

Lastly sir, I took a direct Docker image initially for 7.9.5 and it came with the sonar-java version of 5.13.*. 7.9.6 came with 6.1. Out of curiosity, what are the ramifications (if any) by using sonar-java 5.13 in the 7.9.6 distribution?

• SQ 7.9.5 embed sonarjava 5.13.*, but you should update it through the SonarQube marketplace to sonarjava 6.3.2.*.
• You should then use API of java 6.3.2 as well. APIs from version 5.13 and 6.3 are absolutely not compatible.
• The ramifications are that if you make your plugin rely on API of 5.13, it simply won’t work with the future versions of SonarQube. Note that new LTS 8.9 just got released, and it embeds SonarJava 6.15.1.*. This last version is much closer to 6.3 in terms of API, and a world apart from 5.13.

Good luck with your changes,
Michael