Cleaning all of the projects and rebuilding them does not solve the problem.
Restarting Eclipse IDE does not solve the problem.
If I hold down the Ctrl key and mouse over the enum type, the type does not underline in blue.  If I mouse over the switched variable, it underlines in blue.  If I click on it, the cursor jumps to where the variable is declared.  If I mouse over another type, it does underline in blue and clicking on it opens the file.
I am running the 64-bit version of Eclipse IDE... if it matters.

As you already mention that the bug happens only some times, can you give
an example that demonstrates the bug?
Where is that enum in question defined? In the same project?
In a library? Can you open the enum type using Ctrl-Shift-T?

SendTimeoutFlags is one of the enums in question.  I think most if not all of the enums in the project are flagged as switch errors.  I am able to open the enum type using Ctrl-Shift-T.  In fact, SendTimeoutFlags is defined in the same file!
   public static enum SendTimeoutFlags {AbortIfHung, Block, Normal, NoTimeoutIfNotHung, ErrorOnExit}
public void hi(SendTimeoutFlags flags)
   switch (flags)
      case AbortIfHung:
      case Block:
      case Normal:
      case NoTimeoutIfNotHung:
      case ErrorOnExit:
      default:
         System.out.println("Hello");
         break;
1. Open the project properties
2. Click on "Java Compiler"
3. Checkmark "Enable project specific settings"
4. Set all of the drop down menus to 1.7
5. Hit ok
6. Clean the project to trigger a rebuild (it won't rebuild automatically)
If I do the following (at the moment), then the problem appears.
1. Open the project properties
2. Click on "Java Compiler"
3. Clear "Enable project specific settings"
4. Hit ok
5. Clean the project to trigger a rebuild (it will rebuild automatically)
Here's what I see if I do the following...
1. Open the project properties
2. Click on "Java Compiler"
3. Click on "Configure Workspace Settings"
4. I see that the "Compiler compliance level" = 1.7
5. I see that "Use default compliance settings" is checked.

(In reply to comment #6)
> (In reply to comment #4)
> > SendTimeoutFlags is one of the enums in question.  
> Is this the complete example? I get multiple compilation errors with the
> example in question.
The example isn't quite complete.  I don't have a class around the code.  So you can't paste it into an empty file.  However, you can paste the code into an existing class and the problem shows up.  I attached a zip file of a newly created project with just this code.  The error shows up.  The steps in Comment 5 still cause the error to show up or disappear.  I have a feeling that some how the "Compiler compliance level" in the workspace settings isn't working quite right.  I wonder if a file in my workspace settings is corrupted.

(In reply to comment #9)
> (In reply to comment #8)
> > I wonder if a file in my workspace settings is corrupted.
> That's a possibility, because I can't reproduce this on my fresh workspace :(
How do I determine if that is the case and which file is corrupted?  Which folder should I look in?  Would uploading a zip archive a particular folder be helpful?

(In reply to Michael Warner from comment #11)
> Did you ever resolve why this is happening? I'm getting a similar problem. I
> have eclipse installed on two different workstations and get this error on
> one workstation but not the other, for the same code.
The steps mentioned in comment #5 works around the problem for me.

I'm getting a similar issue, which appears to be related to a conflict with Drools 6.0.1 Final, reported here:
http://drools.46999.n3.nabble.com/Drools-causes-switch-enum-e-to-break-td4029233.html
-------------------------
I've reproduced this issue with a simple example: 
1. Create a new "Drools Project" in Eclipse Kepler with Drools 6.0.1.Final installed (JDK 1.7) with simple "Hello World" rule example.  Project builds OK. 
2. Create the following new class: 
public class EnumTest { 
    private enum EnumType { On, Off } 
    private EnumType et = EnumType.On;     
    public EnumTest() {} 
    public String TypeText() 
    switch(et) 
        case On: 
            return "On"; 
        case Off: 
            return "Off"; 
        default: 
            return ""; 
3. Rebuild project.  Eclipse reports Problem: 
    Drools Error: "Cannot switch on a value of type EnumTest.EnumType. 
    Only convertible int values or enum variables are permitted" 
4. Export Ant Build file for the project and run the Ant Build.  Build successful. 
5. Create a vanilla Java Project (no Drools) and add the same EnumTest class.  Eclipse project builds OK. 
As the project builds OK via Ant, it appears that this is an issue with the Eclipse incremental builder conflicting with Drools 6.  
As noted by others, it appears that Eclipse may be reducing JDK compiler compliance level down to 1.5 or referencing JRE 1.5 in class path as a result of this conflict, as I've occasionally noticed it changing these settings in project properties. 
Initially the project was compiling OK with the same code.  Now Eclipse has become unworkable for me.  Are there some cached settings files that I can delete that may fix the issue in the short term?

I see the issue with the latest code. It is 100% reproducible.
(In reply to dj l from comment #14)
> 4. Export Ant Build file for the project and run the Ant Build.  Build
> successful. 
Could you please let me know how did you perform this step.
Thanks

I get the same message.  I am using Luna Service Release 1 (4.4.1) Build id: 20140925-1800, without Drools.
My only non-stock plugins are Subversive - and an uninstalled Subclipse that doesn't seem to have completely gone away.
As with Nathan, changing the Compiler level settings seems to cause a rebuild that clears the messages, but the messages appear to come back with the next rebuild.  (I am suspicious that the compile is triggering an error that should only be triggered with source level < 1.5, but returning the message that is appropriate to the corresponding error for the actual source level.)
I will try re-installing Eclipse from scratch, to get rid of the Subclipse fragments, and see what happens - but I don't understand why either Subclipse or Subversion would affect the build.

Re-installed Luna (and changed from Java package to Java+Report) but still got same message.  That eliminates Subversive and Subclipse from the equation.  Also eliminates Git, Maven, Code Recommenders.
Changing from JDK 1.6.0_37 to 1.8.0 seems to fix that issue.
It may be easier (for me) to try to upgrade our code to 1.8 compliance.

I think the two uses of complianceLevel in org.eclipse.jdt.internal.compiler.ast.SwitchStatement.resolve(BlockScope)'s
checkType: {
block should really be sourceLevel and not complianceLevel.
See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=444402
Sometimes other plugins muck around with compliance levels and
code generation levels incorrectly

(In reply to Stephan Herrmann from comment #26)
> I saw you added restrictions "Security_Advisories" on this bug, accidentally?
Yes, I think if there is a failure due to connectivity problems and you
press the browser back button, sometimes the forms get populated with
odd values.

We just had the same problem in Eclipse 4.4.2 but without Drools.
We had however Subclipse 1.10.9 installed.
The very same setup worked perfect for months on other hosts.
We compile with compliance level 1.8 with class compatibility 1.8 and source compatibility 1.7 against a 1.8.31 server jvm.
Changing source compatibility to 1.8 (giving other (correct) errors) and switching back to 1.7 solved the issue.
Hopefully it does not come back.

I had the same problem today on 4.4.2. 
When checking Project->Prefetences->Java Compiler->Compiler compliance level - it showed grey 1.4 (other compliance level were set to 1.5), but Window->Preferences->Java Compiler->Compiler compliance level was set to 1.5!
After i changed workspace compliance level to some other value and back to 1.5, project compliance showed correct 1.5 and the bug disappeared.
So this looks like it might be related to the incoherent propagation of workspace compliance level to project.

(In reply to Jay Arthanareeswaran from comment #33)
> Good to know that we have a workaround that works consistently. However, we
> are going to need a testcase to come up with a permanent fix.
Jayy - this smells like some caching bug which only happens sometimes, maybe even timing sensitive, so we might never have reliable steps to reproduce.
I'd propose testing scenario where you upgrade Java (new JRE, set compliance level) and recompile.

(In reply to Peter Kundrat from comment #34)
> (In reply to Jay Arthanareeswaran from comment #33)
> > Good to know that we have a workaround that works consistently. However, we
> > are going to need a testcase to come up with a permanent fix.
> Jayy - this smells like some caching bug which only happens sometimes, maybe
> even timing sensitive, so we might never have reliable steps to reproduce.
> I'd propose testing scenario where you upgrade Java (new JRE, set compliance
> level) and recompile.
I have tried a few such scenarios that I could think of. I guess I will have to wait for more information.

I can reproduce the issue 100% in my project which is using ECJ to do in memory compilation against the source code at dev mode. Initially I thought it was caused by Java 8 however when I created a simple project trying to reproduce the issue, I found it can't be reproduced in the simple project.
I am sorry I can't share the entire project here b/c it's a commercial project. Due to this issue we have to use if-else to replace all switch case for enum type values, which is very annoying. I look forward to seeing any updates on this issue.
Refer to the attachment named "The screenshot shows the exact issue happening"

(In reply to Jay Arthanareeswaran from comment #39)
> Gelin, does the workaround shared in comment #32 help in your case?
> Stephan, what do you think of Srikanth's suggestion/guess? Is it worthwhile
> to put that in a patch and test it with people who are facing the issue?
@Jay, I am not using Eclipse IDE. I use the ECJ in my project to compile source code in memory. So #32 workaround doesn't apply to my case.
Here is my code setting compiler options:
    private void configureCompilerOptions() {
        Map<String, String> map = C.newMap();
        opt(map, OPTION_ReportMissingSerialVersion, IGNORE);
        opt(map, OPTION_LineNumberAttribute, GENERATE);
        opt(map, OPTION_SourceFileAttribute, GENERATE);
        opt(map, OPTION_LocalVariableAttribute, GENERATE);
        opt(map, OPTION_PreserveUnusedLocal, PRESERVE);
        opt(map, OPTION_ReportDeprecation, IGNORE);
        opt(map, OPTION_ReportUnusedImport, IGNORE);
        opt(map, OPTION_Encoding, "UTF-8");
        opt(map, OPTION_Process_Annotations, ENABLED);
        opt(map, OPTION_Source, conf.sourceVersion());
        opt(map, OPTION_TargetPlatform, conf.targetVersion());
        opt(map, OPTION_Compliance, conf.sourceVersion());
        compilerOptions = new CompilerOptions(map);
    private void opt(Map map, String key, String val) {
        map.put(key, val);
The sourceVersion and targetVersion in conf are all set to 1.8

(In reply to Jay Arthanareeswaran from comment #39)
> Stephan, what do you think of Srikanth's suggestion/guess? Is it worthwhile
> to put that in a patch and test it with people who are facing the issue?
I assume you're referring to comment 25, but: going by the javadoc from JavaCore.COMPILER_COMPLIANCE if s.o. wants 1.5 features, they MUST set compliance to s.t. >= 1.5. The same seems to be enforced also in Main.validateOptions (see. incompatibleComplianceForSource). So if we encounter compliance < 1.5 I don't see how source could be >= 1.5.
I'd rather suspect that the properly configured compliance level is overwritten during compilation or such.
From attachment 259290 [details] I see that a custom ICompilerRequestor is used. Such a hook into the compiler could potentially mess up internal state of the compiler during compilation.
*Wait*: SwitchStatement inspects complianceLevel but inside ProblemReporter.incorrectSwitchType(Expression, TypeBinding) we check the sourceLevel. That IS inconsistent. I think the very error message:
"Cannot switch on a value of type {0}. Only convertible int values or enum variables are permitted" reveals that indeed we have
  complianceLevel < 1.5
  sourceLevel >= 1.5
We don't seem to need additional checks to find out the broken state when the bogus error is reported.
I don't think Main.validateOptions would have accepted this combo, so s.t. illegal must be happening after initialization.

(In reply to Gelin Luo from comment #42)
> Actually I am wondering why don't set Compliance level to source level by
> default?
From my analysis, at the time when the compiler was configured, we had a legal combination of options but some time later, that configuration was messed up. Correct me if my conclusions are wrong.
Can you provide any information about class act.app.AppCompiler$3 (an anonymous class inside AppCompiler)?
Or even better: if you are able to debug the situation, please set a modification breakpoint on field org.eclipse.jdt.internal.compiler.impl.CompilerOptions.complianceLevel to find out how this is set to s.t. < 1.5? TIA.

(In reply to Gelin Luo from comment #44)
> Hi my bad, the version of the AppCompiler I was using didn't set the
> complianceLevel, after I updated the version, this issue is gone.
So, we are back to the original issue where this issue was only visible only intermittently, aren't we?

(In reply to Gelin Luo from comment #46)
> My understanding is this issue can be easily avoid if the ECJ use
> sourceLevel set by user as complianceLevel if it is not set by user.
If you try to set sourceLevel > complianceLevel via the UI you get an error, options cannot be applied. If you try to do this via the command line, it is rejected.
Clients setting these programmatically must read the Javadoc of org.eclipse.jdt.core.JavaCore.COMPILER_COMPLIANCE and ..COMPILER_SOURCE, which make clear, too, that this combination is illegal.
I personally am not a fan of silently fixing the illegal configuration.
But: maybe we should throw IllegalStateException from CompilerOptions.set() when setting contradictory complianceLevel and sourceLevel. 
Looking at API like ASTParser.createASTs() s.t. like that is even specified already.
Unfortunately, the fan in of CompilerOptions.set() is huge, so it's hard to tell if the exception would upset any clients that don't expect it.

Removing 'needinfo' as I think we pretty much have what we need. It is only a question of the course of actions. Looking at Stephan's comments, I tend to think we don't have much to offer.
Stephan, please correct me if I am wrong.

I had this issue and this got resolved by changing the Preferences>Java>Compiler>Error/Warnings setting "Incomplete 'switch' cases on enum" to 'Ignore' instead of 'Error'.
On further investigation (just before submitting this comment), it is reproducible when the switch doesn't have a 'default', irrespective of whether all the cases are cased or not.

(In reply to Prasanna Kumar Ranjan from comment #49)
> I had this issue and this got resolved by changing the
> Preferences>Java>Compiler>Error/Warnings setting "Incomplete 'switch' cases
> on enum" to 'Ignore' instead of 'Error'.
> On further investigation (just before submitting this comment), it is
> reproducible when the switch doesn't have a 'default', irrespective of
> whether all the cases are cased or not.
Can you please provide an source example that demonstrates your findings?

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.

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.

Just found this bug report, because I am having this issue with Eclipse Version: 2022-12 (4.26.0), Build id: 20221201-1913
I copied code from a class in Maven Dependencies to my project, and it included a switch on an enum. Got this message:
Cannot switch on a value of type <enum from external project>. Only convertible int values, strings or enum variables are permitted
Checked Compiler compliance level in the project and it was set to 1.4, while the JRE version for the workspace is 17. I can confirm that the proposed workaround works: changed the workspace compliance level from 17 to 16 and the error went away. Put it back to 17, then checked on the affected project and it is now saying 17 instead of 1.4.