ParseException for private static String[] allConstants = {C1,C2,C3};

I'm unable to reproduce a parsing error with the attached file.

The error is a bit more strange nowadays, since the first method of a class includes the comment before it if the constant declarations (above) are present as below:

package com.acme.qdox;

import static org.junit.Assert.assertEquals;
import java.io.StringReader;
import org.junit.Test;
import com.thoughtworks.qdox.JavaDocBuilder;
import com.thoughtworks.qdox.model.JavaClass;

public class TestQDoxBug131 {
@Test
public void commentsBeforeMethodShouldNotAppearInSourceCode() throws Exception {
String sourceCode = "package com.acme.qdox;\n" +
"\n" +
"public class QDoxBugClass {\n" +
" final public static String C1 = \"C1\", C2 = \"C2\";\n" +
" final public static String[] ALL =

; \n" +
" /*\n" +
" Comment\n" +
" */\n" +
" public void method()

\n" +
"}\n" +
"";
JavaDocBuilder builder = new JavaDocBuilder();
builder.addSource(new StringReader(sourceCode));
JavaClass aClass = builder.getClassByName("com.acme.qdox.QDoxBugClass");
assertEquals("\n System.out.println(\"This should not contain the comment\");\n ",
aClass.getMethods()[0].getSourceCode());

}
}

Testfile for bug described

I attached file TestQDoxBug131.java since the code got whitespace-trimmed.

The javadoc isn't clear in what to expect when calling getSourceCode(). In this case it's the code between the method-brackets. I don't know if it's valid to expect the comments to be filtered out. Bug or feature-request?

Hi Robert,

The example is a bit cluttered but if you run the attached test and check the difference between the expected and the actual in an IDE I think it will be clearer what I mean.

This bug is that the comments BEFORE the method is included in the source of the method, but only for the first method of a class, and only if there is a declaration like C1 or ALL as above.

(The comments within a method should, as you state, be returned as part of the source code for that method.)

Cheers
Daniel

Hi Daniel,

thanks for explaining, the problem is clear to me. And it's not that hard to spot the cause of this problem. There's no trigger to start a new codeBody (or end the old one). It's a lexer-problem and should be solvable. Maybe I'll have another look next week.

patch attached with a test and the fix. Now when starting a new codeblock, it'll be reset first.

Great! Any chance of knowing when it is in a build/release on the maven site?

patch applied