Eclipse “cannot be resolved to a type” error

So I’m coding along and all of a sudden, Eclipse (3.4) can’t resolve classes. Classes that are in the same package as the class I’m editing. Classes that are fully qualified in the import statement.

Not good.

The last thing I had done was add a Spring @Autowired annotation. I saved the file and voila, everything goes to crap. I then spend a stupid amount of time trying to track down the cause. I took the changes out. I did a clean and rebuild and retest (everything passed; this was Eclipse-only). I added new classes to see if they broke (they did). I did a false modify (add space, remove space, save) to see if that broke said file (it did). It was a death spiral. No matter how I changed the code, the same problem was there.

Turns out, it wasn’t the annotation, or anything else in Spring, or any of my code, or any of my Eclipse plugins. It was a step before that killed me. I was doing a little cleanup and I created a temp directory at the top of my project folder so I could move some files there. It wasn’t nested in anything, other than the top level directory. What could go wrong?

Apparently, that makes Eclipse see red. Squiggly red.

The solution was simply to do a refresh (F5) on my project. Just as quickly as it started, the problem went away. That smells like a bug to me, but if it was I figure I’d see a lot more mentions in Google or the Eclipse bug tracker. I’m really hoping this helps someone save some time.

Update: If that doesn’t work, try:

Clean, refresh, build, restart

Also, remember any external build/clean scripts you might be using. For instance, Grails has a command line “clean” you may have to invoke. Same if you have Ant or Maven builds.

David Resnick (comment below) discovered this tip for those with an external build script:

Windows–>Preferences–>Java–>Compiler–>Building–>Output folder–>”Rebuild class files modified by others”.

This exists in Eclipse 3.5; I’m not sure about earlier versions.

Another issue I’ve found over the years is problems when upgrading Eclipse. In theory, new versions of Eclipse should update your workspace and project files just fine. In practice, they can become corrupted. My new rule is to create a new workspace for every major version upgrade of Eclipse (maybe more often if you’re cautious). Then I copy those projects and import the copy. This ensures I have a backup plan should something go awry. You may need to reimport your project(s) if there’s a problem that won’t go away after an upgrade.

Many commenters offered other solutions, so check below. Thanks to those who contributed them!

Update: I switched to IntelliJ. Click that link for details why, it’s not the usual hand-wavy “it’s just so much better” that never got me to switch. Not saying it’s bug free, but nothing is, and I’ve never seen errors like this there.

Keywords: false error, bogus error, eclipse bug

