Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Build Identifier: I20090611-1540 In Javadoc: The @literal tag itself is not considered when computing the length of the line, thus each long line with such a tag exceeds the selected column width. Reproducible: Always Steps to Reproduce: 1. In a Javadoc comment, type a line just long enough not to exceed the selected column width. Format to be sure. 2. Add a @literal tag around anything in the previous line. Format again. The line did not reformat but exceeds the columns width. 3.
It's often clearer and helpful for us to reproduce when a simple test case shows the problem. Considering the following test case: public interface Test { /** * This a test for bug 291720: {@literal 3<4} */ void foo(); } When formatting it using Eclipse built-in + max line width = 40, I get: public interface Test { /** * This a test for bug 291720: * {@literal 3<4} */ void foo(); } So, it sounds to work properly... However, if your test case was: public interface Test { /** * This a test for bug 291720: @literal */ void foo(); } Then I agree that formatting it does not break the line although you could expect it. But this is intentional and not limited to @literal tag. If the formatter detects that breaking a line would imply to have a block tag at the beginning then it skips the tag and brakes the line after it. The reason of this behavior is because if the line would have been broken before the block tag then another formatting would have formatted the comment differently, hence would have made the formatter output unstable. Again a sample would be better to understand this. Formatting the test case above would have produced the following output: public interface Test { /** * This a test for bug 291720: * @literal */ void foo(); } But formatting this output again would have given a different output: public interface Test { /** * This a test for bug 291720: * * @literal */ void foo(); } As block tags written in a line are often users mistakes (typically in your case, I guess it is as @literal is an inline tag...), we have chosen to accept characters over the max line width instead of making the formatter unstable... So, close as WONTFIX. Reopen in case my assumption on your test case was totally wrong, thanks
Agree with comment 1. Verified for 3.6M3 using I20091027-0100
