Today I've dug out an Eclipse 3.2 article that's seven years old and is still valid. Considering how much Eclipse has changed since 2007 that's pretty astonishing. So, if you want to know how to format an entire Java Eclipse project in no time, you may ask Peter Friese. Of course you're invited to read on instead and learn some additional hints.
Let's have Eclipse do it
The general idea is to use Eclipse itself to do the formatting. There are also quite a few great source code formatting tools out there (just think of Jalopy), but I assume you're an Eclipse user who simply wants to use the Eclipse configuration you've investigated so much time in. So you need to install Eclipse first. Of course you already have Eclipse on your development machine, so you can skip this point unless you want to run the formatter on your continuous integration server (aka Cruise Control, Jenkins or Hudson, or you want to run it each time a file is checked in. In both cases it's unlikely Eclipse is already installed on your server.
A down-sized version of Eclipse
Actually, you don't have to install an entire Eclipse. All you need is the formatter class, plus the infrastructure it needs. Stefan Franke shows you which libraries you need, and he even prepared a package based on Eclipse 3.6 for you. Unfortunately, Eclipse 4.2 uses different file names, and they seem to have changed the format of the configuration file. Either you use his Eclipse 3.6 distribution, or investigate some time to update it to a current Eclipse version. If you do, please drop a note in the comment section below so other readers can benefit from your effort.
Find the configuration file
Back to Eclipse 4.2. I already mention the configuration file, and that's what we're looking for next. I suppose you've already configured your source code formatting rule in the preference dialog of Eclipse. You'll have to make it project specific to get hold of the configuration file. To do so activate project specific preferences as shown in the hardcopy:
Don't forget to activate them again in the consecutive dialog:
Now the configuration rules have been added to .settings/org.eclipse.jdt.core.prefs. Open the navigator view of eclipse and copy the file to a new location (or leave it where it is and just memorize the path name).
Configure Eclipse
To keep things simple I assume you're using the same eclipse.ini you're always using. If you're using a fresh eclipse installation, you may have to add the path of your JVM and the Java version, as described in Peter's post.
Run it!
We're almost done! All that remains is to write a small batch file and run it:
C: CD \eclipse_4.2 REM the folder of your Eclipse installation eclipse.exe -application org.eclipse.jdt.core.JavaCodeFormatter -configNote lines 3 to 5 are actually a single line. I just had to split it to accomodate this blog's layout.
The last parameter is the path of your Java files. By default it's processed recursively. There's a caveat to Windows users: you have to replace the backslashes to forward slashes (UNIX style path names).
Troubleshooting
It took me a while to get things running, so maybe I can give you a few hints:
- Every other description I found in the web tells you to add the
verboseparameter. However, the Eclipse source code formatter is a taciturn guy if ever there was one. No matter if you addverbose, it won't tell you what went wrong (or even if everything's all right). - To get started use your development copy of Eclipse to be sure the eclipse.ini is correct. If you use the -vm parameter in the command line, better move it to eclipse.ini. Alternatively, you can add the -vm parameter to your batch file.
- As mentioned above, Windows users have to replace path separators (backslashes) by UNIX style path separators (forward slashes).
Format source code when committing to the repository
After a while everybody who's working collaborately in a team wants to enforce a uniform source code formatting. The easiest way to achieve this is to add a formatting step to the commit process of your SVN or GIT.
However, that's shaky ground. Don't do it. For one, I'm told Subversion will cease to work. It's possible to add a pre-commit hook formatting the code on the server, but that means your local copy of subversion believes the code is unformatted, whereas the server copy of the same revision of the code is formatted indeed. This leads - they tell me - to all sorts of uncanny behavior.
Other source code repository such as GIT cope better with the situation, but maybe it's still a bad idea. I'm not sure what happens when you update the code. Chances are your tool simply relies on the revision number, so you won't get the current version of the shared code.
There's still another reason why not to do it: formatters modify your code. In rare cases it may even break. If you're in a hurry you will simply remove the pre-commit hook and leave it at that.
Format source code during continous integration
It's a better idea to integrate source code formatting as a build step in Jenkins (or Hudson, or CruiseControl, or ...). You write a batch file that checks out the source files, formats them and commits the folder to the source code repository.
If the build fails because of formatting, your development team can simply deactivate the build step. Most teams are more familiar with the configuration of Jenkins than with Subversion, so chances are the build step is reactivated when the urgent problem has been solved.
Ask your team first!
Developers become very emotional when it comes to source code formatting. Commit a bug fix in a fellow developers class, and chances are he'll become angry. Not because of the bug fix (although these things also happen), but because of the formatting. So the most important thing before enforcing a company-wide formatting is to convince everybody first. That's one of the thing you can't decide by a simple management order. If one of your developers fell in love with a particular code style, he'll simply ignore his boss's orders, or accept them grudgingly.
Peter Friese's article on the topic