Community
Participate
Working Groups
I200312162000 Changing the "Format header comment" affects the interface's Javadoc in the following code (taken from new code formatter comment preview): /** * An example for comment formatting. This example is meant to illustrate the various possiblilities offered by <i>Eclipse</i> in order to format comments. */ interface Example { /** * * These possibilities include: * <ul><li>Formatting of header comments.</li><li>Formatting of Javadoc tags</li></ul> */ int bar(); /** * The following is some sample code which illustrates source formatting within javadoc comments: * <pre>public class Example {final int a= 1;final boolean b= true;}</pre> * @param a The first parameter. For an optimum result, this should be an odd number * between 0 and 100. * @param b The second parameter. * @result The result of the foo operation, usually within 0 and 1000. */ int foo(int a, int b); }
the "format header comment" feature just checks for comments at position 0. A solution would be to add an empty line before the javadoc comment, or a package declaration or so.
I disagree and would say it is a bug that the file header comment can't start with empty lines. See also bug 49527
So the real problem is that the type comment of a type in the default package that specifies no imports is not formatted when "format header comments" is unchecked. Seems not like a very frequent problem - workaround for the preference page by - adding an import statement - adding a package declaration - setting format header comment to "true" for the preview.
As discussed and decided with Tom, the current header detection scheme is quite error prone and should be replaced by the following heuristic: treat everything as header from 0 to beginning of first top level type's source range offset. Adapted summary and increased priority.
How should we handle the case where we don't have an editor? E.g., in previewers we do not have a Java model. Right?
you could make temporary working copy using the preview source
There is a problem with the proposal from comment 4: Given a CU with a header comment and a top-level type's comment with nothing but whitespace in-between, the source range of the top-level type starts at the offset of the header comment, not the type's comment.
See bug 56532. As a workaround you could use a Java code scanner and do it yourself (see JavaDocAccess as a hint).
Fixed (released modified patch by Christof) Available in builds > 20040330
*** Bug 57161 has been marked as a duplicate of this bug. ***
