Community
Participate
Working Groups
I've seen this problem with several 3.2 pre-releases as well as 3.2 proper: I have an enum containing about 30-40 members and a static final int. The enum class itself compiles fine. However, *some* other classes that refer to the enum elements don't compile, complaining about entries that can't be resolved. Other values from the same enum class are referenced just fine in the referring class. The enum elements that fail to get referenced properly are either proper enum members or the public static final int member. I've tried clean builds, but to no avail. If I build outside of eclipse via jdk 1.5.0_06, everything builds fine. Thus, this is either a JDT bug, or I've got something misconfigured. I know for sure that Eclipse is in 'jdk 1.5' mode. If it wasn't all the template stuff I'm doing wouldn't work either. Thanks much.
Can you pls provide exact steps to reproduce ? We did address a couple enum issues lately, which will make it into 3.2.1, see early preview at: http://www.eclipse.org/jdt/core/r3.2/index.php#UPDATES
I've tried to reproduce it in isolation, but to no avail. It only fails in the context of our overall system. Is there any kind of debug logging I can turn on in Eclipse? For example, I could do a 'clean', then turn on some debugging, and then build my project. I could then send you that debug output, which hopefully won't include every line of code in the project! :) In the past I may have sometimes managed to get past the bug by modifying the enum class to have members in a different order...but I'm not sure. Sorry I can't give you a test case, but I am very willing to try anything you suggest and to give you any debug info that may help you.
There is no specific trace which would help you here I am afraid. Can't you attach a project ? Also does problem occur in both clean build and incremental build mode ? Pls check bug 145746, bug 145732 or bug 141810 to see if you recognize something familiar. Last, did you try the 3.2.1 preview I mentionned earlier, it contains fixes for these issues (and many others), maybe this would address your issues as well.
I just downloaded org.eclipse.jdt.core_3.2.1.jar. I put it in my c:\eclipse\plugins directory and started up Eclipse, but it didn't seem to do anything. I then tried updating c:\eclipse\features\org.eclipse.jdt_3.2.0.v20060609m-F7snq1fxia-Z4XP\feature.xml to declare that it's got version 3.2.1 of the jdt core plugin rather than 3.2.0.v_671. That didn't seem to help either. I can't give you a project because I can't give you our code...it's proprietary. Please tell me what I have to do to be sure I'm running with the new jdt. Thanks!
Created attachment 46739 [details] Enum class that compiles, but when referenced doesn't always work. Some classes that reference this enum's elements fail to compile because they claim that they can't find the enum value.
One of my colleagues and I were talking about this a little while ago, and one thing that struck us is that the bug showed up for only one enum class. All of our other enum classes seem to be referenced fine. He did some experiments and figured out the critical difference between the "bad" enum class and the other good ones: the bad one has a non-static method near the end. If he commented out that method definition and re-built, all of the enum reference problems went away (and naturally, those classes trying to call the commented out method now had compile failures). I tried reproducing this in isolation, but to no avail. I'm hoping that this gives you a direction to look in, however. I just attached our "bad" enum class. Hopefully, you'll be able to do something useful with it.
My colleague did some more experiments and discovered that it's not so much about methods being in the enum class. He said even after removing methods from the enum, at some point in time some consumer classes stopped being able to reference the enum elements. He believes that the act of modifying/saving the enum class made problems go away for a little while, regardless of what change occurred. We both also have wondered, "What's different about this enum than other enums we use?" This is a bigger enum class than any other that we use in our project, and it's name is BeanName. Is there anything significant about the name of the enum class? Maybe there's an underlying name resolution bug and we're picking up a different BeanName class in the referents.
The enum class that's giving me trouble is BeanName (attached to this bug a few weeks ago). Classes that have trouble referencing enums in BeanName compile fine if BeanName is already compiled (e.g. an incremental build launched when I make a dummy modification of a class the refers to BeanName).
Thanks for the testcase, will look into it. (delay is due to vacation time)
Cannot reproduce on your testcase. Could you attach an example of some referencing file which doesn't work ?
Added EnumTest#test136 (with simple ref to offending BeanName enum).
Removing 3.2.1 tag until further reproduced/assessed.
It seems I can no longer reproduce the issue. I've tried several clean builds, but it never fails as it did before. I suspect that as our code evolved, whatever triggered this bug seems to have stopped. I suspect there is a race condition between BeanName being built and its consumers. Thus, a dummy modification of one of the consumers and doing an incremental build would make the problem go away because BeanName is already compiled at the time of the incremental build. Sorry I can't give you more (well, half-sorry. I'm half-relieved that I'm not experiencing the issue any more... but of course some other random change in our code might tickle this again). Also, I did reproduce the issue on 3.3M1, but there's no way to know if I reproduced it on 3.2.1 since I couldn't find the instructions for how to install the 3.2.1 jdt into my 3.2.0 setup (am I supposed to look at "Getting the sources"? "build notes"?)
Will close it as REMIND, i.e. if you see it again and have better luck finding steps, then pls reopen it.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
