As described in our previous post, we maintain a common Eclipse Oomph Profile with our favorite plugins and settings preconfigured. By using Oomph, you can get this version of Eclipse installed with a single click. See here for a more thorough introduction and how to get the pre-configured Eclipse Oomph Profile.
As promised, we describe the things we adapted compared to the standard Eclipse Packages. I would like to start with a few default settings that have been adapted. Those settings are automatically pre-configured when using our Oomph profile, so you do not have to adapt them for every new Eclipse instance you create. Of course, it is always possible to adapt these defaults or add some more default settings of your choice. 2 years ago, Holger presented a great list of preferred default settings. We would like to describe the most notable ones which made it into our Oomph profile.
Native hooks or polling
One of the things most Eclipse users complain about is the fact, that contents presented in an Eclipse workspace can get out of sync with the file system. This happens, if you change a file somehow outside of Eclipse and then switch back to the file within Eclipse without pressing F5. Still, many people do not know, there is a simple solution for this problems. Eclipse provides two settings.
The first will automatically update workspace contents, if the file is changed externally. The second will additionally update on open, in case there are any changes. With those two settings it is unnecessary to press F5 therefore fixing one of the most annoying problems in Eclipse. Of course, both settings are default in the EclipseSource Oomph profile.
Another preference, that probably every Eclipse developer has changed several hundred times is the encoding. In times of heterogeneous developers operating system, we typically want to use UTF-8, therefore, this is the default in our profile.
There has been endless discussion about this in the past. We skip these and just turn on line numbers in all editors by default 🙂
Ignore AWT packages
Features such as content assist, organize imports, and quick fix are great to save typing effort. However, some of the suggestions made are not what you want. This can be due to the fact, that frameworks have overlapping naming schemes. If you need to use those frameworks, there is no good default solutions for this except to use some more advanced frameworks such as code recommender. However, there are also some things, that you almost never use and therefore it is beneficial to remove those packages completely from the namespace used for resolving content assist, imports, etc..
Java AWT is (in our context) a very good example for this. It has very annoying overlaps, e.g. it has a class “Composite” , which overlaps with the SWT Composite or a class “List”, which overlaps with Java. As we have no single project using AWT, we decided to remove AWT completely so it no longer appears in content assist or organize import.
For this purpose, Eclipse provides so-called type filters (Preferences => Java => Appearance => Type Filters). Adding entries to this list will hide all matching Java Classes from related features such as content assist, organize import and quick fixes. As you can see in the following screenshot, you can even use wildcards to exclude a whole tree of java packages. Excluding AWT completely is default in our Oomph profile.
Another famous entry to be excluded is “java.lang.Object”.However, this is not currently default in our profile. This would have the advantage that methods such as notify(), notifyAll() or wait() do not appear on all Java object anymore, but also things such as toString() would be missing. Of course you can add any type filters you prefer to your preferences and thereby customize our profile to your specific needs.
More Memory for Eclipse
The last setting we would like to mention is actually not a preference, but a start-up parameter for Eclipse. If you start Eclipse without any adaptations, it is limited to 512MB of memory. This might have worked 10 years ago, but complex projects demand more. Modern developer hardware usually provides 4 and more GB of RAM, therefore, our default setting is 2 GB per Eclipse instance.
No settings for warnings, formatter, etc?
You might wonder, why there are no settings such as formatter, compiler warnings, save actions, etc. in this list. We strongly encourage to make those settings in a project-specific way. Therefore, they are distributed with the source code rather than with our Oomph profile. Instead of modifying those settings in the general preference dialog of Eclipse, you right click on a projects, select “properties” and enable the settings to be project-specific.
All settings, which either influence the compiler (e.g. warning settings) or the written code (e.g. the formatter) should not be made for the Eclipse instance but rather for every Java project (or bundle) in the workspace. This is for three reasons. First, project-specific settings are under version control. Things such as the formatter have a direct influence on the code and should be in sync with the current code basis in case they are adapted. You might even want to maintain different settings, e.g. for new vs. old parts or test vs. non-test code. Second, if you check out a project, project-specific settings are directly applied. You do not rely on developers to have a correct setting in their Eclipse installation. Third, and most important, for modularity reasons, those settings belong to a project, rather than to an Eclipse instance. Imagine a scenario, where you work on two Java projects, which you have checked out from two different open source projects. Those two projects might use different formatters. Setting a formatter for your Eclipse instance would not work in this scenario. The same is true for warnings, if you do not use them project-specific in this scenario, you might see different results from co-developers. Therefore, every Java project should be distributed including its settings.
Of course, it makes sense to apply the same settings for several Java projects which belong together. For example, open source projects typically provide a common project settings for all new Java projects or bundles developed in their context. A very simple way of transferring project-specific settings from one existing Java project to a new one is to copy the content of the “.settings” folder located in the root folder of every Eclipse project. Alternatively, the Oomph project provides some tooling for synchronizing project-specific settings and even identify unintended differences in those.
We hope, our default settings are a good fit for you. Please note, that you can adapt these settings at any point in time. If you change a preference, a window will ask you, whether you want to record that. If you do, it will be included in your future installation, but only yours. If you think a certain setting might be interesting for the majority of users, please get in touch with us, so we can consider adding it to the original profile.
You can report issues and feedback using this github project.
In our next blog posts, we will describe some of the additional plugins, we added to our Oomph profile. For an overview, all posts are linked here. I will also post all updates on the profile in this blog, so please follow us to be notified about those.
Until then, have fun using the EclipseSource Oomph Profile!