What does "// TODO Auto Generated method stub" mean? - java

I see it all the time and can't find a simple description.

It means that your IDE (or some other tool) has automatically generated a method for you, but has left the body blank to be filled in by you (this is known as a "stub").
In your case, it was probably Eclipse.

This is a comment that's added by Eclipse (an IDE) when you have eclipse create a method body for you. It's meant as a reminder for the programmer that he/she needs to code something in the method

These stubs mean that they are inherited abstract methods from super class whose implementations need to be crammed by you.

Related

How do I find usages of method implementation in eclipse?

When I want to find usages of a normal method in java it is fairly easy and straightforward CTRL-SHIFT-G .
However if this method has a super definition, or implementation, then eclipse will show me usages of all types in the hierarchy types.
For example, if I have a toString() method on my class, I would only be interested in finding exactly where this toString() of this class was being called, instead eclipse gives me every single ancestor toString in the project (ie Object.toString()).
How do I find only specific usages to my class? And not usages of parent classes like Object.toString() ?
Alt + ctrl + h should give you exactly, what you are looking for.
Updated with screenshot from my workspace as some people are facing issue in following it:
Thanks to #manouti answer,
To show when using the overridden method only follow the steps:
Search by Java the method as com.package.MyObject.toString()
And after in search result screen click on the right arrow to the left and check References to Overridden
After having the same problem as many others in the comments (Eclipse shows references to Object.toString()) I have found a way that seems to work correctly:
Go to outline from your custom class, right click on your toString() implementation and References -> Project. This displays only references to said implementation.

Intellij IDEA doesn't grey out some unused methods

In intellij IDEA, if a method is unused, the method is shown in a gray color. But in some cases, IDEA doesn't grey out the method, but when I check the references of those methods using alt + F7, IDEA says that the method is unused.
Is this a IDEA bug or is there any reason why IDEA wouldn't grey out these specific methods? If it is a bug, is there some workaround to make IDEA identify that method is unused?
Most likely it's not a bug, it's a limitation for performance reasons. Methods likely to take a long time when searching for usages are skipped.
A workaround is to run Unused Declaration inspection explicitly in all your project via Analyze | Inspect Code or Analyze | Run Inspection by Name. That'll take some time. You can also set up TeamCity server to do it for you automatically every night.
I used to have it working like charm, but one time, I by mistake clicked on alt+Enter on an unused method, and chose to suppress the inspection on unused code. Ever since then, I stopped getting the grayed out methods and code, so since there is a way to get it undone, there sure must be a way to get it back working.
After 5 minutes of searching, I found a solution:
Settings --> Editor --> Inspections --> Java --> Declaration Redundancy --> Unused Declaration
Make sure you check "Unused Declaration"
And I just checked by creating a new useless method, working like a charm.
My answer is quite late, but perhaps it will help others to identify their problem:
IntelliJ didn't mark methods as unused for me, because they were overloaded methods, for example:
1: methodName(String argument)
2: methodName(ArrayList<String> argument)
The first method was no longer used, but the second method was. IntelliJ (I assume) simply checks the method names, and sees that the method name is used, even though one of them is no longer used.
I have checked the other answers on this page for finding unused methods, but have not found a solution to filter out unused, overloaded methods.
It might be a bug if you're using a method with a very common name.
If you tried #Peter Gromov method above, and your method is still yellow, it might be the case that this is a bug.
I had a very common named method, named "stop".
Looking for usages (using ALT + F7) didn't show anything.
Analyzing the whole project, clearly showed that this method did not have any use.
Despite that, the method was still yellow.
I was surprised to find out, that if I try to refactor the method name, I get a pop-up warning that this will change in other places as well.
Turns out, that the refactoring warned about changing the method name in TODO comments. Somehow Lint recognized the TODO comments as using this method.
My advice is to just not name your methods as something that may be written in a TODO comment.
See this image, where I am using a method named "stop" :

Finding called methods - reverse call hierarchy

Are there any tools that will, for a given method or class, list all methods that can be called by that method/class?
I am aware of code coverage tools, but I'm looking more for static analysis.
Obviously some kind of filtering system would be needed to stop the generated report being too big. I would want to identify all methods in the com.mycompany.* package hierarchy, for example.
I'm basically looking for an inverse version of the call hierarchy provided by IDEs like Eclipse and Idea.
bcel and asm permit to read and analyze class files. Then you can write the code which:
look in the target method all call ('invoke')
look into constant pool components for their resolution
I don't have anything more friendly...
You can try jarchitect tool, a static analysis tool that can help you to list all methods called by another method or a class.
In Eclipse, you can view the references to a method, class, or variable.
You can do this by right-clicking on the name of the object you're interested in, and selecting whichever scope applies to you:
References -> Workspace (Ctrl + Shift + G)
Project
Hierarchy
Working Set...
or by typing: Ctrl + Shift + G to find references in your Workspace by default.

Seeing all classes that extent current viewed class in javadocs?

At the risk of sounding incredibly stupid and receiving a rather patronising answer, how do I view all other classes that extend the current 'viewed class' in javadocS?
i.e.
Object a {}
Object b extends a {}
Viewing a, is there a way to see 'all classes that have extended this class A'... therefore showing 'Class B'.
EDIT:
Thanks for that. There is an API I am reading at the minute where I was certain there had to be subclasses... turns out it doesn't! Interesting.
Javadoc should automatically generate the "Direct known subclasses" section, which in this case would list class B.
You shouldn't need to do anything to make this show up, so if you're not, there's a possibility it's a bug in the javadoc generator (however, unless you've presented a simplified version here, I'd be surprised if this trivial case triggers it).
Outside of your IDE javadocs in browser have a header "Direct Known Subclasses:" like the one in the javadoc for ArrayList. In IntelliJ IDEA all implementations/extensions of currently viewed interface/class can be seen if you press + B.

Can one automatically create javadoc tags for an entire Eclipse project?

I know one can use '<alt><shift>J' to create tags for a single code element (class method for example).
But is there a way to automatically create these tags for every class in the entire project? Or even just at package or class level?
Have you looked at JAutodoc?
Not that I know of.
What would that be good for anyway? Autogenerated Javadoc comments are worse than useless; I'd rather not have them cluttering up my code, and Javadoc will provide as much information even with no comment present.
Automatic generated JavaDoc is a pain, because other people never now what the method should do and yourself will also not know it, when you look at the class one year later.
Please comment your methods by yourself or do not comment the method.
My company is using checkstyle to force the employers to add javadoc. Some employers hate it to comment their methods and just type sensless comments. It would be better that their is no comment than a useless.
With checkstyle you can find all undocumented methods, to document them in a well format.
What will help you to document an init method like
"init has to be called before any
other method and initializes the class
ActionDummy"
it is better to tell what exactly is done
Inizializes the default state of the
action provider. Some state variables can be
overriden by the listener when ....

Categories

Resources