4 ms·

> YMMV. I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle

> YMMV. I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs. If you tried and rejected lsp-java I'd be interested in your experience. I've been eyeing it as a way to get rid of my last non-emacs editing.

barrkel 7y ago
I've tried it. It mostly works and completion is alright, though a bit clunky visually and interactively. I haven't tried to tune the UI much - it would need a bunch of tuning to be good enough for me - but I haven't because it's brittle in the face of switching branches out from underneath it. It gets its project structure confused, and the workspace dir needs blowing away. Dismissing the "server crashed" notification every time I opened up a Java file to make a tweak on an git commit (using magit) made me disable it for a while. I still have hope. It's definitely improved from where things used to be, with eclim (Eclipse Vim plugin thing).
bennofs 7y ago
Tried lsp-java with a gradle-based project, and couldn't get it to properly figure out the project model (so imports wouldn't be found and nothing worked). Tried with both Emacs and VS Code, no luck.
fiddlerwoaroof 7y ago
I’ve been using lsp-java recently instead of IntelliJ (I’ve not used IntelliJ for so long now that my license expired). Ive found that you turning off lsp-sideline-mode makes the UI significantly better but, otherwise, I’ve had a fairly good experience using it in a large maven project.
Arcsech 7y ago
I tried the LSP-based Java extension for VSCode on a large project (~2M lines, large Gradle build) and it was unusably slow. More than 30s for a "Go To Definition" command with my CPU pegged the whole time. Caveats: It's possible the VSCode implementation was bad, but I think it was the LSP, and this was a few months ago, so things might be better now, but it would need to have orders of magnitude of improvement in performance to be tolerable. IntelliJ handles this project pretty much without breaking a sweat.

barrkel 7y ago

I've tried it. It mostly works and completion is alright, though a bit clunky visually and interactively. I haven't tried to tune the UI much - it would need a bunch of tuning to be good enough for me - but I haven't because it's brittle in the face of switching branches out from underneath it. It gets its project structure confused, and the workspace dir needs blowing away. Dismissing the "server crashed" notification every time I opened up a Java file to make a tweak on an git commit (using magit) made me disable it for a while. I still have hope. It's definitely improved from where things used to be, with eclim (Eclipse Vim plugin thing).

bennofs 7y ago

Tried lsp-java with a gradle-based project, and couldn't get it to properly figure out the project model (so imports wouldn't be found and nothing worked). Tried with both Emacs and VS Code, no luck.

fiddlerwoaroof 7y ago

I’ve been using lsp-java recently instead of IntelliJ (I’ve not used IntelliJ for so long now that my license expired). Ive found that you turning off lsp-sideline-mode makes the UI significantly better but, otherwise, I’ve had a fairly good experience using it in a large maven project.

Arcsech 7y ago

I tried the LSP-based Java extension for VSCode on a large project (~2M lines, large Gradle build) and it was unusably slow. More than 30s for a "Go To Definition" command with my CPU pegged the whole time. Caveats: It's possible the VSCode implementation was bad, but I think it was the LSP, and this was a few months ago, so things might be better now, but it would need to have orders of magnitude of improvement in performance to be tolerable. IntelliJ handles this project pretty much without breaking a sweat.