I have a class which has 1600 public static members. I must found and delete the unused ones. Is there a way to do it in Eclipse.
There exists a Eclipse plugin Unused Code Detector (http://www.ucdetector.org/).
It can process a specific file or the entire project, searching for unused members/methods.
Ucdetector: You can install a plugin from this link. It works pretty well we have been using it in all our projects. It generates a html report as well it can mark warnings in eclipse. It helps you find unused classes, methods and variables. Only thing it dosen't do well is finding if a class is used via reflection only or where instance is created via spring. In these cases it still shows that class is unused.
http://ucdetector.sourceforge.net/update
Another thing you can do to clean up other types of unsed code is
GoTo Window>Preferences>Java>Compiler>Error/Warnings
Now look for uncessary code section and tweak the settings as you desire to cleanup further.
I hope it helps :)
Related
I'm working on a module project in NetBeans 8.2, with a GUI and everything. I'm using lots of the IDE functionality to auto-generate code for the GUI.
Every time I do a clean build of my project, I get a warning from the compiler:
warning: No processor claimed any of these annotations:javax.annotation.Generated
Browsing the build directory, I see that the IDE generates a class for me, Bundle.java, and it slaps the given annotation on top of it:
#javax.annotation.Generated(value="org.netbeans.modules.openide.util.NbBundleProcessor")
I need this warning to go away. I tried searching the web for an annotation processor that processes this specific annotation but I had no luck. Does an annotation processor for this specific annotation exist?
If this is a "harmless warning," I need to understand why it is harmless to justify its existence in my build output.
If needed I can include in this question the argument to the -processorpath option that is passed to javac from the IDE; I didn't include it on purpose because it is very long but I can add it if necessary
EDIT #1:
I did a "hacky" modification to the common.xml file under the NetBeans installation directory to make the invocation to javac not include the -processorpath option, and doing so makes the warning dissapear. I still do not understand why that is the case
A simple fix for this is to remove the #Messages annotation from the TopComponent class that is generated by the NetBeans code generator. It is that annotation that is responsible for generating the Bundle class, as per the NbBundle.Messages API Documentation.
As soon as you remove that annotation, you might get warnings from other annotations that rely on the contents of the #Messages annotation (i.e. TopComponent.OpenActionRegistration), so make sure to modify the contents of those annotation as well until nothing in your code depends on that Bundle anymore.
Hopefully nothing else in your code relies on your Bundle.
I've been using Eclipse for a while and I'm having trouble understanding what's going on with my first project in IntelliJ. I've read the documentation, and searched other questions, but I still can't seem to grasp it. I think there is something wrong with my project structure. This is what my structure currently looks like;
I'm trying to run the JavaForLoop class, but whenever I do, compilation fails because I have errors in the StringMethods class of the strings package. My question is why would that prevent compilation if the two classes are in separate packages? Neither class uses the other, and they both have the appropriate package declaration statements. With a similar structure in Eclipse, this would work. Should I be using a different project structure?
By default IDEA adds Build Configuration which is executed before launch and includes following steps (taken from here):
Compiling source code in the source path of a module and placing results to the output path.
Compiling source code in the test path of a module and placing results to the test output path.
Creating copies of the resource files in the output path.
Reporting problems in the Messages tool window.
check if it's your case in Edit Configuration screen and if so, remove it.
To use a class from a different package you must declare a import statement to the class.
In your JavaForLoop.java add the import before the class statement (and after package declaration where its the case)
//package ...
import strings.StringMethods;
//public class JavaForLoop { and the rest of the code
Intellij uses regular javac, which will fail to compile if you have errors anywhere in the code.
Eclipse has it's own compiler, that allows to compile and even run code that has compilation errors, causing a runtime exception if any part of the code that has errors is run. This allows you to run parts of the code that work even if other pieces of code are failing.
The simple solution is to resolve your compilation errors. You can also use the eclipse compiler with Intellij, but I've never done this so I can't comment on how well it works.
I was using JD-GUI to get readable content of the several .class files in order to create a custom one, because many parts of the original libraries are not used (save space and performance)
So I read the code and started creating an eclipse library project in eclipse pasting them in.
soon apeared the first weird errors:
The method getLogger(Class) from the type Logger refers to the missing type Class
Implicit super constructor Object() is undefined for default constructor. Must define an explicit constructor
and so on.
Does anyone has experience in creating libraries from other libraries in eclipse? what is going wrong?
thank you.
EDIT:
it seems that several imports are not found:
error example:
The import org.w3c.dom.stylesheets cannot be resolved
how can this be, when the original libraries are working fine? I did not remove a single class. my custom library is just a merged one with 100% the same content.
I am trying to get Thrift working in Eclipse and having some issues. The project is a standard maven project.
I used the thrift compiler to compile the thrift file to Java code, which was successful. The generated code was placed under src/main/generated-sources//
(Is this acceptable practise?)
In eclipse, I added the src folder from the build menu, but then I get:
Cannot reduce the visibility of the inherited method from ProcessFuction<I,...
I am not using the maven thrift plugin as the source is already generated and within the source tree (again, is this advisable?).
How should I configure this setup?
seems like the Thrift compiler is not as good as thought.
Cannot reduce the visibility of the inherited method
shows that a inherited method from an abstract class or an interface has originally a higher visibility, e.g. "public" while you have "private" in your code.
I would try to set that to "public" and see what happens. The code might compile sweet, as I expect that mismatch to be generated due to compiling/transformation of code with missing visibility setting on the method as one can write a method header without specifying the visiblitiy:
void doany(){
// nothing
}
The method uses the classes visibility in that case (mostly "public") - which the compiler will have misunderstood.
I get the following IDE error which appears inline or on the package declaration of my classes, but doesn't prevent the code running or working as expected.
I tried manually downloading the javax-annotations.jar from Glassfish and placing that in both the classpath and also on the JDK external JAR resources areas, no help.
The type javax.annotation.meta.When cannot be resolved. It is indirectly referenced from required .class file.
The error appears anywhere that I use the Findbugs #NonNull annotations; any class which uses this annotation has the above message appear in the IDE on the package declaration line. The class however appears as error-free from the Package-Explorer or Navigator view.
I would quite happily ignore this, however it breaks the Mark-All-Occurences behaviour which I quite like, if anyone has any ideas on what I might have missed I would appreciate it!
The FindBugs jar already contains a jsr-305.jar, which contains an implementation of JSR-305.
More info in this previous question.
Edit Oh, you already did that--I didn't even know it was in annotations.jar as well.