Eclipse is a beast. A device whose mystery is only exceeded by its power. Some would call it a continuum transfunctioner. Others would call it a transmogrifier. Yes, it is so huge, it takes years to master. And then, your manager shows up and tells you: We’re using NetBeans now.
Just kidding. No one uses NetBeans, except for Adam Bien. So let’s have a look at 5 very useful, but hidden Eclipse features.
1: My favourite feature: Favourites
Everyone uses libraries with static methods. Since Java 5, we can static import them, so we no longer have to write things like:
But who is going to static-import all those methods manually in every class referencing them? No one. Because you can define your favourite types and members in the preferences:
And then, just start typing and look for auto-completion:
The auto-completion will also generate the necessary static import. Very useful when using DSLs with many functions, for instance. Obviously, you will want to make a careful decision, which ones are really your favourite libraries and within those libraries, which are your favourite types. As you’re on the jOOQ blog (or a syndication thereof), let me give you a hint. Always favourite
2: The awesome block selection mode
I’ve recently blogged about it here. This is so awesome, it merits being mentioned one more time.
Notice the highlighted button, the sixth from the left. That’s the awesome “Block Selection Mode” (Alt-Shift-A on Windows, or Ctrl+3 and then typing block selection). It lets you write opening quotes on each selected line at the same position. This is so useful when you have to edit large amounts of almost identical lines.
3: The EGit staging view
Aparently, not every EGit user is aware of this view. As a matter of fact, to me, this view is the most important reason why I’m NOT using the shell commands. Check out this beauty:
OK, not really a beauty. Reminds me of this comic strip by Eric Burke. But we’re in transmogrifier land and the staging view is filled with changes waiting to be added / committed / pushed once you synchronize a repository with its origin. I can now decide on a line-per-line basis, which changes I want to be added to the index (note I haven’t added the main method). This leads to there being staged (added) changes and unstaged (not yet added) changes. As always in EGit, I can now either directly commit, commit+push, amend+commit, amend+commit+push in one go. Try doing that on the command line.
Now after this first commit, I can now again stage/add the main method in a separate commit. I guess, behind the scenes, this might be implemented using stashing or some other sort of local cache. I don’t care, this is beautiful!
I can probably do much more with this beauty, but that would fill an entire book (I’m waiting for such a book, @niborst, if you’re reading this)
If you didn’t understand any of the above Git talk, try this popular guide, or join me with…
4: Type filters
Yes, because Eclipse’s out-of-the-box autocompletion is nonsense. Yes, it is! No one really wants to call
notifyAll() on an API. Ever. Actually, nowadays, hardly anyone even wants to call
notify() even on a lock object, except if they’re writing the JDK’s concurrency libraries. But luckily someone else is doing that for free, and they’re certainly using vi or emacs or a hex editor, so they don’t mind
So then, why is my autocompletion popup filled with this nonsense? Let’s create a class…
Wow. I thought I had only one method? I don’t mind
equals(), although the few times I actually type
equals() I can type it out. So let’s remove that stuff:
Thanks Eclipse for mentioning awt, too. I wish there was an option to remove awt from the JDK and from our collective memory, entirely. But at least, adding awt to the type filters stops you from having to choose between importing
java.util.List (99.9%) and
java.awt.List (8.3%). The rounding error is due to the amount of times you had previously chosen the wrong list, accidentally, and wondered why you couldn’t assign an
ArrayList. Thanks again, awt. Do also note how my chameleon Windows 8 has changed window colours while taking screenshots. Tiles, what’s next? Anyway back to Eclipse, let’s try auto-completing again…
5: Formatter tags
After having spent all that time with block selection, carefully formatting our SQL… bam comes the intern and/or styleguide-nazi and auto-formats all your beautiful source files to a huge one-liner. But not for much longer. Protect your code with easy to type formatter tags:
Remember to use something concise to protect your carefully crafted SQL, as you might have to type these tags once or twice:
No one touches that code again. Except the intern who forgot to and/or styleguide-nazi who refuses to apply your formatting settings. And the other intern, who uses NetBeans. Just kidding. No one uses NetBeans.
Again, these tags work wonderfully with DSLs, which are hard to auto-format.
More to come
Eclipes is an awesome beast. Every year, new versions are stacked with new features that we Java developers get for free! You can give back to Eclipse. While I think that the foundation (backed by IBM) might not heavily rely on donations, your best option is to report bugs and feature requests, here: https://bugs.eclipse.org/bugs … or if you’re brave, to sign the CLA and start contributing.
There is always room for improvement to this awesome developer device, adding more material and candidates for my next top 5 list.
Improve software development by passing along shared knowledge and best practices.
One of the biggest challenges in application development today is how to factor in application-specific information. The answer lies in the ability to capture application evolution and developers' knowledge of building and extending the application as metadata so that it's not lost in time or translation. Once that can be done effectively, the combination of the application code along with application-specific metadata can be meaningfully packaged into reusable software asset modules. This white paper will discuss how 'Application Factories' can transform an IDE to play a central role in capturing both the application evolution and the developers' knowledge.