Community
Participate
Working Groups
The following code is mis-parsed: @Foo({"bar", "baz"}) private String name; while the following, functionally equivalent, code is parsed correctly: @Foo(value={"bar", "baz"}) private String name; In the former case, the parser ignores the annotation and generates an empty Initializer block in the parent TypeDeclaration's bodyDeclarations. In the latter case, the parser correctly generates a NormalAnnotation and places it in the following FieldDeclaration's modifiers. The former should be parsed as a SingleMemberAnnotation in the FieldDeclaration's modifiers.
Could you please let me know if you are in a code snippet page (scrapbook page) or inside a normal compilation unit?
(In reply to comment #1) > Could you please let me know if you are in a code snippet page (scrapbook page) > or inside a normal compilation unit? > normal compilation unit
I could not reproduce with HEAD contents. What is your build id + compiler settings ?
Could not reproduce with 3.2.1 maintenance build. Could you please tell me what you have installed over 3.2 and WTP? Thanks.
(In reply to comment #4) > Could you please tell me what you have installed over 3.2 and WTP? The HEAD of the org.eclipse.dali.* and org.eclipse.jst.jpa.* packages.
And what do you do to get the error?
Created attachment 49025 [details] JUnit Plug-in Test to re-create problem This JUnit test case class has two tests: test1 uses the annotation "@Foo(value={1, 2})" and passes test2 uses the annotation "@Foo({1, 2})" and fails
In the source that you use for the test case, you missed a semi-colon after the package name. You have: package test public class TestClass { @Foo({1, 2}) private int id; public int getId() { return this.id; } public void setId(int id) { this.id = id; } } In this case the error recovery cannot retrieve the annotation. If the source doesn't contain any error, it works fine. David, do you believe this is doable? If not, simply close as INVALID.
Ahhh, right you are. I have over 100 other tests that manipulate various types of annotations in that same spot; but only this one has caused problems. I guess the parser recovers in the other cases. I added the semicolon and things work fine. Sorry about the hassle.
No problem.
I cannot reproduce the bug using 3.3RC4. This bug has been fixed in a previous build. I close this bug as WORKSFORME.
