Bug 232138 - [formatter] Javadoc header/footer formatting is different than 3.3
Summary: [formatter] Javadoc header/footer formatting is different than 3.3
Status: RESOLVED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P5 normal with 1 vote (vote)
Target Milestone: 4.14 M3   Edit
Assignee: Mateusz Matela CLA
QA Contact:
URL:
Whiteboard: To be verified for 4.14 M3
Keywords:
: 288729 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-05-14 14:08 EDT by Frederic Fusier CLA
Modified: 2019-10-14 04:56 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Fusier CLA 2008-05-14 14:08:06 EDT
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() {
	}
}
Comment 1 Frederic Fusier CLA 2008-05-14 14:12:36 EDT
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.
Comment 2 Frederic Fusier CLA 2008-05-14 14:18:05 EDT
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...
Comment 3 Frederic Fusier CLA 2008-05-14 14:19:25 EDT
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?
Comment 4 Frederic Fusier CLA 2008-05-15 05:00:18 EDT
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... :-(
Comment 5 Frederic Fusier CLA 2008-05-15 06:39:40 EDT
In fact there are many other differences while formatting the javadoc header and footer. So, I update the summary accordingly
Comment 6 Frederic Fusier CLA 2008-05-15 06:56:29 EDT
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...
Comment 7 Frederic Fusier CLA 2010-12-27 04:24:23 EST
*** Bug 288729 has been marked as a duplicate of this bug. ***
Comment 8 Eclipse Genie CLA 2019-10-13 17:57:13 EDT
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.
Comment 9 Mateusz Matela CLA 2019-10-14 04:56:56 EDT
I checked a few examples and the results are quite reasonable now.