We Keep Coding

can we make JavaDoc tool to parse comments inside methods?

I tried googling this question a lot but could not find the answer to exact question. I also read this question: Does the javadoc tool recognize comments inside methods?
So my question is kind-of a follow-up to this. I know that default JavaDoc tool would simple ignore any javadoc comments inside methods, but can we somehow make it read those comments too and may be try handling them on our customer doclets/ taglets? I tried writing my own doclet and taglet as well but since JavaDoc would completely ignore the comments inside methods, I could not succeed.
For example, suppose I have the following code:
public void methodX() {
/**
* #MyTag This is a sample javadoc comment with custom tag
*/
}
Is there a way to make JavaDoc not ignore the comment inside methodX? I could handle the response in a custom doclet if javadoc could parse and provide the comment text.
Reason to try this:
I guess it would be helpful to know why I'm looking for such a requirement. Basically we have a lot of configuration driven coding where these configurations are stored in DB (So that we could simply change the configuration at runtime without having to go through the BRD process again). So we are planning to document those configurations at a central place. And instead of keeping the code and document separate, we also think it would be wise to keep the documentation closer to code itself so that any code updations could also possibly update the documentation. Publishing to central place can be taken care of via doclets/ taglets but only if JavaDoc could read those comments inside methods.
So is there a possibility of making JavaDoc tool read through comments inside methods as well? Or else we would have to try and write our own comments parser similar to JavaDoc for this.

So I did a little digging around and seeing that no-one has answered the question, it seems people are (maybe) not sure about the possibility.
Based on what I found, it doesn't seem feasible to have the JavaDoc tool parse the comments inside methods. The reason being, JavaDoc doesn't even get those comment texts to parse. Now, what I mean here is, JavaDoc relies on the JDK compiler (the API of-course) to have the Java code converted into tokens and trees and then gets all the comments from there. So unless you are okay modifying the JDK compiler itself to make it "Do Not Ignore" the comments inside methods, you can't make JavaDoc to read comments inside method.
Oh! And for the part of solving our problem, we're, for now, restricting to define JavaDocs with custom Tags for the constants we used and have the comments processed via a Custom Taglet to handle the new Tags.

Is there any point in writing javadocs for a javafx application?

Simple question here. Is there any point in applying javadocs to methods in a javafx application.
For starters - the majority of my method headers are formatted as private (with #FXML annotation).
I am using some public methods - but what is the point in javadocs if the end user uses a GUI to interact with the application and my application isn't an API? Obviously, all my methods are concisely commented - but I don't see what benefit javadocs will have for users or future developers of the code.
Am I wrong? If so, I'd really appreciate your views on this.
Many thanks.

Please take a look at https://softwareengineering.stackexchange.com/questions/85910/is-it-wrong-not-to-create-javadoc-for-my-code
In theory, meaningful documentation is never bad, and therefore every method you can document in a meaningful way should be documented.
In practice, it comes down to who the "audience" for the documentation is, to team-agreement, and to personal choice.
Things to consider are:
Your audience can be a maintenance developer, which, nevermind other persons, may be yourself, after 3 years without working or visiting the project, and after you have forgotten the details of how it all works.
In case of Javadoc and similar documentation tools and standards, even for private methods (usually not outputted to external doc files by default), many IDEs support Javadocs (or similar) and implement extra-features based on them. NetBeans, for example, can display tooltips containing the types, names, and if you documented them, purposes of classes, methods, and input and output parameters and vars. Eliminating the need to open files and/or look at source-code inline-comments if and when you forget something.

For framework code, I always Javadoc all public and protected members. For application code, I generally don't bother with Javadoc comments, but I do use inline comments to explain what a method is doing.
For private methods (whether framework or app code), I don't use Javadoc at all, since they aren't included in the Javadoc output by default. I do use inline comments for private members, though.

Java code change analysis tool - e.g tell me if a method signature has changed, method implementation

Is there any diff tool specifically for Java that doesn't just highlight differences in a file, but is more complex?
By more complex I mean it'd take 2 input files, the same class file of different versions, and tell me things like:
Field names changed
New methods added
Deleted methods
Methods whose signatures have changed
Methods whose implementations have changed (not interested in any more detail than that)
Done some Googling and can't find anything like this...I figure it could be useful in determining whether or not changes to dependencies would require a rebuild of a particular module.
Thanks in advance
Edit:
I suppose I should clarify:
I'm not bothered about a GUI for the tool, it'd be something I'm interested in calling programmatically.
And as for my reasoning:
To workout if I need to rebuild certain modules/components if their dependencies have changed (which could save us around 1 hour per component)... More detailed explanation but I don't really see it as important.
To be used to analyse changes made to certain components that we are trying to lock down and rely on as being more stable, we are attempting to ensure that only very rarely should method signatures change in a particular component.

You said above that Clirr is what you're looking for.
But for others with slightly differet needs, I'd like to recommend JDiff. Both have pros and cons, but for my needs I ended up using JDiff. I don't think it'll satisfy your last bullet point and it's difficult to call programmatically. What it does do is generate a useful report for API differences.

#Generated Annotation, how do we use it?

I recently read an article talking about the Java annotations, and on this latter comes the #Generated one. They say that it is used for automatically generate code.
Could someone explain me that in further with a little example ?
All what i found on the net was some pro question or something beyond what i was looking for.

As per the JavaDoc:
The Generated annoation is used to mark source code that has been generated. It can also be used to differentiate user written code from generated code in a single file.

#Generated is used by meta-programs such as Auto/Value which generate source code so you don't have to manually write it. If you're writing a .java file by hand (which is normally what one does), don't use #Generated.

Fox example are good and bad policies on the border between generated and written code. Way of thinking is (i belive) different in compiled (static) languages, nad interpreted / dynamic.
Worst is to modify generated code (will be lost at next generation, or next generation is then prohibited)
Usually is accepted to derive (manual) class from generated, or generate class what extends core "manual" class.
If someone know good policies in this area, please comment.

Some code linters use the annotation to skip generated code. For example, it doesn't make sense to calculate cyclomatic complexity on generated code.

Should a function's comment include descriptions of work done by functions it calls?

Let's say I have a function called DisplayWhiskers() which puts some slashes and backslashes on the screen to represent an animal's whiskers like this: /// \\\.
I might write a comment for this function along the lines of
// Represents an animal's whiskers by displaying three
// slashes followed by a space and three backslashes
But if I then add functions DisplayKitten() and DisplaySealion() which as part of their work call DisplayWhiskers(), how much detail about the displaying of whiskers should go in the comments for these other functions?
On one hand, it seems that I should be able to look at the comments for DisplayKitten() and understand everything I need to about what it's going to do, including exactly how it will display the whiskers. I shouldn't have to go elsewhere to read the comments for DisplayWhiskers() to find this out.
On the other hand, if the comments for DisplayKitten() explicitly refer to three slashes followed by three backslashes, this seems to go against the spirit of encapsulation and could become erroneous if DisplayWhiskers() is later changed.
What is considered best practice?
EDIT: Several answers have suggested that the solution is to read the code. I understand the principle of good code being its own best comment, but for this question I didn't mean to refer to in-code comments, but to the comments in header files that accompany the function prototypes. Let's assume the actual code is pre-compiled and not accessible to the client who wants to use or call it.

I would say that you should write your code clearly and name it appropriately so that it is self-documenting and doesn't need comments for future programmers to understand what it does. Then you would only use comments to document API functions (where the user doesn't have access to the code base) or complex/non-obvious things that you haven't been able to refactor to make them more understandable.