103 thoughts on “Eclipse “cannot be resolved to a type” error”

  1. Thanks for your article. I had the exact same thing happen to me at the end of a Friday. I decided to hold off tackling the problem until Monday morning. I came and did a little searching and found your article.

    You helped me save some time!

    I am using the M2 plugin from Sonatype and found that I needed to do a Maven clean/install as well.

  2. hi,
    unfortunatelly, ur solution didnt help me.
    i am having this problem for some time now. usu. it is fixed when i do a clean, and-build, refresh, but now for some reason it doesnt work anymore…

    any suggestions are most welcome..

  3. Hmm, not sure what to say. I imagine you’ve tried restarting and if that doesn’t work, exiting/relaunching (sometimes restart clear everything out). Possibly export/import might fix it if there’s something wrong with your .project. Clearly, I’m just guessing here. I’d try an Eclipse forum or your local JUG mailing list if you can’t solve this quickly.

  4. I had the same problem and neither refreshing nor restarting worked. What worked though was deliberately making a syntax error in a type that couldn’t be resolved (despite being in the same package …) and saving the file.

    It’s a weird bug in Eclipse that happens from time to time for no apparent reason. Most of the time a refresh does the trick though.

  5. Its obvious that its a strange Eclipse bug.. Refreshing the project didn’t help me either. The solution for me was deleting the project from the workspace and importing the project again.

    Thanks philip

  6. This stupid eclipse bug is killing me.
    Whenever I save a file I see those abominable red squiggly lines.
    When I do project->clean they disappear all at once, but when I save the file again they reappear…

  7. This was killing me too. Project -> Clean worked for me but I wanted a more permanent solution.

    Having worked for several hours just in Eclipse without a problem, I ran an Ant build externally and sure enough, the problem came back with my very next Save in Eclipse. I realized that my Ant task was deleting the class folders that Eclipse was compiling to. (Ant would empty ./build, then compile to ./build/web-inf/classes, and Eclipse to ./build/classes. My ‘clean’ task simply wiped out all of ./build. Then when Eclipse auto-compiled a class, it wouldn’t find any of the other required classes.)

    My solution was to either point Eclipse to the EXACT same output folder as Ant (so everything would be in the right place after an Ant build) or point Eclipse at some other location that Ant doesn’t touch.

    Hope this helps someone!

  8. I use the Ant builder too.

    I fixed the problem by changing the eclipse build folder to “build2” so Ant and Eclipse don’t share their build folder.

    Thanx Stephen

  9. Based on the comments here, I started checking how I could make sure that my Ant build wouldn’t interfere with my Eclipse build.

    I found an option in Eclipse that clears up the problem (and is possibly more efficient than changing the 2 build system’s output folders).

    Windows–>Preferences–>Java–>Compiler–>Building–>Output folder–>”Rebuild class files modified by others”. This exists in Eclipse 3.5; I’m not sure about earlier versions.

    Checking this seems to have fixed my problems.

  10. Many thanks for this blog contribution, Philip.

    It helped me solve a vexatious problem on which I spent a lot of time trying to solve.

    I finally saw the parallel between your problem and mine, and I finally could say: SOLVED.

    Many many thanks

  11. Comment by David Resnick worked for me too, thanks.

    It seems all class files aren’t the same? If Ant compiles the .class file to the (shared) build path and it’s up-to-date Eclipse determines by default that the file shouldn’t be overridden.

    The ”Rebuild class files modified by others” setting tells Eclipse that if it needs the class file rebuilt (in a different format? or does it include extra properties) to just do it – rather than reporting problems about the class not existing.

    Note, in 3.5 you could also have this setting on the project itself: Right-click the Project ->Properties->”Java Compiler”->Building->”Enable project specific settings”->”Rebuild class files modified by others”

  12. Hey Guys,

    THANKS A LOT for the comments regarding this “bug”. This problem was killing me !!!

    Now my world is wonderful again 😉

  13. Thanks to David Resnick for his comment.

    Thanks to Philip Yurchuk for this article.

    My workspace is red-squiggle-free again, and all is well.

  14. Yup, Project -> Clean did it for me, just as well too as the laptop was heading for the window. You’ve saved my sanity and my laptop repair bill.

    Huge thanks

  15. Twice done succesfully. Disable “Build Automatically” and press File>Refresh (F5). Then you can enable “Build Automatically” and it will work.

  16. Thanks! Your article helped!! For me, i was trying to refresh the whole project and still errors were present. Then i refreshed only the concerned packages where errors were appearing and this time ‘refresh’ worked…All errors gone now..But its lil strange

  17. Thanks! I needed a “mvn clean install”. The problem started when an error crept into the install goal and it only partially finished.

  18. Yeah, i did a mvn generate sources which sorta fixed the errors although it still showed errors in the class file below the java file. Then when i closed and re-opened the project, wa-la error gone. Gotta love those kind of IT problems :-LOL

  19. I have to add my name to the long list of those paying homage. This bug almost ruined my XMAS! I could almost rewrite that 12 days of xmas song with a new idea I had to attack a problem nearly as frustrating as japanese knott weed or a rodent infestation.

    I found your blog. Thanks Phillip. The rebuild stuff is just 2nd nature to Java programmers so that had all been done. Likewise the point at a diff build folder didn’t feel right. A couple of the other solns didn’t feel good either.

    David hit the nail on the head. Infestation gone with 2 shakes of a cats whiskers. Truly thank you. I would ocasionally build xternally with Maven just to keep that non-ide build on track. That killed it. Now I get to continue on my path – glad to have crossed yours.

    Thank you both.

  20. Refreshing the project didn’t help, but deleting the project from the workspace and re-importing the project did.

    Thanks kamil!

  21. Thanks to David Resnick which corrected my recurrent problem.
    I am used to the “mvn clean install” command runned externally.

  22. I’m just getting started with Eclipse, and am still in my petulant “man, I wish this was Visual Studio” phase. But this bug made me feel much more at home.

    I’m deleting the contents of my “bin” folders from the command line, so that I can compress my project folders better. That causes this bug. I am able to fix it with the “cause syntax error, save, remove it, save again” technique, as well as with the “clean project” option.

    Thanks for this post. Maybe in another two years they’ll fix it. Until then, keep up the good work!

  23. to fix this you can either create your variable name using the package

    p1.Person p = new p1.Person();


    use the “set the import declarations for running code” button at the top of the window center right

  24. Hi all, i have some code in some different package, and when i try to use this package and its methods it is showing error as cannot be resolved to a type. i have tried the above mentioned techniques but could not solve the problem.

    Please help me out asap.

  25. This thread helped me alot, tried refresh, maven clean-install, but didn’t worked.

    Finally i made some deliberate syntax error, saved file, undo syntax error, again saved files & all errors were gone

  26. I have tried all the options in the blog and in the comment. Nothing helped. I am using maven and had other components. I wanted to debug them. But I have to close that component in order to start the project. I tried Maven > update project configuration. It solved my issue.

  27. If you use a library that requires Java 6, while using Eclipse’s 1.5 level compiler settings, Eclipse does this.

  28. Man, thank goodness for pdu’s entry from May 6 2009!

    Same thing happened to me so I did what pdu said and introduced a syntax error intentionally (though I have a bunch of files/classes and had to introduce a bunch of errors, one for each file/error combo).

    Then, and only then, could it get rid of the error. Man, I’d be using NetBeans if I could. Silly Eclipse….


  29. I tried all the options stated above nothing worked…One of my friends faced same issue and she suggested to remove all the jar files and add again and then refresh and build…This solved my issue…

  30. Hello,
    I did an uncheck auto build and David Resnick comment and then did a clean all. It worked!
    Many thanks

  31. I had a similar problem; the difference was that I use ant in the command line to build, not enclipse (so build automatically is disabled).

    As for others, suddenly it started showing “-cannot-be-resolved-to-a-type” errors.

    After being stuck for hours; I tried the following (not sure why I did):

    select an error in the “problems” tab and delete it. It worked.

    So I selected all of them and simply deleted them.

    Who would have thought!

    (Btw its Eclipse’s unreliability the reason that I build everything from the command line)

  32. This tiresome bug haunted me for abot TWO hours!!!!!
    Luckily Closing project, Open Project, Project–>Clean did the trick!!

  33. I have had this problem for a long time with Eclipse Helios. Usually doing a Project Clean and then a project Refresh clears it up. Not today. I do most builds with Ant and that seems to mess it up. I agree it is a bug and a very annoying one.

  34. Thanks a million for the “project – clean” suggestion. I had the same problem and this solution worked for me. Good times 🙂

  35. The way it worked for me was to include all .h files that the red underline refer to, compile it clean, and then remove them. Seems that Eclipse has problem to automatically find the path but once does it holds into it.

  36. This kind of stuff is the reason i hate programming. I don’t have a problem with logic errors, syntax errors, etc. but Christ’s dusty nuts I hate bureaucracy.

    I started with a completely new set up. Wrote a hello world program. It worked fine. Then I tried to use Date(): cannot resolve class. Tried GregorianC…cannot resolve class. Everything: cannot resolve class.

    10 minutes into playing with Eclipse and I am searching for obscure error.

  37. Ok so I am not sure if you are familiar with minecraft code but I am trying to create a new block and i keep getting an error saying BaseMod can not be resolved to type

  38. For me it was a combination of solutions. So

    1. Delete project or projects.
    2. Close Eclipse.
    3. Open Eclipse with -clean argument. Add “-clean” as the first line in eclipse.ini, more info here:

    4. Recreate each project (create a project with the same name).
    5. Clean the project or projects. From Project->Clean…
    6. Clear the “-clean” argument from eclipse.ini.

  39. I faced the same problem even though i followed above tips .Then i did validate the project once again it resolved.Thanks for the support.

  40. Look for a temp folder in your project root, which include a xml with buld instructions. Delete it and , refresh (F5) the project. Will resolve this.

  41. del all and do it again import swt, check build path, create class, add code, run again, should work , if not, right click , click clean up, click source…orgainise imports , run again ..if found err like cannot find .dll in library, coopy swt dll to your library path….run and
    this should work

  42. Thanks so much for the Project-Clean advice!!! If only I had read this yesterday, I wouldn’t have thrown all my changes away and re-check out the latest version from the svn…

  43. Well, none of the solutions works for me. My c++ code “compiles” in eclipse without and errors in the “console” window. But in the Problems window, really EVERY line is red because of an error… Maybe someone forgot to debug eclipse?

  44. God send article. Did the same, added a folder and eclipse went red. Refresh did not work but a project clean did the trick. Whew.

  45. 69 comments to Eclipse “cannot be resolved to a type” error:

    I think you should be careful about the global variable in the class:p

    public class HesapMakinasi extends Activity {
    EditText sayilar;
    EditText gecmis;
    Boolean isaret = true;
    Boolean islemUygun = false;
    Boolean esittirSonIslem = false;
    Queue kuyruk = new LinkedList();

    public void onCreate(Bundle savedInstanceState) {

    sayilar = (EditText)findViewById(;
    gecmis = (EditText)findViewById(;

    sayilar and gecmis are the defined global variable and fix my problem.

  46. If you are on the same problem, I invite you to make as following :

    – Right-click on project > “Team” > “Refresh/Cleanup”. In very rare cases, it can work.
    – “Project” > “Clean…” > “Clean all projects”.
    – Deleting your project and checkout it anew CAN work, but sometimes Eclipse is boring. Use it as last resort. Think to save your current work on diff patch, if any.


  47. I also had this issue with classes in the same package not being able to be resolved.
    I fixed by doing a refresh, followed by a clean and a fresh build.

  48. Here is what you do if you can compile and run but see a lot of red: just build another project that does compile WITHOUT red marks. Then switch to your project and viola – the red stuff disappears. Woof

  49. I am a complete newbee to android development. Using Eclipse I am working through the step-by-steps of developing apps. I got to Starting Another Activity and then got an error when I added @SuppressLint(“NewApi”) to class DisplayMessageActivity. So then I imported android.annotation.SuppressLint but the error would not go away after Ctrl-Shift-o. I tried to do an F5 as some folks suggested, but it did not get rid of error. So what I did was remove the line @SuppressLint(“NewApi”) and left the import android.annotation.SuppressLint and then did Ctrl-shift-o and added @SuppressLint(“NewApi”) back into code. No errors now. A bug in Eclipse?

  50. Thank you! In my case it wasn’t an extra folder, but an extra copy of my class created by WinMerge but this was enough to put me looking in the right place!

  51. Guys, same problem here. Especially after adding an interface. Looked over the first 6 answers, and then looked at the BuildPath, Configure Build Path…, and there, much to my surprise, was my interface listed as EXCLUDED. Once I corrected that issue, the complaint about cannot be resolved to a type went away. Good luck.

  52. simply add struts-1.2.2.jar file into your lib folder. It will help you.
    the actionform class is present in this .jar and we missed it that is the cause.

  53. I’m glad that solved it for you, Asif, but the majority here (and my original problem) was that all necessary jars are on the classpath, but Eclipse gets in a state where it still cannot resolve the type. In that case, adding jars doesn’t help.

  54. followed all the above trials.But still “Solo cannot resolved to type” error is showing in eclipse juno while running robotium basic test.please assit

  55. Just like that. Project > Clean. Couldn’t understand what was going on, couldn’t see anything wrong with the code. There wasn’t.

    Thank you.

  56. Thank you! i been two days looking for the same problem and i was running out of ideas, i saw your article pressed F5 and the problem was fixed.


  57. Three years later and your post still helps – in my case i simply added a new folder which i subsequently changed to a source folder. This apparently eclipsed (aka messed up) my build path thus my junit test was not finding the classes. Checking the ”Rebuild class files modified by others” somehow fixed it. Thanks!

  58. Hope this helps somebody…

    Refreshing the project did not help in my case. However, using Refactor > Rename (Alt+Shift+R) on the unresolvable class did work. After renaming it the class was able to be resolved in the multiple places it was being referenced, then I simply renamed it back.

  59. Thank you for writing this article! Saved me a lot of time. May good karma come your way sir 🙂

  60. Another scenario that can trigger this incorrect Eclipse behavior is malformed source code (e.g. source code having improper Java structure).

    I had a large MFC C++ project that I passed through a commercial code converter that was supposed to convert the project to Java. The code converter handled most of the conversion properly, but the resulting Java code was malformed for numerous scenarios the code converter mishandled.

    The resulting Java code had a complex package structure. Classes in some of the packages showed no errors. Classes in other packages showed:
    (1) “Syntax error on token ‘package’, assert expected”
    (2) ” cannot be resolved to a type.”
    (3) Imports cannot be resolved

    It appeared Eclipse build process (compilation) had a certain order. Classes compiling BEFORE the malformed code compiled correctly. Classes compiling AFTER the malformed code reported the errors above even though their source code was, in fact, 100% correct!

    In this situation, the solution was to locate and correct the malformed source code.

  61. Hi,

    Thanks for this, I didn’t even have to create a new directory, I added a new LOG.INFO to a file and the whole project went squiggly.

    1) delete the LOG.INFO
    2) save file
    3) press F5
    3) press CTRL-Z to undo the deletion from step 1 (put back the statement)

    it’s now OK,

    Maybe Eclipse just needs F5 to be pressed after every change to to keep it happy.

Leave a Reply

Your email address will not be published. Required fields are marked *