It might sound a little bit weird, but I am looking for a possibility to test if some statements in the code are rejected by the typechecker (which means that the code should NOT compile).
Be explain my intend: I am running a controlled experiment on type-systems where my subjects have to write some methods in java for me. The functionality of the methods written by the subjects can be easily tested using unit-tests, but I also want the methods to be well-typed (which means that some methodcalls should not be allowed).
One way I could imagine to achieve that would be writing the statements which should break the build into a seperate file, add it to the classpath and run javac to see if any error occurs during the build. Although this might work, it does not feel very sophisticated, so my question is: Is there any better way to (automatically) test if some statements are refected by the typechecker?
This is a variation of the Halting Problem, which isn't solvable in the general case. To do this, you have to run (or in this case compile) the code. Therefore, the solution you've already proposed is the best solution.
Have you looked at the Checker Framework? It can be used to static code analysis and more. It might be a good fit for what's you are doing. Here is the link on my answer with an example of the annotation type processor.
Also you may find the Java Compiler API quite helpful. It allows to execute javac programmatically in a single java machine. So you could use it as a part of your tests.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
What tools do you use to find unused/dead code in large java projects? Our product has been in development for some years, and it is getting very hard to manually detect code that is no longer in use. We do however try to delete as much unused code as possible.
Suggestions for general strategies/techniques (other than specific tools) are also appreciated.
Edit: Note that we already use code coverage tools (Clover, IntelliJ), but these are of little help. Dead code still has unit tests, and shows up as covered. I guess an ideal tool would identify clusters of code which have very little other code depending on it, allowing for docues manual inspection.
An Eclipse plugin that works reasonably well is Unused Code Detector.
It processes an entire project, or a specific file and shows various unused/dead code methods, as well as suggesting visibility changes (i.e. a public method that could be protected or private).
CodePro was recently released by Google with the Eclipse project. It is free and highly effective. The plugin has a 'Find Dead Code' feature with one/many entry point(s). Works pretty well.
I would instrument the running system to keep logs of code usage, and then start inspecting code that is not used for months or years.
For example if you are interested in unused classes, all classes could be instrumented to log when instances are created. And then a small script could compare these logs against the complete list of classes to find unused classes.
Of course, if you go at the method level you should keep performance in mind. For example, the methods could only log their first use. I dont know how this is best done in Java. We have done this in Smalltalk, which is a dynamic language and thus allows for code modification at runtime. We instrument all methods with a logging call and uninstall the logging code after a method has been logged for the first time, thus after some time no more performance penalties occur. Maybe a similar thing can be done in Java with static boolean flags...
I'm suprised ProGuard hasn't been mentioned here. It's one of the most mature products around.
ProGuard is a free Java class file shrinker, optimizer, obfuscator,
and preverifier. It detects and removes unused classes, fields,
methods, and attributes. It optimizes bytecode and removes unused
instructions. It renames the remaining classes, fields, and methods
using short meaningless names. Finally, it preverifies the processed
code for Java 6 or for Java Micro Edition.
Some uses of ProGuard are:
Creating more compact code, for smaller code archives, faster transfer across networks, faster loading, and smaller memory
footprints.
Making programs and libraries harder to reverse-engineer.
Listing dead code, so it can be removed from the source code.
Retargeting and preverifying existing class files for Java 6 or higher, to take full advantage of their faster class loading.
Here example for list dead code: https://www.guardsquare.com/en/products/proguard/manual/examples#deadcode
One thing I've been known to do in Eclipse, on a single class, is change all of its methods to private and then see what complaints I get. For methods that are used, this will provoke errors, and I return them to the lowest access level I can. For methods that are unused, this will provoke warnings about unused methods, and those can then be deleted. And as a bonus, you often find some public methods that can and should be made private.
But it's very manual.
Use a test coverage tool to instrument your codebase, then run the application itself, not the tests.
Emma and Eclemma will give you nice reports of what percentage of what classes are run for any given run of the code.
We've started to use Find Bugs to help identify some of the funk in our codebase's target-rich environment for refactorings. I would also consider Structure 101 to identify spots in your codebase's architecture that are too complicated, so you know where the real swamps are.
In theory, you can't deterministically find unused code. Theres a mathematical proof of this (well, this is a special case of a more general theorem). If you're curious, look up the Halting Problem.
This can manifest itself in Java code in many ways:
Loading classes based on user input, config files, database entries, etc;
Loading external code;
Passing object trees to third party libraries;
etc.
That being said, I use IDEA IntelliJ as my IDE of choice and it has extensive analysis tools for findign dependencies between modules, unused methods, unused members, unused classes, etc. Its quite intelligent too like a private method that isn't called is tagged unused but a public method requires more extensive analysis.
In Eclipse Goto Windows > Preferences > Java > Compiler > Errors/Warnings
and change all of them to errors. Fix all the errors. This is the simplest way. The beauty is that this will allow you to clean up the code as you write.
Screenshot Eclipse Code :
IntelliJ has code analysis tools for detecting code which is unused. You should try making as many fields/methods/classes as non-public as possible and that will show up more unused methods/fields/classes
I would also try to locate duplicate code as a way of reducing code volume.
My last suggestion is try to find open source code which if used would make your code simpler.
The Structure101 slice perspective will give a list (and dependency graph) of any "orphans" or "orphan groups" of classes or packages that have no dependencies to or from the "main" cluster.
DCD is not a plugin for some IDE but can be run from ant or standalone. It looks like a static tool and it can do what PMD and FindBugs can't. I will try it.
P.S. As mentioned in a comment below, the Project lives now in GitHub.
There are tools which profile code and provide code coverage data. This lets you see (as code is run) how much of it is being called. You can get any of these tools to find out how much orphan code you have.
FindBugs is excellent for this sort of thing.
PMD (Project Mess Detector) is another tool that can be used.
However, neither can find public static methods that are unused in a workspace. If anyone knows of such a tool then please let me know.
User coverage tools, such as EMMA. But it's not static tool (i.e. it requires to actually run the application through regression testing, and through all possible error cases, which is, well, impossible :) )
Still, EMMA is very useful.
Code coverage tools, such as Emma, Cobertura, and Clover, will instrument your code and record which parts of it gets invoked by running a suite of tests. This is very useful, and should be an integral part of your development process. It will help you identify how well your test suite covers your code.
However, this is not the same as identifying real dead code. It only identifies code that is covered (or not covered) by tests. This can give you false positives (if your tests do not cover all scenarios) as well as false negatives (if your tests access code that is actually never used in a real world scenario).
I imagine the best way to really identify dead code would be to instrument your code with a coverage tool in a live running environment and to analyse code coverage over an extended period of time.
If you are runnning in a load balanced redundant environment (and if not, why not?) then I suppose it would make sense to only instrument one instance of your application and to configure your load balancer such that a random, but small, portion of your users run on your instrumented instance. If you do this over an extended period of time (to make sure that you have covered all real world usage scenarios - such seasonal variations), you should be able to see exactly which areas of your code are accessed under real world usage and which parts are really never accessed and hence dead code.
I have never personally seen this done, and do not know how the aforementioned tools can be used to instrument and analyse code that is not being invoked through a test suite - but I am sure they can be.
There is a Java project - Dead Code Detector (DCD). For source code it doesn't seem to work well, but for .jar file - it's really good. Plus you can filter by class and by method.
Netbeans here is a plugin for Netbeans dead code detector.
It would be better if it could link to and highlight the unused code. You can vote and comment here: Bug 181458 - Find unused public classes, methods, fields
Eclipse can show/highlight code that can't be reached. JUnit can show you code coverage, but you'd need some tests and have to decide if the relevant test is missing or the code is really unused.
I found Clover coverage tool which instruments code and highlights the code that is used and that is unused. Unlike Google CodePro Analytics, it also works for WebApplications (as per my experience and I may be incorrect about Google CodePro).
The only drawback that I noticed is that it does not takes Java interfaces into account.
I use Doxygen to develop a method call map to locate methods that are never called. On the graph you will find islands of method clusters without callers. This doesn't work for libraries since you need always start from some main entry point.
I'm a new person in this area (plugin developing) and I want to create some kind of plugin for my app:
I've developed an android application and now I need to make a toolkit for the students for future work on this app. The idea is:
1) to make a manual for that app, so that students can read about classes and structure not in separate .doc file but inside Eclipse IDE, probably with some links to the code.
2) to make a supervise of the app's functions (so that students can check if all features (performance-UI design, connection to the external server/API's, etc) of the app are working properly, in case if they will change something). All these data should be in separate frame (looks like a toolkit). (I found information related to this here http://www.ibm.com/developerworks/opensource/tutorials/os-eclipse-jfeature/section5.html, but I'm not sure if it's gonna work for my idea)
I will be glad to get some links of tutorials that are related to my task as well as your suggestions for the set of the toolkit features (but also with links how to make it).
Thank you very much in advance! Hope to get your help :)
The thing for the manual is Javadoc, you can use it in eclipse with java as well as in android.
here are some links, first:
http://en.wikipedia.org/wiki/Javadoc
Then I can quickly explain why javadoc can be useful for you, first of all it allows to create a real manual (java API are created with javadoc) with (in my opinion) the easiest way you can imagine.
You have to use a special comment tag that is:
/**
*
**/
When you put this before any declaration (methods, class, interfaces, fields etc) it will be included in the javadoc.
You have standard things that can be added for example you can specify a description of the method, what it #return what #params it need and many other things, being very careful and precise you can link javadoc with each other, and create very complex and precise documentation.
In eclipse javadoc is useful because eclipse itself allows the user to interact with javadoc by default. For example if you want to know what a method do, just simply hang the mouse over the name of the method and a little yellow dialog will appear. If you also use ctrl-space you can have some tips also in it. Pressing ctrl-space shows for example all avaible public methods, with javadoc for each method you have the yellow description dialog. If you are instantiating a new object you can see how many (and what kind of parameters they have) constructor are definited and so on, I think it is very useful and important.
For the second things if I understand what you want probably something like JUnit (a unit for the testing) can be ok for you.
http://www.junit.org
JUnit is a unit for testing the code, can be fully integrated with eclipse.
In few word, for each part of the code you should write one or more test to check if its behaviour is correct. Once you've written some test you can run them automatically with an user-friendly interface that tell you how many test are failed, how many passed and what kind of error there are.
Why is useful to test each little (stupid?) thing of my code?
Imagine you have a working code (your code).
Imagine you have someone working on it (your students).
How can a user be sure that any change he/she do it's ok with the existing code?
He/she should run the program and check each functionality one by one in order to find an error.
You understand that this is impossible. so JUnit do it for you with just one click (and if you want also in background).
So the student can add the code, and run the tests in order to see if the pre-existing code is still working.
The students can also write his own test to test automatically if all is ok. JUnit in facts allow you to test each part of the code without depending from the other, in this way, you can also test an internet connection without being connected to the net just "mocking" the connection.
I let this part without explanation because It is a long and complicated part. I gave you that "input" to stimulate you to read about testing and XP programming.
Ah, and welcome to stackoverflow! if you like this answer and think that answer correct to your question you can check it with the little check on the left.
I encounter this issue when calculating the price for a product but the formula changes nearly every day because of marketing schemes, discounts, taxes...
So I think it would be great if I could write code such as the code below, so that I could change the script at runtime.
public BigDecimal calculate(String script) {
return (BigDecimal) ScriptEngine.execute(script);
}
Is there any way to implement this using Java?
Yes: Use the Scripting API.
There are implementations to run scripts written in JavaScript, Groovy, Python and lots of other languages.
[EDIT]
Since it was mentioned in the comments: Be wary of security issues.
There are several options:
You allow end-customers to supply scripts (say in a web form)
You don't allow customers to supply scripts; if a script needs to be changes an administrator or developer must start a specific tool.
You develop a system which only allows to execute "safe" scripts
Option #3 doesn't work (= only works for the most simple cases). There is a mathematical proof that a computer program can never tell what another program can potentially do without actually executing it.
So you can get away with option #3 if you don't allow to call methods (or only a very, very limited set of methods). But most scripting languages allow to access Java classes which means you can eventually get System.exit() or Runtime.exec(). This in turn means you have to write a parser which makes sure that the code doesn't contain something odd.
Which you will have to update every day because the customers will come up with new ... err ... interesting ways to use the feature.
Also chances are that you'll make a mistake - either the parser won't accept valid input or it will let malicious code pass. Given the complexity of the problem, the chance is between 99.9999% and 100%.
Option #1 means no security at all but after the third change, customers will berate you to adopt it. It will work for some time until the first script kiddie comes along and ruins everything. Guess whose fault that will be? The manager who hired his nephew... the kid?
So a human will have to eyeball the scripts, fix all the bugs in them and configure the system to run them. Option #2 will cause all kinds of griefs, too, but it will cause less grief, all things considered.
What language do you want "script" to be in?
One way to do this would be to use Javascript, and use a library like Rhino. This will let you execute some JS and get the output inside your code.
http://www.mozilla.org/rhino/
Sure, see Mozilla Rhino
You can use beanshell.jar - It is a standalone shell as well, but can easily be used to run uncompiled java code at runtime.
Developers who have used eclipse cannot miss out the Cntrl+Shift+G combo - the easiest way to find all references to a particular member/method/class in your workspace.
Consider a scenario where you are a new guy maintaining a web application written in java. Now, you are about to change a method signature, and you do a Cntl+Shift+G to find all references to the said method (yes, hoping that you are not doing depedency injection / reflection etc). However, a new guy, would want not to screw up any functionality in the application. How would ensure that the functional dependencies are not affected?
I guess..the question is a bit unclear.. lemme rephrase... Say you are changing something functional (an if loop in a business rule or whateva) - this will definetly CHANGE something else in the context of the application.. and at this point you wish there was something (a plugin?) in eclipse, that would tell you - "hey noob..don't change this - it would affect this..." - Now, if you were to create something that does this for eclipse (plugin?) - where would you start? (tagging parts of scr code and introducing a depdency tree? etc?)
Perhaps I failed to understand your question, but I think I might have an answer. Take a look at nWire for Java (or PHP). It is a plugin for code exploration. Focusing on a piece of code, the developer can quickly determine where the method is invoked, where the class is used, etc. This makes it easier to understand what you are about to change.
I am the developer of this plugin. If it is not exactly what you are looking for, let me know, I'll be happy to better understand what you are looking for.
Besides: ALT+SHIFT+C is the way to change a method signature. ALT+SHIFT+G "only" finds references, which is helpful of course.
vickirk mentionend the most important aspect here: Without having tests and a good code coverage you aren't able to apply any changes without risking a failing system afterwards.
The book "Working Effectively with Legacy Code" from Robert C Martin explains it nicely: All code, which is not covered by tests, is legacy code. You could draw the conclusion, that before you apply any functional change you need to ensure a sufficient test coverage.
Tagging parts in the source code seems like a bad idea, since these tags need to be additionally maintained, which usually never really happens in projects. :)
What about JDepend?