In general, comments should not concentrate on what the code does -- the code itself documents that. Instead they should concentrate on WHY things are being done.

You seem to be naming your functions descriptive enough and leaving them to do only one thing (single responsibility). By reading the code you would essentially understand what they are doing. This would be my preference instead of adding comments.

I'd argue that in general, this paragraph is on the right track for 99% of cases:
On the other hand, if the comments for
DisplayKitten() explicitly refer to
three slashes followed by three
backslashes, this seems to go against
the spirit of encapsulation and could
become erroneous if DisplayWhiskers()
is later changed.
How DisplayKitten() calls DisplayWhiskers(), and even the fact that it calls it, is probably an implementation detail.
There are cases where this is not true. Sometimes you have a "convenience function" whose job is to just call another function in a particular way. In those cases it may make sense to intentionally break the encapsulation in your documentation. These cases are the exception to the rule, however.

Your functions should ideally do one thing only, whatever a "thing" may be and at what level of granularity.
Similarly, they should be described at the appropriate level of granularity. If you're printing out an ASCII kitten, you can leave that as the description for DisplayKitten(). You don't have to describe every last thing it does.
Think about it. If every function described every last thing it did, your main function would have to describe every individual thing anything in the program would do, and that's way overkill. Moreover, most of that comment would be distributed among the called functions, and so on, so the program would wind up as mostly ridiculously detailed comments.
So, leave the comments to what the function does in general, and as long as your function names are sufficiently descriptive (and yours are) cut those to a minimum. If you or your users need more detail, they can examine the code.

Normally I wouldn't mention all the work done by all the subroutines. It could get very tedious. It might be worth mentioning if one of the subroutines does something unusual, or has interesting side effects that would otherwise be unknown.

keep the comments DRY

"for this question I didn't mean to refer to in-code comments, but to the comments in header files that accompany the function prototypes."
You'd probably get different answers if you replace the word "comments" with the word "documentation" throughout your question. I think this addition changes the question quite a lot.
There's a huge difference between an interface that you're committed to, and a few notes about how your implementation happens to accomplish something. You should take the former very seriously, and make sure it contains everything the caller needs to know, and no more. The latter should be kept as far away from callers as possible, so that if you want to change it in future, you can do so without affecting any other code.
In this case, kittens clearly have whiskers, so that much should be documented. But is it a vital feature of kittens that they have three whiskers on each side? I don't know, it depends entirely on the real problem domain, and the design of your code. If not, you probably shouldn't be documenting it, and perhaps should specifically mention that the number of whiskers may change without warning in future.

Method comments (ideally in javadoc form, despite its hideous syntax) should accompany methods, and should include what a caller needs to know to call the method, and nothing else (except possibly what a subclasser needs to know).
What work is done by submethods is an implementation detail. Indeed, whether there even are any submethods is an implementation detail.
Just tell potential callers what they need to know, things like: does displayKitten() actually display a kitten? If so, where? Or does it return a string representation?
Should you give the format? That depends. Is the actual representation of a kitten an implementation detail, as described in the question? In that case, no, you should not give the format. But if it's in compliance with some specification, it's good practice to reference the spec - possibly even in the method name: displayKittenPerFsda246_a().