Community
Participate
Working Groups
With 3.2 RC6, no plugins, default configuration, running against JDK 1.5.0_06: I am getting the Java editor produce red squiggly underlines and apparent compilation errors where I shouldn't. The code below is valid, and produces no output in the Problem View, but is underlined in red in the editor and produces the following tooltip error message: "The type java.util.concurrent.Future cannot be resolved. It is indirectly referenced from required .class files" package com.x.y; import java.util.concurrent.Callable; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class Main { public static void main(String[] args) { ExecutorService executor = Executors.newSingleThreadExecutor(); executor.submit(new Callable<String>() { public String call() throws Exception { return "Hello"; } }); } } The red squiggle lines underline the executor.submit statement. I have noticed this with other, equally valid constructs concerning the Concurrent package. If I ensure the "refresh workspace on startup" option is selected; close and reopen the workspace, the squigglies disappear and all is well. The same happens if I open the workspace back up in RC5. This has happened on a number of my workspaces, both existing ones upgrading from RC5 and new ones started with RC6. The test case above was with a brand-new workspace. This did not occur on previous release candidates. I haven't delved deeper yet to see if it only happens on the concurrent stuff - don't see why it should - its just that this is what I'm using at the moment.
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 ***
