Our CloneDR tool finds duplicate code by comparing abstract syntax trees from parsers. (It comes in language versions for many languages, including Java and JavaScript).
This means that he can find the cloned code, despite the format changes and modifications to the clone body that are often performed during cloning. Clones found correspond to language concepts such as expression, declaration, statements, functions, and even classes. Reported clones, as expected, are reported along with differences / variation points.
It can find clone sets with multiple instances (we have several applications with hundreds of clones of one bit of code), and it can find clones in many source files.
It creates HTML reports that are directly read by people, and XML reports that can be processed by other downstream tools. (You can see some examples of HTML reports here).
Similarity is difficult to identify, and in fact you can define it in many ways. CloneDR defines it as the ratio of identical elements (technically, AST nodes) to a set of clones divided by the total number of elements in a set of clones. This ratio is a value from 0 to 1. It is compared with a threshold; we found that 95% is surprisingly reliable as a threshold in terms of the quality of reported clones.
It’s useful to set a minimum size for interesting clones. a*b is a clone of x*y (with two parameters), but it is not useful to report because it is too small. CloneDR also uses a size threshold, which we call "row count", but in fact it is the size of the clone in elements divided by the average number of elements per line throughout the code base. This creates clones that usually have more lines than the threshold, but he will find clones for the huge expressions that are inside the line. We found that 5-6 “lines” are also quite reliable in terms of clone quality.
This table shows how effective the AST compliance approach for CloneDR is compared to many other clone detection tools (rating “very good”). The only one that comes close is CCDIML .... which is an academic reorganization of the CloneDR approach. There are other approaches (in particular PDG-based approaches) that can detect more sensitive clones, but in practice, in my personal experience, people who clone the code usually don’t cut the cloned part into a bunch of separate parts to scatter them about; they are just too lazy. YMMV.
[Table from: Roy, Cordy, Koshke: Comparison and Evaluation of Methods and Tools for Detecting Code Cloning: A Qualitative Approach, Programming Science, Volume 74, Issue 7, May 2009. This article outlines many different methods for detecting clones and evaluates their effectiveness .]
[PMD is not listed, but using Rabin-Karp string matching, “text-based” according to the table above, not AST matching.]
Re OP:
CloneDR (and actually not a single tool that I know) will NOT find a set of similar methods for several methods if these methods occur in different orders in different classes. In this case, CloneDR is more likely to report individual methods as clones; the net result is the same. He will find such a set if the members are executed sequentially in the same order in different classes, as happens when one body of the class was optionally copied from another.
Similar code blocks in several methods are often found. The generated report shows how similar code blocks are linked, including an abstracted version of the code, which is essentially a parameterized code block that is needed for the method body.