Bug 12710 - Inconsistent behavior for the method IType.createField()
Summary: Inconsistent behavior for the method IType.createField()
Status: RESOLVED DUPLICATE of bug 9790
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.0 M5   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-03 14:18 EST by Brian Wilkerson CLA
Modified: 2002-04-04 06:05 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Wilkerson CLA 2002-04-03 14:18:36 EST
Given a class whose source code has the following form:

public abstract class TestClass implements ITestClass {
    /* (non-Javadoc)
     * @see ITestClass#getName()
     */
    public String getName() {
        return null;
    }
}

invoking the method

    org.eclipse.jdt.core.IType.createField(String contents,
                                           IJavaElement sibling,
                                           boolean force,
                                           IProgressMonitor monitor)

on the object that represents the above type (passing in "null" for both the 
sibling and the progress monitor and "false" for force) will cause the 
definition of the field to be inserted between the comment and the method. I 
suspect that the behavior I'm seeing is due to the non-Javadoc comment not 
being associated with the method.

This behavior seems inconsistent because of the user-level preference 
to "Create non-Javadoc comments for overridden methods" on the Java|Code 
Generation preference page. It seems that the user interface is implying 
support for that style of coding, while the API does not. I believe that in 
order to fully support that style, the API needs to recognize such a comment as 
being essentially equivalent to a Javadoc comment.

I believe that two fixes are possible. The first would be to explicitly stop 
supporting that style of coding. I suspect, however, that while this change 
would be easy to implement, it would be a very difficult change to make from a 
political point of view.

The second would be to fix the API so that non-Javadoc comments are associated 
with the member (or at least method) that follows them. You might want to place 
additional restrictions so that the association is only made if

 - there are no blank lines between the comment and the member,

 - there is no Javadoc comment, and/or

 - the phrase "(non-Javadoc)" must appear as the first non-white
   space in the comment.

I am running build 20020214 under Microsoft Windows 2000 (5.00.2195).
Comment 1 Philipe Mulet CLA 2002-04-04 06:05:07 EST
Comments were indeed not associated with their corresponding construct. We are 
changing this rule due to bug 9790, to include all comments prior to any 
constructor to be part of it in the JavaModel.

Please check with latest integration build, and reopen this defect if the new 
behavior is still not appropriate.

*** This bug has been marked as a duplicate of 9790 ***