Bug 262304 - [1.5][compiler] Enum constant in annotation value: javac vs Eclipse differ
Summary: [1.5][compiler] Enum constant in annotation value: javac vs Eclipse differ
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.5 M5   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-24 20:51 EST by Walter Harley CLA
Modified: 2016-10-09 08:53 EDT (History)
2 users (show)

See Also:

Attachments
Proposed patch (2.61 KB, patch)
2009-01-26 08:09 EST, Philipe Mulet CLA 		no flags Details | Diff
Complement (2.68 KB, patch)
2009-01-26 11:31 EST, Olivier Thomann CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Walter Harley CLA 2009-01-24 20:51:35 EST 
When compiling the following code

  public class Foo {
    protected enum E { E1, E2 }
    protected @interface AnnoE {
      E value();
    }
 
    @AnnoE(true ? E.E1 : E.E2)
    public void foo() {}
  }


Eclipse does not produce an error, but javac 1.6 does:

  Foo.java:8: an enum annotation value must be an enum constant
          @AnnoE(true ? E.E1 : E.E2)
                      ^

I suspect this has to do with whether the result of the expression (true ? E.E1 : E.E2) is considered an enum constant, and I am not sure whether this is a javac bug or an Eclipse bug.
Comment 1 Philipe Mulet CLA 2009-01-26 06:06:38 EST 
This is an Eclipse bug.
Comment 2 Philipe Mulet CLA 2009-01-26 08:09:22 EST 
Created attachment 123732 [details]
Proposed patch
Comment 3 Philipe Mulet CLA 2009-01-26 11:28:46 EST 
Released for 3.5M5.
We had it wrong since day 1; so not a regression we have to fix for 3.4.2 (also our codegen did eliminate the offending annotation silently already).
Comment 4 Olivier Thomann CLA 2009-01-26 11:31:35 EST 
Created attachment 123762 [details]
Complement

In case the annotation cannot be generated, we should not leave unused strings in the constant pool. This patch properly resets the constant pool in this case.
Comment 5 Frederic Fusier CLA 2009-01-27 07:55:50 EST 
(In reply to comment #4)
> Created an attachment (id=123762) [details]
> Complement
> 
> In case the annotation cannot be generated, we should not leave unused strings
> in the constant pool. This patch properly resets the constant pool in this
> case.
> 
This is unclear whether this complement was released in HEAD stream or not.
Comment 6 Frederic Fusier CLA 2009-01-27 13:41:20 EST 
(In reply to comment #5)
> (In reply to comment #4)
> > Created an attachment (id=123762) [details] [details]
> > Complement
> > 
> This is unclear whether this complement was released in HEAD stream or not.
> 
I verified that this change was also released in HEAD. So, the complete fix will be available in next I-build (I20090128-0100).
Comment 7 Frederic Fusier CLA 2009-01-28 05:14:55 EST 
Verified for 3.5M5 using build I20090127-2000.
Comment 8 Stephan Herrmann CLA 2016-10-09 08:53:40 EDT 
(In reply to Olivier Thomann from comment #4)
> Created attachment 123762 [details] [diff]
> Complement
> 
> In case the annotation cannot be generated, we should not leave unused
> strings in the constant pool. This patch properly resets the constant pool
> in this case.

For posterity: this Complement caused bug 504031 and will be reverted.