Develop Reference

How to use mailed .class files in eclipse

So a friend of mine told me I could mail my java projects to myself (the .class files) and then just put them into my workspace (yes I know about github, but having trouble with it, looking into it), though when I paste them into my workspace in the correct package, the code does not change.
Even making an entire new package (which would be required since I mailed 2 projects, from which only one was on my primary computer) did not help, as the package remains empty.
Yes I've tried the import option, didn't work (yes I'm fairly new to eclipse)
Any help is appreciated

The .class files are binary executables that are compiled from the .java files. If you want to transfer an entire Eclipse project from one computer to another, you could zip the project from the top-level in your Eclipse workspace, email it, unzip it on the target computer, and then import it as an existing project into Eclipse. You can unzip it anywhere, but you might prefer to put the project into the Eclipse workspace on the target computer as a good convention.
Note: I would recommend cleaning the project before zipping it so that you don't transfer the .class files that are going to be rebuilt anyway. That will make the zip archive smaller.

You can mail Java projects to yourself, but you want to send the source (.java) files to yourself. The .class files contain compiled byte-code and are generated from the source. Zip up the entire project folder and email it to yourself or place it on a thumb drive.

How can I stop eclipse to modify .classpath automatically

I check out a java project from svn repository include .classpath and .project files. And I import these codes into eclipse. But the eclipse will modify the content of .classpath file. How can I stop eclipse to do this? just write off build automatically option?

You can't. But instead of putting a JAR on the Java build path you could
choose an execution environment which should stay stable when you change
the JRE and hence the .classpath file will not change either.

.Project and .classpath files should not be checked in under svn repos.Blindly copying such files from one machine to another may be risky. These are the files that eclipse automatically constructs for you as per your project structure. If you want to edit, you can do that.
Here is the nice explanation What's in an Eclipse .classpath/.project file?

Adding information to a 2-year old question just in case of any one else is stumbling across this.
Due to insufficient detail in the original question, I am guessing that the problem experienced is due to the project's classpath pointing to a different location on the questioner's machine as on the original project author's machine. When a project uses 3rd party libraries (JARs) and is shared between different team members (as hinted at by the use of a version control tool), this is a common occurrence.
A solution to this would be to have all team members set up the location of the directory containing all 3rd party JARs to have an identical structure on all individual machines. So instead of changing the classpath, change the directory structure to that required by the classpath.
Unfortunately this is not always the best solution:
Team members may have different operating systems (Windows vs Linux) and you will not be able to have a (absolute) class path that works on all platforms (e.g. C:\libraries\3rdparty.jar vs /opt/libs/3rdparty.jar)
Team members may differ in how they prefer to organize their directory structure. Especially, if a team member places libraries into his home directory (e.g. C:\User\abcd\libraries\3rdparty.jar or /usr/abcd/libs/3rdparty.jar), another team member will struggle to replicate that directory structure.
Eclipse provides various methods to set up a project so that it can easily be shared between team members. These however require team members to all agree on the convention, and will be slightly easier if set up by the original project author right from the start. Two methods most commonly used:
Add all third-party libraries to the project itself (the usual convention is to have a /lib directory inside the project for this - on the same level as /src and /bin etc.). The classpath can now be set up to be relative to the project's root and thus usable across different setups. A variation for large multi-project-file projects would be to have a separate eclipse project containing the libraries, then add it to other projects as a dependency ("Required projects on the build path" in the "Java Build Path" dialog).
This has the benefit of being able to version control your JARs too. However, it may use up a lot of extra storage/bandwith, so may not always be desirable. For instance, I would not do this with Java Enterprise Edition JARs contained in my preferred Application Server distribution, as I may want to migrate my project in future to a new version or another product, without such dependencies - I also do not want to have my project saddled with duplicate JARs that are in any case already available in the AS distribution. So you need to think through your requirements.
Eclipse also provides the concept of a classpath variable. This may be set up to point to the root of a team member's JAR-containing directory, and be extended with subdirectories and filenames inside the classpath. This needs to be done only once, and is also accessed via the "Java Build Path" dialog.
Whenever a new team member uses the project for the first time, he needs to configure eclipse (once) to point that variable to the relevant path on his own machine.
The above mechanisms are explained in more detail on various web pages, here is one reference: http://www.informit.com/articles/article.aspx?p=367962

How do I get eclipse to compile and copy only .java files during build?

I have a dynamic web project in eclipse (although I'm not using it as a web project. I would like to convert it to a java project if possible) and there are java files all over the place. There are also a lot of other files like images etc (which I don't want to remove because the project is linked to my SVN repo so if i do an update then everything will come back).
Now when i build my project eclipse copies all the files instead of compiling and copying the .java files only and this takes a lot of time because there are some 2GB worth of files.
I tried to include only .java files in the source by going to properties of my project -> Java Build Path -> source tab -> includes -> I added "*.java" to the textbox. However, no file got copied to my output folder after that.
how do i go about this? Deleting the images etc from my project is not a solution here.

Add **/*.java/ in the includes.

Linking source to .jars in Eclipse

This framework distribution includes a lib folder (where all the binary .jars are) and a src one (where you can find the corresponding .javas for each .jar). So far I only have added lib to the Java project build path.
How would you copy src now? Just adding it or is there a way of somehow link it to lib? I don't have in mind what the gain would exactly consist of but I reckon that that would be somewhat better.
Edit - src is provided as a folder hierarchy, not source .jars.

If you're not modifying the source, performance will be better if the source for each jar is in its own source jar. It's usually also more convenient. This is a convention at this point - especially if you can get the jars from a maven repository. Each jar should be organized as you'd expect, with top level directory(s) "org", "com", etc. In the build path, you can attach a source jar to each binary jar.

I'm not 100% sure this is what you're looking for, but if you have added jars to your build path, you can right click on individual jars in the Project Explorer and select Properties. In the resulting pop-up is a Java Source Attachment tab, which has options for linking source files depending on where they're located.
The main advantage to this that I'm aware of is when you're debugging code that makes use of the jars. If you have source attached, you can step through the code, including comments (which are not available if you use a de-compiling tool to step through classes for which you don't have source).

What files should be added to SVN in an eclipse Java project?

I have a Java project I'd like to commit to my SVN repository, created with eclipse.
Now, what files (aside from the source code, obviously) are necessary? In the workspace root, there is a .settings folder with many files and subfolders, and inside the project folder there are two files - .classpath and .project, and another .settings folder with a single file - org.eclipse.jdt.core.prefs.
Which of these files should be committed to SVN and which can be safely excluded?

They're all useful if you want to have consistent settings across your team.
.classpath and .project mean everyone can get up and running with a project just by importing it. Any changes to the libraries and source files included in the project will be picked up by everyone when they're checked in.
The .settings directory has things like code formatting options and what the compiler considers as warnings, errors, or OK. For consistency, I've started checking these in as well (as long as everyone on your team can agree to a standard for formatting, I guess).
I've found that the biggest limitation in sharing things across version control in Eclipse is in the library definitions. Library definitions seem to be only stored on a per-user basis, so if you reference a "library" in the .classpath file, every other user has to manually define the contents of that library (or manually import your exported library definitions file).
Edit: (Addressing #mliebelt's comment below)
You'd only commit .settings files if you're trying to keep consistency/standardisation between developers. If that isn't an issue for the project, then not committing .settings files is one less thing to worry about maintaining. Files that are specific to an individual's favourite plugin(s) probably don't need to be committed either (although I don't think it would hurt if they were, would probably be ignored?).
The two most common ones I've found worth committing are org.eclipse.jdt.core.prefs and org.eclipse.jdt.ui.prefs, which are core to any (Java) Eclipse project.

You can exclude the .settings folder, but the .project file will be useful to other developers who want to reconstruct the same exact Eclipse project. If you examine the file it should only have relative references (if it doesn't, you should modify it as such.)

In contrast to the other answers I've made better experiences with not checking in the .project file in large open source projects that I work with.
You may disagree with me, but there is one problem with shared .project files: They contain references to the project natures used in the project. The project natures again depend on the plugins installed on the local developers machine.
Example: If you use Findbugs on a Java project, a new nature gets added to your Java project. Checking that file in, modifying it on another system (with no Findbugs installed) and afterwards using it on my system again has led to the Findbugs reference being lost for me (and therefore all Findbugs checks being removed silently).
But if you can have all of your developers agree on using the same tools, then you may be able to work around this problem easily.