yeah, this happens sometimes for no apparent reason. You can go to the "Problems"-Tab (right next to console output) and see the error message, so maybe you can narrow it down that way.
I've run into a similar problem many a time, what happens usually for me is that a java file will say it won't compile in the text editor but in the package explorer it will say it's compiling fine.
Sometimes doing a 'rebuild' or 'clean-build' doesn't work, the files don't actually get built (one has to presume that eclipse thinks the files it has are up to date) and when this happens I usually open up the java build path and just move one of my dependencies down/up the pecking order. This forces eclipse to do a rebuild of everything and it always seems to work.
If you're still having problems try copying the project and seeing if you get the same behaviour and at a last ditch attempt post a bug for eclipse, it may take a while for them to fix but at least you know that you're being heard.
To add to the previous answer, an extreme way of "cleaning" your project is to delete it (that is deleting its reference from the workspace, not deleting the actual files), and then re-import it.
Sometimes, it helps...
I want to start by thanking everyone that answered. But cleaning and rebuilding was not enough in my case because the problem was still there and needed fixing.
Turned out that one of my package directories had accidentally been copied so that an extra directory now existed called "Copy of dagskra" containing Java files with wrong package declarations. In addition the errors in this "new" directory don't show up with a "red-x" in the package that it exists in:
It was the hint of reading the "Problems" tab :-) that turned me into the right direction, so I'm selecting that answer as the accepted answer because this is what I needed:
As others have said, bad file references in the build path is often the culprit.
Usually a .jar file that has been moved/deleted. Eclipse expects to find everything referenced on the build path at the location specified, and will complain if not.
I have run through this. My case was more involved. The project was packaged fine from maven command line.
Couple of things I made.
1. One class has many imports that confused eclipse. Cleaning them fixed part of the problem
2. One case was about a Setter, pressing F3 navigating to that Setter although eclipse complained it is not there. So I simply retyped it and it worked fine (even for all other Setters)
I am still struggling with
Implicit super constructor Item() is undefined for default constructor. Must define an explicit constructor"
So upon finding that there could be a missing package in the buildpath, thus the red x against the main project, to remove this:
1) go into "Configure Buildpath" of project
2) Java Build Path -> Source Tab - you should see the red x against the missing package/file. if it no longer exists, just "remove" it.
I also experience those misterious error-symbols on packages from time to time. A way to get rid of them that works for me is to effectively remove the JRE System Library from Java Build Path and add it back again.
My solution that finally worked was to clean all projects, close eclipse, clean all projects, close eclipse, and so on at least 5-6 times. Eventually it all settled down and everything was as expected. Weirdest thing ever!!
And no there were no errors in the Problem or console view.
Also this happened after a computer crash. The last time it happened my whole workspace was completely lost. It was still there on the computer, but when I tried to access it, it would be all blank.
For whatever reason computer crashes are really really really badly handled by eclipse.
This can occur for a number of reasons. If you have changed the jdk, the Project facet will have a red X next to it while no other folders shows an error. If this is the case, modify the jdk that is shown. This happens on occasion in our JAX-WS class (HSG
Subversion is occasionally the culprit for this as well. It might not have anything to do with your environment. But, there might be a discrepancy between the current and local state of the project. In my case, doing an update, and then a commit to the subversion server provided me with the expected clean result without any flags in the project such as the X.
In my case what solved this problem was simply to Close Eclipse and opening it again...However I am still not sure why this happened or why it worked. I was having problems Cleaning my project (it said it could not Delete certain file) and this solved it :):
This happens often when I use Maven, and I had always ignored it until I found this question. You need to update the project in this case (figured this out by looking in the Problems pane)
From the project context menu: Maven -> Update Project and select the available maven codebases
Alternatively you can use (Alt + F5) to bring up the same window
After build. Refresh project and if still persist just right click Problems tab in eclipse and choose delete all.
It often happens if you do maven install and eclipse properties files do not get updated properly. Even though your project does not have any errors. Hopefully!
I encountered this problem today and found this link. I followed as mentioned by Patrick Schaefer above and opened the Update Maven project Dialog. Click on my working project and selected the checkbox "Force Update of Snapshots/Releases" and 'Ok'. All the red cross vanished.
I hope this helps anybody in a similar situation.
The question is old but I had this issue and I tried the following to no avail.
mvn update (with snapshots)
remove project and re-importing
clean build
restarting Eclipse
changing order of items in build path
In my case I've got multi module mvn projects and one of the nested projects was showing a red X icon only in the Project Explorer (package explorer and problems were totally fine) and the whole project was fine as I could run classes without any issues. So seemed like a display issue.
The only thing that worked for me was to edit the pom.xml if the offending project module and make a breaking change (add 'xxx' to a tag name) which caused 1000s of errors and then undo.