Tools I use: Eclipse

This is first of a series of posts where I talk about the tools and technologies I prefer to use. They are not intended to be in-depth technical documents, but posts answering the questions like Why & How with the history behind it. As always, all comments are welcome.

Eclipse is an IDE framework. A complex scaffolding which can host a lot of functionality at the same time. This means an Eclipse installation can be almost anything, and many things at once. You want a C++ IDE? Check. Python? Check. Java? Go? Web development? Check, check & check.

This makes Eclipse decidedly different from other tools at the same category, and puts it somewhere between an old school IDE and a modern code-aware text editor with plugins. As a result, when a newcomer sees Eclipse first time, there's a big, unfamiliar terrain to navigate.

Eclipse in Python perspective

Moreover, Eclipse is old. Around 20 years old, to be precise. As a result, it doesn't follow the new conventions, styling, UI densities, and whatnot from current era. It's written in Java. In other words, It's a prehistoric artifact when evaluated from a technology perspective.

Or is it?

Personally, I'm using Eclipse since 2006. Before that, I have used various software on and off, but while I was developing my graduation project, I needed a Java IDE, and found Eclipse. It was acceptably fast, worked on both Windows and Linux (I was dual-booting at that time), and most importantly, it was portable. I installed Eclipse to a 256MB flash drive alongside my workspace, and used that USB flash drive to work on my code while I was at the university (laptops were luxury back then).

Eclipse provided great Java tools at that time (it was on par with greatest IDEs of the time for Java), and allowed me to develop and debug my graduation and master's projects. I've published papers from these research projects, too. Being able to develop, debug and oversee the whole process from a single point hooked me to Eclipse.

Then, I found out that Eclipse can do more than Java (and Subversion).

Being interested in C++ lead me to install C/C++ Development Tools (CDT), and Linux profiling integration tools (Linux Tools). Then, Eclipse published its Git integration. Installing these three things converted Eclipse to a modern, Linux native C/C++ development environment with a single click. Eclipse has a notion called "Perspectives", which are "task oriented views" in its essence. With perspectives, Eclipse can transform on the fly, and doesn't get cluttered.

Eclipse in Git perspective

While Eclipse had its dark periods of being a heavy, slow and crash-prone application, especially in the C++ department, the project found its footing in the last 7-8 years, and fixed all its problems, and changed to a quarterly release schedule. While history of Eclipse warrants a single and much longer post, let's get into how I use Eclipse.

Eclipse puts "Integrated" into IDE firmly and squarely.

Eclipse uses "Projects" to store everything related to a project, including its source, settings, and everything in between. A project can override any global setting, and these settings are carried with the project itself. While not favored broadly, by submitting these files into your Git repository, you can carry all your pipeline with the source itself. This allows me to carry and share a project with all its intricate details and settings without detailed documentation and scripts. All are there when I import my project back to Eclipse.

On top of that, Eclipse supports a great deal of programmability out of the box. This means, almost every path and every setting can contain variables. Using these variables allows a project to behave the same way between systems, operating systems and directory trees, making it more portable.

Another feature I love is "Profiles". A project can have many build and debug profiles, which can contain different compiler flags, toolchains, folder includes and excludes, and environment variables. As a result, you can target different architectures, feature/optimization levels, or in extreme cases, a different source tree. This last feature makes compiling test suites with Catch 2 a breeze. While I didn't use extensively, you can even tune which ELF parser to use for debugging and understanding your errors, per profile.

Eclipse has an integrated Git client for a long time. Arguably, it's the best Git client I have ever used (Git Tower comes a close second). It's completely integrated to all views, provides great visual aid for history, encapsulates all common operations to easy to understand flows, and has a useful, integrated diffing tool. Moreover, it guides you during conflict resolution, provides advanced push/pull/merge/rebase controls and even discourages you from doing wrong things with your repo.

On the language specific features provided by the "Toolkits", C/C++ Development Tools' indexer is something worth mentioning. It's called an indexer, but for historic reasons. It supports auto-completion (incl. templates), code formatting (with different profiles nonetheless), documentation access, declaration/instantiation location, advanced refactoring, code analysis, and probably some other things I didn't need or explore yet.

Eclipse's CDT settings window

When combined with Linux Tools (e.g. Valgrind), you can run the tests and profiling from your Eclipse window and get your results directly into your window, with graphs and annotations on your source code directly. This is a true integration. Not "tool launch" support.

PyDev, which is the Python development environment for Eclipse, provides almost the same set of features, and some Python specific ones, as well.

The last part I want to touch in this category is synchronization, and export/import capabilities.

You can export all your configuration (installed items) and settings in Eclipse, with small XML files. This allows you or anyone to backup or share your Eclipse installation. You can import your configuration to any Eclipse installation to transform it to the Eclipse you got used to, and import your preferences on top of it to continue from where you left. If you want a more automatic way, you can login to your Eclipse account from any number of installations and keep them in sync via Oomph feature.

There are more Eclipse features I'm aware of, but don't use actively. Hence, I'll leave a concise list of them:

  • Language Server Protocol support.
  • Compile into / Run in Docker container.
  • Remote development support (via SSH or dedicated daemon).
  • Automatic Change Log generation.
  • True multi monitor / multi window support.
  • A broad official package ecosystem.
  • A board third party package ecosystem via official Marketplace.
  • ...and many more.

As a result, today's Eclipse is neither slow, nor heavy (it uses less RAM than a certain, popular editor of today), nor left behind. With its quarterly updates, diverse package and tool integration ecosystem, it's as capable and flexible as any tool used by today's developers.

On top of that, Eclipse provides a true, single point of command and control for all the software development pipeline, from foundation to testing to deployment/publishing. It's a true marvel and powerhouse.