Summary: | Invalid "indirectly referenced from required .class files" reference in Java editor | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Ian Brown <ian> | ||||||
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> | ||||||
Status: | RESOLVED DUPLICATE | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | daniel_megert | ||||||
Version: | 3.2 | ||||||||
Target Milestone: | --- | ||||||||
Hardware: | PC | ||||||||
OS: | Windows XP | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Ian Brown
2006-05-29 09:10:03 EDT
Unfortunately I cannot reproduce this problem. Do you have more details on how to reproduce it ? Unfortunately, the scenario I suggested was all that I needed to do... 1) Set up 3.2 RC6 default installation 2) Run with new workspace 3) Create the class as described 4) Notice the problem It originally happened on a workspace I was migrating from RC5, so I went for the new install/new workspace to try and eliminate migration issues I applied no configuration changes, so it was actually running against the 1.5.0_06 JRE in the first instance, but switching to the JDK made no difference so it was: CD \<dir> \eclipse\eclipse.exe -data workspace wish I could offer more - I found this completely reproducible. I used code-complete to build this. Um. Dunno what else to put I'll have another go and see what happens OK. I've completely failed to reproduce this on the machine on which I originally had this happen (although I did make it happen 4 or 5 times before submitting the original report) I had now got it happening on another machine (same setup - clean install, clean workspace) After putting in this line: ExecutorService executor = Executors.newSingleThreadExecutor(); auto-complete on "executor." is not even listing the submit() methods (presumably as it can't resolve Future?) If I write the remainder of the method as: Future<String> future; future = executor.submit(new Callable<String>() { public String call() throws Exception {} { return null; } }); the squigglies only kick-in on the executor.submit(...) statement. The declaration of 'future' is not identified as a problem. I will attach the .log file as this may contain further clues Created attachment 43072 [details]
Log file from clean install when reproducing this problem
Not sure how related this is to the issue, but I guess any sort of JavaModelException might throw out the parsing and lead to spurious problems, so there could easily be a connection
OK, and I have just changed this workspace to use the JDK, not the JRE and the squigglies have gone Points of note: 1) When I originally had this problem (on a migrated RC5 workspace), I would have (*almost* certainly) been already looking at a JDK, not a JRE. 2) Another difference between the JDK and JRE here is the spaces in the filepaths to the rt.jar etc - which /could/ be a complete red-herring 3) The log file for the machine on which this initially happened also shows that a Java Model Exception was thrown - but for different reasons. I'll attach that .log too Created attachment 43076 [details]
Log file from another machine on which this problem occurred
It can be seen that a similar exception is occurring, but for different reasons (I was offline at the time)
The JavaModelExceptions are also a red-herring. They just indicate that the attached Javadoc cannot be retrieved, but the Javadoc is not used by the name lookup. As nothing more than an idle curiosity, on the install where this doesn't happen, when I do Ctrl+Space on Callable to add the import statement, code-complete comes up with Callable<T> but when I do it in the workspace where it does occur, it comes up with Callable<V> No matter - just odd I wish I could help more - this definitely happens, and has done so a few times 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 ? Please ignore patch in comment 9. I identified the cause (bad side effect on a MethodInfo in the Java model cache) and posted a new 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 ? If the patch fixes the problem, this bug would be a dup of bug 140879. Well, a little early to say yet, but the problem has not re-occurred with this patch whereas it was fairly easy to reproduce previously. I notice that the fix you proposed for 140879 has been released in RC7. I'll give that a go and see if all is well Have not yet been able to reproduce this in RC7. Will keep trying though Assuming you've not seen the problem since 3.2 RC7, I'm closing this as a dup of bug 140879. *** This bug has been marked as a duplicate of 140879 *** |