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.conf – the 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