I have taken a look at the PMD api which I want to use to detect unused instance variables and methods in a class. I see that it can be invoked from the command line, however I would like to perform a redundancy analysis of my class by invoking PMD programatically. Unfortunately, the api doesn't contain any information regarding the various classes and methods. Does anyone have any information regarding how PMD can be invoked to detect redundant code programatically?
Do you mean invoke it as a part of your build? It wouldn't make much sense to invoke PMD to analyze the source code during the runtime of the actual application.
Take a look at maven-pmd-plugin or the Ant task.
Related
I understand that there are static analysis tool e.g. FindBugs (there are bunch of them ) which do the code analysis statically and also can be scheduled as a part of continuous build process. These tool operate on a code part. A commenting is equally important, it would be great if the any discrepancy could be detected and reported to the concerned developer (as a part of build process).
I was looking for a capability wherein a tool could also flag the instances where appropriate comments are missing. I am referring to standard javadoc style comments like class, method etc.
According to an article I found, Checkstyle can do Javadoc validation
http://www.techrepublic.com/article/three-tools-that-make-java-code-review-painless-and-effective/5031836
... Unlike PMD, Checkstyle can check for Javadoc commenting; ...
I need to diagnose all invoked methods in a class(either declared in the class or not) using it's source code. Means that give the class source code to a method as an input and get the invoked method by the class as the output. In fact I need a class/method which operates same as java lexical analyzer .
Is there any method to diagnose all invoked methods ?
of course I tried to use Runtime.traceMethodCalls(); to solve the problem but there was no output. I've read I need to run java debug with java -g but unfortunately when I try to run java -g it makes error. Now what should I do ? Is there any approach ?
1) In the general case, no. Reflection will always allow the code to make method calls that you won't be able to analyze without actually running the code.
2) Tracing the method calls won't give you the full picture either, since a method is not in any way guaranteed (or even likely) to make all the calls it can every time you call it.
Your best bet is some kind of "best effort" code analysis. You may want to try enlisting the compiler's help with that. For example, compile the code and analyze the generated class file for all emitted external symbols. It won't guarantee catching every call (see #1), but it will get you close in most cases.
You can utilize one of the open source static analyzers for Java as a starting point. Checkstyle allows you to build your own modules. Soot has a pretty flexible API and a good example of call analysis. FindBugs might also allow you too write a custom module. AFAIK all three are embeddable in the form of a JAR, so you can incorporate whatever you come up with into your own custom program.
From your question it is hard to determine what is exactly problem you're trying to solve.
But in case:
If you want to analyze source code, to see which parts of it are redundant and may be removed, then you could use some IDE (Eclipse, IntelliJ IDEA Community Edition etc.) In IDE's you have features to search for usages of method and also you have functionality to analyze code and highlight unused methods as warnings/errors.
If you want to see where during runtime some method is called, then you could use profiling tool to collect information on those method invocations. Depending on tool you could see also from where those methods were called. But bare in mind, that when you execute program, then it is not guaranteed that your interesting method is called from every possible place.
if you are developing an automated tool for displaying calling graphs of methods. Then you need to parse source and start working with code entities. One way would be to implement your own compiler and go on from there. But easier way would be to reuse opensourced parser/compiler/analyzer and build your tool around it.
I've used IntelliJ IDEA CE that has such functionalitys and may be downloaded with source http://www.jetbrains.org/display/IJOS/Home
Also there is well known product Eclipse that has its sources available.
Both of these products have enormous code base, so isolating interesting part would be difficult. But it would still be easier than writing your own java compiler and werifying that it works for every corner case.
For analyzing the bytecode as mentioned above you could take a look at JBoss Bytecode. It is more for testing but may also be helpful for analyzing code.
sven.malvik.de
You may plug into the compiler.
Have a look the source of Project Lombok for instance.
There is no general mechanism, so they have one mechanism for javac and one for eclipse's compiler.
http://projectlombok.org/
I have quite shallow understanding of JUnit and Javassist, i just want to use them to do some program analysis. For example given a library, I want to know during the runtime what methods in the library have been invoked. I can use bytecode manipulation to insert a system.out.println("method_name"); statement in the beginning of a method. So during the runtime, it will print out what methods have been invoked.
In standalone application i can intercept before the main() is called and use my own class loader(see below), however in JUnit there is no main(), could anyone show me how to intercept at this situation?
Many thanks.
...
Loader loader = new Loader( pool );
loader.addTranslator( pool, xlat );
loader.run( className, args );
...
Edit: I use JUnit 4.8 and Javassist 3.15.0.GA
Might I recommend an alternative approach instead? You can use an aspect-oriented approach instead, using AspectJ. With that, you can define pointcuts around a subset of or all methods that you want to monitor.
Another option is, if you're looking to monitor code coverage (the fact that you're using JUnit and just looking to do System.out.println(...) are good hints of this), maybe you're looking for a code coverage tool? If so, Cobertura would be your best bet - with no custom coding required.
Both of these options do their own byte-code manipulation, but without being something that needs to be maintained by the developer.
If you're using Eclipse as your IDE, both of these tie-in very nicely to Eclipse. AspectJ is actually an Eclipse project, but doesn't require Eclipse. The Eclipse plug-in for Cobertura is eCobertura.
Yet another option for this is to do it within JUnit itself - and this wouldn't require any bytecode manipulation. Take a look at its TestWatchman class. I don't yet have this documented online as I do with my other libraries, but you could take a look at my BaseTest class as part of my JUnit utilities library. Any JUnit test class that extends this will automatically log (to SLF4J) when each test starts, succeeds, or fails. However, this is all at a test-level only, and won't help monitor other methods that each test runs.
We have huge codebase and some classes are often used via reflection all over the code. We can safely remove classes and compiler is happy, but some of them are used dynamically using reflection so I can't locate them otherwise than searching strings ...
Is there some reflection explorer for Java code?
No simple tool to do this. However you can use code coverage instead. What this does is give you a report of all the line of code executed. This can be even more useful in either improving test code or removing dead code.
Reflections is by definition very dynamic and you have to run the right code to see what it would do. i.e. you have to have reasonable tests. You can add logging to everything Reflection does if you can access this code, or perhaps you can use instrumentation of these libraries (or change them directly)
I suggest, using appropriately licensed source for your JRE, modifying the reflection classes to log when classes are used by reflection (use a map/WeakHashMap to ignore duplicates). Your modified system classes can replace those in rt.jar with -Xbootclasspath/p: on the command line (on Oracle "Sun" JRE, others will presumably have something similar). Run your program and tests and see what comes up.
(Possibly you might have to hack around issues with class loading order in the system classes.)
I doubt any such utility is readily available, but I could be wrong.
This is quite complex, considering that dynamically loaded classes (via reflection) can themselves load other classes dynamically and that the names of loaded classes may come from variables or some runtime input.
Your codebase probably does neither of these. If this a one time effort searching strings might be a good option. Or you look for calls to reflection methods.
As the other posters have mentioned, this cannot be done with static analysis due to the dynamic nature of Reflection. If you are using Eclipse, you might find this coverage tool to be useful, and it's very easy to work with. It's called EclEmma
Have you heard of any library which would allow me to set up tracing for specific methods at runtime?
Instead of adding (and removing) lots of System.out.println in my code (and having to re-compile and re-deploy) I would like to have a magic thing which would print out a line for each call of selected method without any change in the code. This would work without re-compiling, so some kind of JVM agent (or some non-standard JVM would be needed?). Sounds like a job for aspect programming?
A typical scenario would be to start an application, configure the traced methods dynamically (in a separate file or similar) and then everytime a selected method is called a line with its name (and arguments) is printed out to System.out (or some log file).
Naturally one could think of tens of additional features, but this basic set would be a great tool. BTW, I use Eclipse interactive debugger too, not only the System.out tracing technique, but both have some advantages and sometimes Eclipse is not enough.
Yes what you are referring to is known as Aspect oriented programming. A typical library providing this for Java is AspectJ. You define what are called pointcuts, essentially regular expressions for classes and method names, including wildcards, and the code to execute at each pointcut, known as an advice. This is useful for logging and also security checks and similar cross cutting concerns.
You can turn pointcut advices on and off through configuration. You can have an advice execute before a method call, after it returns or even after it throws an exception. Arguments are also available.
An aspectj java agent is needed for this to work.
In my experience, that kind of very detailed tracing (much more detailed than one would normally use for logging) as a debugging technique is indicative of insufficient unit testing and integration testing.
You can do this using a tool called InTrace.
NOTE: InTrace is a free and open source tool which I have written.
Log4J useful for disabling logging depending on "log-level" (DEBUG, INFO, WARN, FATAL).
You specify in configuration file what the least level you want to appear in logs, e.g., don't log anything below INFO level, and voila!
Looks like there's yet another solution - called Byteman. In their own words:
Byteman is a tool which simplifies tracing and testing of Java
programs. Byteman allows you to insert extra Java code into your
application, either as it is loaded during JVM startup or even after
it has already started running. The injected code is allowed to access
any of your data and call any application methods, including where
they are private. You can inject code almost anywhere you want and
there is no need to prepare the original source code in advance nor do
you have to recompile, repackage or redeploy your application. In fact
you can remove injected code and reinstall different code while the
application continues to execute.
Jackplay is the tool you are looking for.
It allows you to enable logging on method entry and exit points without any coding or redeployment.
It also allows redefining a method body. It gives you web based UI as control panel to enable or undo tracing on your class.methods.