A lot of my team’s code is in Java, and although I have a love-hate relationship with Java spanning years, I do think it’s a decent systems language, albeit with its own warts, and Java 8 has smoothed over a lot of those warts.

This isn’t my first time to use Emacs for editing Java, and I’ve used several elisp packages in my journey of Java-editing-Zen. My current practice is to use Eclipse as a backend for editing Java via Eclim, and unfortunately Eclipse has its own problems as an IDE, or even as a backend server for Emacs.

For starters, you’re severely constrained by how Eclipse builds projects – and it’s worth noting that although you can tell Eclipse to use an Ant build file, that’s cutting against the grain at best and a whole lot of pain at worst. If you want to use a different build tool that isn’t supported out of the box or via a plugin? Tough luck. In my case, our build tooling is pretty much not that compatible with Eclipse, or at least not in a fairly low friction manner.

There’s also the issue that you have to have Eclipse or the eclimd daemon running beforehand. True, you could configure Emacs to start eclimd automatically, but in my experience any Java project of significant size tends to be pretty involved – and things get worse if you need to switch between Eclipse workspaces. There is no way have one buffer open, pointing to a Java source file in one workspace, while having another buffer open, pointing to a source file in a different workspace – all while having Eclim/Eclipse not get confused.

An older alternative is to use JDEE, whose maintenance was recently picked up. There’s a reason I had long moved on from JDEE, however – JDEE is still pretty slow (and kind of painful), since it tends to block things for significant portions of time (even with the new architecture featuring the separate JDEE server, for some reason). Plus, I dislike the color scheme it uses for syntax coloring.

Then there’s the language server protocol, which is promising: the idea is to separate the editor from the language-specific bits, and have a separate server that handles the parsing and source manipulation. That way, you could theoretically introduce support for a language across multiple editors in one go – no more waiting for your favorite editor to get a full-featured plugin for that language.

Or at least, that’s the idea.

In practice, LSP is pretty new, and in particular the more mature language server for Java is still Eclipse-based – Eclim already sort-of works for me if I’m going the Eclipse route, so I don’t see the point.

I have yet to try the other Java language server though, so that might be a win. Watch this space.

In the meantime, I’ve settled on using a fairly lightweight Java editing environment called meghanada. It’s fairly straightforward to set up, and I’ve written some shell scripts to better integrate it with our build tooling.

Particularly, I’ve configured meghanada so that it picks up dependencies from what our build tooling says are the dependencies via .meghanada.confthe documentation is sparse on the topic, but still pretty useful.

One of my pain points with meghanada though is its lack of refactoring tools, which is understandable – it is mostly for editing Java code with a lot of the basic affordances.

As long as I can edit my team’s code in peace inside Emacs, I’m good.

Previously: Identity