We ☠ Eclipse

Over the years, I’ve used a variety of editions of Eclipse with a variety of plugins. These days I try and minimize all of that and ask Eclipse to do as little as possible as infrequently as plausible. The below is a diary of sorts of the events that led to that choice.

A selection of ways Eclipse has failed me:

• It lies about custom key bindings being set, doesn’t actually set them despite indicating it has, and stores the bindings in the robust and never problematic Java-properties+XML standard format resulting in configuration files that look like this:
  

  
eclipse.preferences.version=1
org.eclipse.ui.commands=<?xml version\="1.0" encoding\="UTF-8"?>\n<org.eclipse.ui.commands>\n<activeKeyConfiguration keyConfigurationId\="org.eclipse.ui.emacsAcceleratorConfiguration"/>\n<keyBinding commandId\="org.eclipse.jdt.ui.edit.text.java.search.references.in.project" contextId\="org.eclipse.ui.contexts.window" keyConfigurationId\="org.eclipse.ui.emacsAcceleratorConfiguration" keySequence\="COMMAND+SHIFT+V"/>\n<keyBinding commandId\="org.eclipse.ui.window.previousPerspective" contextId\="org.eclipse.ui.contexts.window" keyConfigurationId\="org.eclipse.ui.emacsAcceleratorConfiguration" keySequence\="ALT+COMMAND+CTRL+ARROW_LEFT"/>\n</org.eclipse.ui.commands>
overridepresentation=true

  Normally I could care less what format software stores its config files in, but despite the braindead format I’ve still had better luck editing this file by hand than trying to get Eclipse to handle it correctly. If your config file format is too error-prone for your software to handle, maybe it’s time for a change.

• Eclipse loses settings upon crashing, and crashes a lot. Feature-rich IDEs are complicated, and I can accept that lesser ones will sometimes crash, but you’d think that there might be some measures taken to mitigate the damage done. Eclipse opts for the road less traveled and doesn’t write out changed settings to disk until exit. This means that in addition to the joy of recovering whatever actual work you were doing when Eclipse decided to have a little lie-down, you’re also greeted on restart with the happy discovery that the obnoxious setting you fixed hours ago has become unset, despite pressing “Apply” and “Ok” repeatedly.
• Sometimes Eclipse just stops paying attention to any keyboard commands. Plain text still works, but shortcuts to anything, not so much.
• Key bindings can be exported to CSV, but can’t be imported from that format! Ha! They can ostensibly be imported and exported alongside other settings, but given the less than stellar track record I’ve had with that, I can only assume that the CSV format is provided for human consumption when you have to go through and manually re-enter all your custom key bindings.
• On occasion, Eclipse will stop highlighting other occurrences of the object under the cursor until ‘Highlight occurrences‘ is toggled on and off.
• After opening a file from search results, scrolling jumps about like a mongoose that just hit the third rail until the cursor’s moved. Because of course the last thing you’d want to do after opening the file with an occurrence of something you searched for is move around to get a bit more context.
• The Android XML editor has the less than charming feature of randomly moving the cursor to another part of the file sometimes when editing. There is nothing better than software that is fundamentally a text editor that can’t handle keeping the point of text entry in one place.
• For reasons unclear, the run/debug buttons will occasionally be disabled for no apparent reason. This is unrelated to the annoyance so omnipresent that it goes almost without mention; trying to run/debug an Android XML file silently does nothing. Those buttons are only effective in Java files. I can’t count the number of times I’ve accidentally forgotten that and sat waiting for the app I’m working on to appear on the phone only to discover that Eclipse wasn’t actually sending it over.
• Perhaps the highpoint of Eclipse’s insanity has been a particular installation that began reorganizing the buttons on the menu bar upon restart. Nothing helps a workflow so much as buttons not being where you left them.
• Using Content Assist in the presence of certain syntax errors frequently results in random gibberish being inserted.
• Text in error messages is sometimes selectable, but not copyable. Because who would ever want to copy the text of an error message? Apparently the highlighting is enabled just to provide a means to highlight important points for anyone physically present that you might want to show the error to while it’s on your screen.
• On other occasions, Eclipse opts for the other extreme and despite only certain text being selected copying drags in all sorts of miscellaneous other text that was plainly not selected.
• I hate Eclipse so much. (This is not strictly a way in which Eclipse has failed me, but it does appear as an entry in the notes that I’m consulting to compile this post, so I felt it should be included.)
• Importing an existing project when the project’s files are already in the Eclipse workspace doesn’t work unless “Copy into workspace” is selected. No files are copied.
• Unlike the rest of the modern world, the target area for checkboxes in Eclipse is limited to the checkbox, rather than the label alongside it. Minor compared to some of these other grievances, but I wouldn’t want to be accused of not being thorough.
• Under the right circumstances, linking a project will apparently succeed, but unresolved dependencies remain. Upon reentering the project linking preferences, Eclipse will admit that the linking actually failed. It will then cheerfully fail in the same manner as many times as desired.
• At some point, a large import failed and Eclipse gave me a dialog box with a message to that effect. It could not be dismissed, necessitating killing the Eclipse process externally.
• There are frequent NullPointerException crashes in Eclipse itself including as a result such esoteric actions as closing a project that another happens to depend on. Opening a project when a dependent project is closed results in the expected build errors, going the other way kills Eclipse.

In summary, I have occasionally found Eclipse to be somewhat lacking.

With the recent announcement of Android Studio I’m hopeful that well-supported Android development will no longer be so tied to Eclipse. Who knows, maybe this will even be the wake-up call that Eclipse needs to do the hard work of getting their app past functional and all the way to reliable.