Community
Participate
Working Groups
Using Eclipse 3.2 RC3 When developing classes that extends javax.swing components using Java 1.5.0_06 I get a spontaneous error "The type java.util.Set cannot be resolved. It is indirectly referenced from required .class files". This error doesn't appear in the Problems list, but ONLY at the left bar of the class edited. It seems to be attached to the class in some way because when I open a different class it disappears. Restarting the workbench helps for the moment. It seems to be triggered by the error marking in the editor, but since it is easy to overlook it's not easy to catch it in the making. It seems to appear when extending javax.swing classes. Example: Issue New->Class, Name the class ToolsMenu, Click on the "Browse" and select javax.swing.JMenu, check "Constructors from superclass", "Inherited abstract methods" and "Generate comments". If the error appears at the topmost left corner of the editor pane (not always) the constructors aren't inherited from the superclass either. (maybe a lead here). This error was present both in RC2 and RC3. And there are no other classes or project dependencies in the project involved.
Jerome - pls investigate
I cannot reproduce. I started a new workspace on a 1.5.0_06 VM, created a new Java project (accepting all defaults) and followed your steps. ToolsMenu.java was generated and opened in the Java editor with no errors in this editor. Please reopen if you have more details to reproduce this problem.
The problem with this bug is that it isn't appearing directly, but after a while when editing, and in that case it seems to be related to the error marking. It IS elusive, and annoying, especially when it's just appearing. The key issue is that it's appearing after editing a while, and it isn't necessarily related to the swing classes, but does also appear without swing dependency. It is more related to the error marking in the editor. I have tried re-creating the workspace, and then importing my projects again into the new workspace but after some time this error occurs again. What I haven't tried is to re-install the whole OS. Eclipse is installed "fresh" into an empty directory, and then I added: GEF-ALL-3.2RC2a.zip wtp-S-1.5RC2-200605051426.zip emf-sdo-xsd-SDK-2.2.0RC3.zip VE-SDK-1.2M3.zip So it may be that some of the added components aren't really compatible with RC3, but as I work extensively with them it's hard to be without them.
Created attachment 41181 [details] Current configuration details
Sorry Nils, but I have been working with an Eclipse install that has all Callisto projects for several weeks now, and I've never seen this problem. I don't see any difference in our config either.
I'm seeing the same error. It doesn't prevent me from running my application at all and doesn't appear in my "Problems" list, but does appear as an error icon in the margin. I too am doing Swing development, but not with the visual editor. I'm using the Sun JDK version 1.5.0_06. I've seen this in 3.2 RC3 and 3.2 RC4
3.2 RC1 does not exhibit this problem. I have not tried 3.2 RC2.
One more report: With 3.2 RC2 it happened twice a day or so. With 3.2 RC4 I get this error about 1 - 5 times per hour. This is probably depending on what or how much I type. The error seems to show more often when Swing is involved, but it's not restricted to working with Swing. In some rare cases, the Type that cannot be resolved is not "java.util.Set" but "java.lang.Object". This whole problem occurs with the linux-gtk build (both RC2 and RC4) as well as with the win32-build (both RC2 and RC4) running on Windows XP Pro. At first I thought it was the "Extended VS Presentation" and/or "AnyEdit tools", plugins, but the error also occurs on fresh installs without any additional plugins and also with new workspaces. When the error occurs, "Content Assist" is sometimes unable to provide anything and editor markings don't really work: 'marking occurences' marks almost nothing, warnings and tasks are sometimes reduced. Restarting eclipse (or switching workspace) does help, as well as changing the build path: Adding a second JRE System Library to the project's build path (or removing it if you already have two on the build path) does clear the error. A simple clean / rebuild does NOT help.
I can confirm the sightings and to me it seems to be a kind of memory leak, and I wonder if it is related to Bug 139429, which I also filed and that occurs also after a time when WSDL files are involved in the workspace. So it may be two symptoms of the same error.
(In reply to comment #9) > I can confirm the sightings and to me it seems to be a kind of memory leak, and > I wonder if it is related to Bug 139429, which I also filed and that occurs > also after a time when WSDL files are involved in the workspace. > > So it may be two symptoms of the same error. > I fail to see how these 2 problems are related. When you get the "The type java.util.Set cannot be resolved" error, is there anything in the .log file indicating that an OutOfMemoryError due to no perm gen space left occured ?
I also experience this problem, exactly as described in the initial report. I am using Eclipse 3.2 [Version: 3.2.0 Build id: I20060505-1306], and the problem occurs on both Windows 2003 [SP1] using JDK 1.5.0_06 and Fedora Core 3 [ 2.6.12-1.1381_FC3 ] using JDK 1.5.0_04. I am editing a 'normal' Java project (which does involve Swing) through CVS. There are no dependencies outside the standard Java packages. I Suggest you change OS from 'Windows XP' to 'All'.
The problem also affects debugging: if the breakpoint is in a file with such error, selecting "Inspect" on a variable brings up window with the above mentioned error message "java.util.Set cannot..." as a "value" for this variable. Eclipse 3.2 RC4, JRE 1.5.0_06 on Windows XP. I suggest upgrading priority of this bug.
I was also considering a higher priority on this bug earlier, upgraded the impact to Major. It is worth to notice that this bug occurs after a varying amount of time, sometimes within a few minutes, sometimes not even after an hour. (Race condition?) I'm currently running the same setup on two different machines, one with a Pentium M 1.4GHz processor and one with a Pentium4 2.6 GHz processor. I haven't yet seen the problem on the Pentium M processor machine. It is still present in 3.2RC5.
I understand this problem is annoying. Unfortunately, I have not been able to reproduce so far, and looking at the code, nothing obvious indicates how this can happen. Can you please confirm that this happens only while editing (i.e. you are not doing any other action in the IDE such as changing the build path, changing default JRE, etc.) ? Also can you please confirm that your .metadata/.log file is empty ?
A slight change is done to the default JRE, but that is well before the problem occured. I have renamed the default JRE from "jdk1.5.0_06" to just "1.5.0" so that projects that depends on a specific JRE on different machines will work better. No changes to the JRE path, and the JRE is the default JRE. The problem is occuring during ordinary editing, cut/paste, SHIFT+CTRL+F, SHIFT+CTRL+O, frequent saving... No big surprises. The only thing that seems to affect the appearence of the error is that it occurs whenever the code contains an error (or possibly warning) itself. I have increased the "paranoia" level on the compiler warnings also and also added warnings on JavaDoc. Set-up on Pentium M (where the error doesn't appear for the moment): Code Style: All except "Undoc. empty block", "Param assignment" and "Non-externalized..." Potential programming...: All except "Empty statement" and "Switch case fall-through" Name shadow...: All except the checkbox for "Include constructor..." Deprecated...: All except the checkboxes. "Forbidden..." as Error. Unnecessary code: All except "...cast or instanceof..." and "...declaration of thrown checked exception..." Generic types: All except "usage of raw..." Annotations: All except "Missing @override" and "Missing @deprecated" (checkbox checked) I'll come back with the setup of the error settings of the other machine. Another difference is that the Pentium M machine are running JDK 1.4 projects while the other machine is running 1.5 projects, so this may depend on the selected JRE version.
Thanks for the reply. I have more questions for you. 1. When you see the "java.util.Set cannot be resolved..." error in the editor, can you make it disappear (e.g. by fixing the first problem, or by replacing with the previous edition from local history) ? 2. When the "java.util.Set cannot be resolved..." error appears in an editor, if you create a new .java file with a reference to "java.util.Set", does this second editor also contain a "java.util.Set cannot be resolved..." error ?
(In reply to comment #16) > Thanks for the reply. I have more questions for you. I have some answers, too: > 1. When you see the "java.util.Set cannot be resolved..." error in the editor, > can you make it disappear (e.g. by fixing the first problem, or by replacing > with the previous edition from local history) ? I can make it disappear. See comment #8. Adding an additional JRE System Library to the build path or removing the additional JRE from the build path if it was already added. > 2. When the "java.util.Set cannot be resolved..." error appears in an editor, > if you create a new .java file with a reference to "java.util.Set", does this > second editor also contain a "java.util.Set cannot be resolved..." error ? Creating a new .java file with a class implementing java.util.Set or extending any class that implements java.util.Set works fine. A simple class just using java.util.Set (and HashSet) can be written, compiled and run successfully. However, if I create a .java file with a class that has java.awt.Container in its hierarchy, the error shows up. Extending java.awt.Component (or java.awt.Component based classes) works without error. Extending java.awt.Container (or java.awt.Container based classes) does show the error in the editor. There is no message in .metadata/.log
> > 1. When you see the "java.util.Set cannot be resolved..." error in the > > editor, > > can you make it disappear (e.g. by fixing the first problem, or by replacing > > with the previous edition from local history) ? > > I can make it disappear. See comment #8. Adding an additional JRE System > Library to the build path or removing the additional JRE from the build path > if it was already added. > Yes this is expected since changing the build path will flush all caches. I was wondering if you could 'fix' the problem by simply editing e.g. by fixing the first problem, or by replacing with the previous edition from local history) > > 2. When the "java.util.Set cannot be resolved..." error appears in an > > editor, > > if you create a new .java file with a reference to "java.util.Set", does > > this > > second editor also contain a "java.util.Set cannot be resolved..." error ? > Let me reformulate that. When you see a "cannot be resolved" error in editor X, can you please create a new Compilation unit Y.java, edit it and add a reference to the very same type that cannot be resolved ? Do you see the same error in editor Y.java ?
(In reply to comment #18) > I was wondering if you could 'fix' the problem by simply editing e.g. by fixing > the first problem, or by replacing with the previous edition from local > history) No. I couldn't fix it this way. Anyone else? > Let me reformulate that. When you see a "cannot be resolved" error in editor X, > can you please create a new Compilation unit Y.java, edit it and add a > reference to the very same type that cannot be resolved ? Do you see the same > error in editor Y.java ? I was referring to that when I wrote "A simple class just using java.util.Set (and HashSet) can be written, compiled and run successfully.". After the error appeared, I created Test.java with something like this: --------------8<-------------------8<------------------- import java.util.Set; import java.util.HashSet; public class Test { static void go(Set<String> set) { for(String s : set) System.out.println(s); } public static void main(String args[]) { HashSet<String> hashSet = new HashSet<String>(); hashSet.add("test"); go(hashSet); } } --------------8<-------------------8<------------------- The editor didn't display any error and Test could be compiled and run. Meanwhile some other editors still showed that "java.util.Set cannot be resolved..." message.
Thanks for the clarification. It is very weird though, since the same cache is used by both editors, I don't see how one could find java.util.Set and the other would not.
I restarted eclipse today, and after some time the bug reappeared (as usual). The only files with today's modification time in .metadata were: version.ini; .plugins/org/eclipse/jdt/core/savedIndexNames.txt (the most recent mtime) D:\project\public\.metadata\.plugins\org.eclipse.core.resources\.root\.indexes\properties.index It's a fresh install of 3.2 RC5 without any additions, on WinXP. I removed the .metadata subdirectory before using it, just in case. By the way, my CPU is Pentium M with dynamic speed switching - the clock frequency varies from 800MHz to 2GHz depending on load. This may lead to unexpected timings, e.g a "heavy" thread actually completes faster than a "light" one. This is probably not relevant, but who knows...
(In reply to comment #20) > Thanks for the clarification. It is very weird though, since the same cache is > used by both editors, I don't see how one could find java.util.Set and the > other would not. > Further data: When the error has appeared you can create a new class extending java.lang.Object where the error doesn't show up, but if you create a new class extending java.awt.Container it will be there right away! I also did an analysis of the class java.awt.Container, and the import is a bit down in the list of imports.
Interesting observation: I did edit a class WITH dependecy on Container (and stopped editing before the error showed up), and then opened a new window without that class involved and did some editing. When I got back to the window with Container the error was there.
Still present in RC6.
Created attachment 42821 [details] Eclipse Configuration Mac OS X
I am experiencing this bug on Mac OS X. I am developing a Swing app as well. I attached the config to the attachments. I wanted to add that I get the error during debugging. Shift-Apple-D (Display) causes the same error dialog. I will add however, it isn't consistent. Unfortunately.
I have narrowed it down a little, and one operation that seems to trigger it is when typing "this." and then selecting the item from the pop-up. However, I haven't narrowed it down to the other surrounding requirements necessary for it to be triggered, since it isn't sufficient to do it in a simple class.
Yet more information. It really seems like it is some kind of race condition that occurs, because I entered the following code: --- import java.awt.Dimension; import javax.swing.JFrame; public class MainFrame extends JFrame { public MainFrame() { Dimension d1=new Dimension(640, 480); this.setSize(d1); } } --- The FIRST time I did it I got the error when entering the "this." and selected the "setSize" from the pop-up, but when I tried to re-create it I wasn't able to. In some way it seems to depend on the complexity of the code. Scratching my head over this one...
(In reply to comment #28) > The FIRST time I did it I got the error when entering the "this." and selected > the "setSize" from the pop-up, but when I tried to re-create it I wasn't able > to. > > In some way it seems to depend on the complexity of the code. It's simply a nasty bug that just tries to keep alive ;-) 3 days ago I was under the impression that long identifier names and Content Assist could have something to do with it. I was able to reproduce the error 8 times in a row (with eclipse restarts in between!) by creating a new compilation unit: --------------------8<-----------------------8<-------------------------- import javax.swing.JButton; import javax.swing.JComponent; public class Test extends JComponent { private JButton wonderfulButtonWithLongName; public Test( String name ) { wonderfulButtonWithLongName = new JButton(); } } --------------------8<-----------------------8<-------------------------- No error showed up after finishing this. Then I typed "wonderfulButtonWithLongName." after the "... new JButton();" line. I browsed the the popup for a few seconds and chose something randomly (for example setVisible()). The editor immediately showed the message about java.util.Set. Then I changed "wonderfulButtonWithLongName" to "b" and tried again. The error did not show up. I renamed "b" back to "wonderfulButtonWithLongName" and the error still didn't show up. I restarted eclipse a few times and tried again. Nothing. In fact: The error did not show up for the rest of the day. That is a big difference to the 8-times-in-a-row experience from the beginning of the day. Still nothing in the logs.
Created attachment 43049 [details] Stacktrace from eclipse debugger attached to eclipse w/ error
Since I am regularly able to reproduce the problem, I fired up the debugger and quickly got in over my head. I inspected the stack (which I have attached), and the first place where things look wrong to me is: method: MethodVerifier15.areMethodsEqual() argument: one value: void setFocusTraversalKeys(int, java.util.Set<? extends Unresolved type java.awt.AWTKeyStroke>) argument:two value: void setFocusTraversalKeys(int, Set<? extends java.awt.AWTKeyStroke>) I hope that helps.
Thanks for your efforts. This confirms that the type java.awt.AWTKeyStroke could not be resolved. If we could find why it could not be resolved (when java.util.Set which is in the same .jar file was resolved), that would solve this bug.
It might be a long shot... but I changed the way a .class file is read and put in the cache. Could you please delete org.eclipse.jdt.core_3.2.0.v_668.jar from your plugins directory, copy http://www.eclipse.org/jdt/core/patches/org.eclipse.jdt.core_3.2.0.z20060531-1812.jar to this plugins directory instead, and let me know if this improves things ?
(In reply to comment #33) > It might be a long shot... but I changed the way a .class file is read and put > in the cache. Could you please delete org.eclipse.jdt.core_3.2.0.v_668.jar from > your plugins directory, copy > http://www.eclipse.org/jdt/core/patches/org.eclipse.jdt.core_3.2.0.z20060531-1812.jar > to this plugins directory instead, and let me know if this improves things ? > That appears to have fixed it. I have now been working with eclipse for 1 hour withouth the problem, and I could depend on getting it within 2 minutes without that change.
(In reply to comment #33) > http://www.eclipse.org/jdt/core/patches/org.eclipse.jdt.core_3.2.0.z20060531-1812.jar > to this plugins directory instead, and let me know if this improves things ? I still get the error. I hoped it would be fixed, because I didn't get the error yesterday, but today the error started to appear after 40 Minutes of editing.
A new twist: today I got similar message "The type java.lang.Class cannot be resolved. It is indirectly..." and so on. The error marks my var.getClass() call (var is a local variable). This line hasn't changed for months. This is different from "java.util.Set" family of this bug in the fact that the error marker appears in a line of code, while the "Set" bug marker has always appeared in the very first line of file (even if it was a comment). And similarity is in the fact that the error marker does not appear anywhere else and does not prevent me from running the program.
(In reply to comment #36) > A new twist: today I got similar message "The type java.lang.Class cannot be > resolved. It is indirectly..." and so on. The error marks my var.getClass() > call (var is a local variable). This line hasn't changed for months. > This is different from "java.util.Set" family of this bug in the fact that the > error marker appears in a line of code, while the "Set" bug marker has always > appeared in the very first line of file (even if it was a comment). And > similarity is in the fact that the error marker does not appear anywhere else > and does not prevent me from running the program. > Boris, are you running with the patch from comment 33 ?
(In addition to #36, reply to #37) No, I use 3.2RC5, Build id: I20060519-1206, with no changes.
I finally was able to find reproducable steps: 1. Start a new workspace on a 1.5.0_06 VM 2. Create a new Java project (accepting all defaults) 3. Create a new class X in default package with the following content: import javax.swing.JFrame; public class X extends JFrame { void foo() { //this.getFocusTraversalKe } } 4. Leave the editor on X.java open 5. Ctrl+Shift+T 6. Select Set (this opens another editor on Set.class) 7. Exit and restart the workbench 8. When the workbench is up, the focus should be on the Set.class editor 9. Give focus to the X.java editor 10. Uncomment //this.getFocusTraversalKe 11. Place cursor just after 'getFocusTraversalKe' 12. Ctrl+Space 13. Enter (to accept first proposal) Observe: You get the 'java.util.Set' error on the first line of the Java editor for X.java
I identified the cause (bad side effect on a MethodInfo in the Java model cache) and posted a patch. Could you please delete any org.eclipse.jdt.core_3.2.0.*.jar from your plugins directory, copy http://www.eclipse.org/jdt/core/patches/org.eclipse.jdt.core_3.2.0.z20060602-1334.jar to this plugins directory instead, and confirm this fixes the problem ?
Created attachment 43341 [details] Proposed fix This is the code change for the patch in comment 40
Mike/Dani/Martin - late candidate for 3.2.0 inclusion. This defect has 3 dups we think; and many people who develop Swing apps seem to find it. It is a regression over 3.1: basically our javadoc extraction support has a small side-effect on a char[] which it shares with the java model. The fix is trivial (clone a char[]), and avoids transient errors in editor about missing types. I know it is late, but it is quite proeminent in certain cases. Either we would need to call for another build today, or we keep it for later, but still within 3.2.0.
(reposting with better wrappering) Mike/Dani/Martin - late candidate for 3.2.0 inclusion. This defect has 3 dups we think; and many people who develop Swing apps seem to find it. It is a regression over 3.1: basically our javadoc extraction support has a small side-effect on a char[] which it shares with the java model. The fix is trivial (clone a char[]), and avoids transient errors in editor about missing types. I know it is late, but it is quite proeminent in certain cases. Either we would need to call for another build today, or we keep it for later, but still within 3.2.0.
Suspecting bug 144477, bug 144099, and bug 144218 to be duplicate of this bug.
*** Bug 144477 has been marked as a duplicate of this bug. ***
+1
+1 for 3.2RC7 Dani/Martin ?
+1 after discussions with Philippe. The modification of the model looks nasty and may be the cause of several bugs that are hard to detect.
Released fix from comment 40 into HEAD.
Verified with I20060602-1317 for RC7.
Created attachment 43453 [details] Regression test
Released regression test
*** Bug 144099 has been marked as a duplicate of this bug. ***
*** Bug 144218 has been marked as a duplicate of this bug. ***
