@Rebse，Thank you a lot for your answer.
We introduced the Sonar rules to our Java project on 7th Oct.2017, and integrated it into Jenkins to guarantee the code quality with continuous inspection. From this day onwards, any code changes get push to gerrit, the Jenkins job will be triggered, and the changes will be analyzed via the SonarQube. For instance, if the code change call any deprecated API, SonarQube will detect and raise warnings, this feature is already in SonarAnalyzer, which is called " “@Deprecated” code should not be used".
If we deprecate a method, and push this change to gerrit, how does SonarQube analyze if that deprecated method has been used by the existing code base?
That is to say, if we deprecate a method/class/interface, how does SonarQube help us check if any part(method, class,interface) of the current project still use the just deprecated API?
I made some investigation these days, and found that it is not feasible to develop a custom sonar rule to meet such a requirement. SonarQube Java Analyzer parses a given Java code file and produces an equivalent data structure: the Syntax Tree . Each construction of the Java language can be represented with a specific kind of Syntax Tree, and the Syntax tree is on a Class/Interface/Enum level, in other words, it is on a Java file level.
When we need to write such a rule to analyzing the existing code base, we need to scan the whole project and check every method/class/interface to see if they ever use the deprecated API, which is not feasible to implement in SonarQube.
What do you think? Could you please give some suggestion?