Contrary to @nitind's opinion, no. You should not put any IDE-specific settings under version control. Except you are developing IDE features or plugins.
In case you really have mandatory team-wide IDE settings, putting them under version control would be a good idea, but IMO having mandatory team-wide settings is not a good idea in itself.
For all other cases, shared IDE settings are bad for portable builds, even with the same IDE, and useless at best for users of other IDEs.
EDIT: I should differentiate, depending on the target group of your project. If you are developing a closed source product in a team that works with eclipse, then keeping these preferences under version control is helpful and a good idea. If you are developing a library, closed or open source, or an open source project, I consider ignoring the preferences more appropriate and polite.
EDIT2: I'm afraid @Bananenweizen is misunderstanding what I am trying to say.
I know that these settings are the eclipse compiler settings. They are still IDE-specific in the sense that they won't have any effect in Netbeans or IntelliJ as they won't have any impact on ant or maven builds from the command line.
Yes, leaving these setting out of version control can bring you many red wavy lines in eclipse on a different machine. It won't, if it's a maven project with a set source level by the way, I'm not sure about ant.
Eclipse is not building the projects by itself - it builds them with ant if it's an eclispe or an ant project, or with maven if it's a maven project. Both ant and maven have specific settings for the source version that do not depend on IDEs.
And this is where these settings ought to be - in the build file. And the build file should be under source control. The exceptions I mentioned earlier still apply.