Community
Participate
Working Groups
Using 3.4M7 The following test case: package test.lines; public class X10 { /** * * Returns true if the operator expects... **/ void foo() { } } is formatted as follow using Eclipse built-in settings: package test.lines; public class X10 { /** * * Returns true if the operator expects... **/ void foo() { } } Note that the javadoc footer is untouched and stay as '**/' In 3.3, the formatted output was: package test.lines; public class X10 { /** * * Returns true if the operator expects... */ void foo() { } }
Playing a little bit with similar test cases, I saw a really strange behavior of the 3.3 formatter... The following similar test case: package test.lines; public class X10 { /** ** ** Returns true if the operator expects... **/ void foo() { } } was formatted as: package test.lines; public class X10 { /** * * * Returns true if the operator expects... */ void foo() { } } Really strange and definitely buggy... The new comment formatter (e.g. 3.4 M7) formatted output is: package test.lines; public class X10 { /** ** ** Returns true if the operator expects... **/ void foo() { } } Which looks a little bit better.
Another variation with Comment max line length = 40... Test case: package test.lines; public class X10 { /** ** ** Returns true if the operator expects... **/ void foo() { } } 3.3 formatted output: package test.lines; public class X10 { /** * * * Returns true if the operator * expects... */ void foo() { } } 3.4M7 formatted output: package test.lines; public class X10 { /** ** ** Returns true if the operator * expects... **/ void foo() { } } Better than 3.3, but not perfect though...
So the main question is should we conserve multiple '*' at the beginning of the javadoc lines, always replace them with only one or add a preference for this?
Note that with HEAD the formatter output is slightly different for the two last cases, respectively: package test.lines; public class X10 { /** ** * Returns true if the operator expects... **/ void foo() { } } and: package test.lines; public class X10 { /** ** * Returns true if the operator * expects... **/ void foo() { } } which looks worst than M7... :-(
In fact there are many other differences while formatting the javadoc header and footer. So, I update the summary accordingly
For example, if they are more than 2 stars in the header or in the footer... All following examples, are formatted using Eclipse built-in + Maximum line width for comments = 40. Test case 1): ============ public class X01 { /*** * * Test header/footer. */ void foo() { } } 3.3 formatter: public class X01 { /*********************************** * * Test header/footer. */ void foo() { } } 3.4M7 formatter: public class X01 { /*** * * Test header/footer. */ void foo() { } } HEAD formatter: public class X01 { /** * * * * Test header/footer. */ void foo() { } } Test case 2): ============ public class X01d { /** * * Test header/footer. ***/ void foo() { } } 3.3 formatter: public class X01d { /*********************************** * * Test header/footer. **********************************/ void foo() { } } 3.4M7 formatter: public class X01d { /** * * Test header/footer. ***/ void foo() { } } HEAD formatter: public class X01d { /** * * Test header/footer. * */ void foo() { } } Test case 3): ============ public class X01f { /***************************************** * * Returns true * *****************************************/ void foo() { } } 3.3 formatter: public class X01f { /*********************************** * * Returns true * **********************************/ void foo() { } } 3.4M7 formatter: public class X01f { /***************************************** * * Returns true * *****************************************/ void foo() { } } HEAD formatter: public class X01f { /** * ********************************* * ****** * * Returns true * ********************************** * ****** */ void foo() { } } The conclusion is that HEAD formatter behavior is definitely worst than M7 and needs to be reverted. There will be still a difference with 3.3 formatter but more acceptable than current one...
*** Bug 288729 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I checked a few examples and the results are quite reasonable now.