> I’ll preface this by saying that if Neovim isn’t your primary editor, you should first try an IDE specifically for Java."
Seconded.
As someone who has spent a lot of time configuring editors, but doesn't enjoy it quite as much as he used to, I gave Java on Neovim a shot this summer.
There are two main routes to go - both of which are described in the article. Either install it yourself, "You read the friendly manual", or use someone else's installer, "You use a distro".
My problem with someone else's installer is that I don't understand what it's doing, which in turn gives me the feeling that it's pulling in the kitchen sink, which is exactly the feeling I hoped to avoid by not using my regular IDE.
My problem with installing it myself is that I have to learn the entire ecosystem including, but not limited to, learning how to use Neovim for more than editing a simple text file, learning the Lua scripting language, learning where Neovim keeps its' configuration files and what to put in them, curating a set of plugins for highlighting, launching code, debugging, etc., figuring out how to configure those plugins for Neovim and finally how to make those plugins play nice together.
In the end it just wasn't for me but if Neovim is your primary editor it might be for you.
> Java has one LSP option for Neovim, and that’s JDTLS (Java Development Tools Language Server) by Eclipse.
I’ve tried out a few distros for vim and emacs over the years and usually drop them after a few hours of trying. But I gotta say I’m really enjoying LazyVim. It’s config layering system makes tweaking any specific plugin settings very easy, and it’s based on the “lazy.nvim” plugin manager that most plugins feature first in their README intros these days. That means there’s less a feeling of doing things “the normal way” vs “the weird distro specific way” that I experienced with DOOM EMacs and SpaceVim.
It’s definitely still a kitchen sink, lots of stuff that I wouldn’t configure on my own, but surprisingly discoverable via a popup that shows available keyboard shortcuts that appears after you type LEADER and wait a moment.
It’s also super fast to start up, putting most destros out there especially EMacs ones to shame.
The main downside is it encourages you to spread out your config in multiple Lua files, and overall learn and use more Lua stuff. But I think it’s worth the price.
Last time I tried and iirc, lazyvim would print out all sorts of various errors within seconds of using it for very basic things, which is enough for me to give up on most tools unless they are forced onto me. That said I have yet to find a proper code editor for my needs which is not exactly dev ; so far I settle with plain vim.
Doesn't the idea of an "LSP for Neovim" mean the entire premise of LSP has failed? Wasn't the whole idea supposedly to put an end to editor-specific plugins in favor of one protocol spoken by all editors?
LSP exposes standard interfaces, but it still has to be bridged across the variety of languages editor plugins are written in. It’s much better than the previous state.
It is just that. (of course in practice you also need to get the LSP to exist on your system somewhere in the first place and have a command that runs it (rather annoying for java programs), but other than that it's literally just a program with JSON I/O)
I was in the same place you were a month ago but I decided to just bite the bullet and build my own Neovim configuration from scratch. Fortunately I don't use auto-complete and an LSP was only a recent addition to my configuration. Telescope was one of the few plug-ins I configured off the bat and when you start small learning the eco-system isn't that much of a hurdle.
The Nvim Kickstart Project is a great starting point for your configuration and has it's config file heavily commented to teach you how to setup your own configuration, I highly recommend it.
Interesting. I always hear "you don't need a full blown IDE, vscode/neovim/other text editor should be enough". Then I read those articles about which plugins/bundles/addons I need to install and I wonder at which point do we call it IDE instead of text editor (with plugins).
It heavily depends on the language, the frameworks and the actual project.
Languages that have great and standard tooling will work great. Frameworks that rely on basic language features work great. Projects that rely on standard tooling and features work great. Things just work.
Languages that have 3 decades of legacy warts, languages with no or poorly implemented LSPs, languages where the ecosystem relies heavily on runtime language features, frameworks that rely on behind the scenes magic and conventions, projects where for ten years the whole team only ever used one IDE… yeah, it’s not where vim/helix/vsc shines, and you will fight an uphill battle.
The Tiobe index might not be the best, but these are certainly popular languages and they don’t have decades, plural, of language warts.
Languages like Rust, Dart, Go, Kotlin, and Swift emerged when standard tooling was already expected, such as LSP, standard formatting and linting.
I don’t have experience with all of these languages, but I know that Rust and Darr have great tooling maintained by the same people who maintain the language and I can just pick any code editor with LSP support and I can expect the experience to be great.
e.g. Android studio has a great preview feature for composable which makes it a joy to build them. It gives you an option to run just see the live effects of updating code for that composable in (a) IDE (b) Emulator (c) Device.
> Languages that have great and standard tooling will work great. Frameworks that rely on basic language features work great. Projects that rely on standard tooling and features work great. Things just work.
The only language that comes to mind fitting this description is Go ?
Rust also has great tooling. Clippy, Rust analyzer (the LSP). Developing Rust in NeoVim is just as fun as Go.
Other languages that do ok are OCaml, Elixir/Gleam, Typescript. Go and Rust just have what I consider a "cut above" the others when it comes to both tooling and standar language features.
There's a spectrum. notepad.exe, vi, emacs/vim/notepad++, vscode, idea. Every new layer adds more features and adds more bloat. You can upgrade to the next layer by installing enough extensions (if editor allows it and those extensions exist). You can certainly turn your bare vim into vscode comparable editor with enough extensions. And you can certainly install enough extensions into vscode to make it comparable with idea.
An important thing is to find a personal sweet spot. For me, using Idea with hundred plugins is just not worth it. Spring plugin comes with thousands of features, but when I disable it, miss very few things, and the bloat is real: slow start, lots of new menu items and icons, new bugs.
I, personally, prefer to use editor on steroids like vscode, with full language-aware support. At the same time I'm using external terminal a lot, doing builds and stuff there. So IDE for me is an entire computer and vscode is part of this IDE.
Also the quality of vscode is strictly worse. I tried it a few years ago and syntax highlighting a basic python program using stock vscode would get stuck (highlighting the wrong characters in random colors) in nondeterministic ways. I tried it again recently and I still see syntax highlighting bugs. Vim does a better job.
There are people out there who don't even use an LSP with autocompletion or type handling, just syntax highlights. There's a theory that actively thinking about this will prevent u from making mistakes like forgetting a semicolon.
I do agree that some nvim setups are just IDE's in your shell, but it's also nice to have everything in one place. I don't like vsc's and Jetbrains's terminals at all, as it gets clunky too quick. To each their own though!
Syntax highlights were probably the first thing I disabled in vim, though they kept adding features—"that's nice, but how does one turn it off?"—so I'm on vi now. Hella distracting to have bloatware spam you like a pachinko parlor, but some folks will want that whole three ring circus cruise ship with the bearded lady tour, I guess. Color support got itself compiled out of the terminal, to avoid the results of git randomly squeezing the backside of a unicorn. Unix here is the IDE, which is fine, as I'm mostly not a programmer (why programmers keep launching flaming turds into production despite all the increasingly fancy tools is a somewhat entertaining question) and 35,000 lines of code is about the largest thing I deal with (vi, or a custom branch thereof). Plus some tools that I wrote that do exactly what I want them to. Multiple cores pegged because some AI nonesense is busy shoving crayons up its nose? No, thank you!
I don't know if you are trolling or not, but if not, you are an interesting person (In a good way) :-)
I too prefer a much more minimal approach to my text editor. Then what most IDEs provide, but syntax highlighting is luxurious and a must-have for me. In general, I really love colors, especially the simple colors of the terminal. Color can be distracting of course, but it is a phenomenal way to quickly differentiate between related and unrelated parts of the code.
You probably do this already, but setting NO_COLOR=1 to disable colors and syntax highlighting is supported by an increasingly wide range of applications.
> why programmers keep launching flaming turds into production despite all the increasingly fancy tools is a somewhat entertaining question
haha I love the tone and I feel you, the state of software (and computing in general) keeps surprising me (in a bad way) as years go by. It feels like it's only getting worse. We can talk about their salaries too !
The best programmer I know very often codes in a simple notepad like text editor with no syntax highlighting or any kind of other help. Purely plain text.
He does this mainly when trying to show/explain something to someone in code and when initially drafting something. Not for full blown projects.
I still find it interesting though, because I personally don't nearly have good enough memory to even do that. I have to look things up constantly and rely on auto completion.
I have normal memory but my interpretation of the worst programmer I've worked with is that he had extraordinary memory and used that to write extremely tangled code but due to remembering every call site and randomly named function he thought the code base was flawless. And the expectation was that efter he explained a piece of code once then I too should have committed that to memory and then be able to recall it days later when it unexpectedly mattered when explaining a new piece of code. Failing to do that would lead to a "sigh, I'll explain it from scratch again". I don't really remember but I think he used intellij, but like a tabbed text editor. Always ctrl-shift-f "startoffunctionname".
I used to think like this too, but I now categorize this as "making easy things easier" and I try to focus only on things that "make hard things easier". Now the main thing I value is flexibility, and that's mainly achieved by mainly spending my time in a programmable environment (the shell), and a CLI editor like Vim fits the most smoothly into this approach.
To give an example, let's say you want to make pull requests for an API change across several interdependent repos (e.g., an API change in a framework). So you want to you want to do a find and replace in each repo, then push the changes to a branch, and create a pull request for each one. This can be achieved entirely from the command line, making it really easy to repeat across all the repos that need to be updated.
(With all the above said, I do use most LSP features, like live error checking and autocomplete, but if I were forced to choose, I would give that up before I give up the flexibility of a programmable environment.)
I’m curious to see how you’ll automate this in e.g. IntelliJ, that doesn’t allow you to open multiple projects side by side. No, opening multiple instances of IntelliJ is not the answer.
You think you waste brain cycles on semicolons? Do touch typists make a conscious effort to "remember" where all the keys are? When you read, do you go letter by letter to make sense of words and sentences?
Your brain is an incredibly efficient tool. You should trust it more.
Brain cycles are still being used even if you're not conscious of them. So yes, some part of your has to spend cycles to remember to type that semicolon, and to even remember where the semicolon is on the keyboard, and in fact to remember how strong a signal has to be sent to the finger muscles to move the pinky to the right location and press the key.
In principle, this effort should even be measurable in calories (though it may be hard to distinguish from the noise of everything else you're thinking).
Perhaps I should have originally been clearer, but I have no clue what these "brain cycles" that keep being mentioned are. If it's some kind of CPU analogy, brains and CPUs are nowhere near analogous in how they work. The brain is an extremely complex system, whose mechanisms we're far from understanding fully and whose activities are mostly unconscious and subconscious processes.
In the context of our discussion, energy expenditure is not really the relevant feature. The more useful "index" would be the "perceived (i.e. conscious) cognitive workload". One is addressed with caloric intake, the other has more explicit psychological ramifications.
It may have been presumptuous of me, but cognitive workload is what I thought GP really meant by "brain cycle" and that's what I was addressing.
The point I was trying to convey is that the brain is very good at moving chunks of work away from conscious processes to subconscious ones (i.e. away from perceived load) through various optimizations. Usually, exposing the brain to deliberate and repetitive tasks will tend to develop certain tacit skills (subconscious shortcuts).
Another subtler point, was that an easy mistake when evaluating how much cognitive work a tacit skill actually demands, is to appreciate it from the perspective of someone who lacks said skill.
You don't need a full-blown IDE to write HTML. Maybe for Python. But for languages like Java, you're leaving a lot of productivity and error prevention on the table.
I agree I think a lot of people do tend to go overboard with the plugins they add to Neovim. I only use a hand-full of plugins myself; Telescope for fuzzy finding, LSP for navigation and Rainbow-delimiters. I've found attempting to add anything "un-neovim-like" such as tabs or a debugger to be more of a hassle and jankier than just using something better suited to that task.
I actually think the best way to learn Neovim is to build your own configuration with as little plugins as necessary for you to get the job done because it'll force you to learn the Neovim way of doing things. For example instead of relying on tabs I learnt to use the Mark system and it was a great addition to my workflow.
The I stands for Integrated. Although technically I think the big 3 Java IDEs are written as a pile of plugins largely to support multiple languages. But they do tend to feel more "integrated"/look more cohesive. I guess the point is that if you feel like opening a text file in something it's a text editor. If you don't it might be an idea. I do try to open up individual text files outside of a project in pycharm sometimes but usually it feels weird. Maybe that's why they added scratch files. Somehow shift+shift new scratch file json and copy/pasting feels easier then making a new file outside your project with the IDE
I use Vim (recently switched to Neovim on my work laptop) as my daily driver with a minimum set of plugins. My primary language right now is Go, but used to be C++. It works just fine for my purpose. I have tried using IDEs in the past, most recently vscode when I was trying to learn Rust, I always end up going back to Vim, I find it more a more enjoyable and streamlined experience. For IDEs it's usually a struggle getting everything to work for me, and if there is a new version it just ends up breaking everything. I'm sure it's just a matter of what I'm used to.
However I learned JAVA at university and it's the one language I have never managed to come to terms with using vim. At university I used Netbeans and I think that remains my one positive experience with IDEs. I really liked how that worked (or maybe I just hadn't been conditioned that much at that point). Java seems to be designed around the idea that you should user an IDE though. Sooo Verbose, and so many frameworks...
> I wonder at which point do we call it IDE instead of text editor
The most hilarious to me is when people refer to Emacs as a "text editor". I'm not talking about the fact that Emacs shall happily display pictures (inlined in a file like in org-mode for example or in their own window), open binary files, open PDF files, manipulate files over SSH (Tramp), etc.
Heck, as a statement some made Emacs run as PID 1.
But many seem to honestly think Emacs is "notepad with bad shortcuts".
The full statement is "You don't need a full-blown IDE, just use (vim or whatever), unless you are writing in Java". Among mainstream languages, Java is uniquely hostile to being written by humans.
The statement is usually shortened under the assumption that nobody is writing Java by choice, and if you're writing it for work you're forced to use (Employer-provided development tool).
There are other languages that are hard to use without an IDE, but they always are relatively obscure ones and/or blatantly integrate the language itself tightly into the IDE, like Smalltalk or Scratch.
Most languages, it's feasible to write with nothing more than a regex-based keyword detector and symbol tagger. LSPs are overrated, other than the fact that they're a narrow waist for supporting multiple languages in multiple editors.
`System.out.println` is ridiculous, and you're likely to use it many times unlike `public static void main`. Well, since there are only 2 of these I suppose you can simplify this to it's not hard to customize your editor to expand `sout` or something to that.
Java culture promotes long class names and method names, which are often neither unambiguous by prefix nor by initials, which are the 2 basic autocomplete styles (though really, I shouldn't allow the pro-Java argument to consider autocomplete at all, even a stupidly basic one).
Java culture (and to some extent the language itself, due to package-private) expects separation of classes within a project into multiple/nested packages, but package names are expected to be very long and there are no relative imports. And classes from third-party packages will also have horribly long names. New-file templates can help a little if you're willing to suppress "unused import" warnings.
The lack of support for "free functions" (outside a class) adds a ton of verbosity, if you can't fake them via dummy interfaces. Meanwhile, the fact that `this` is implicit makes the question of "what identifiers are in scope" almost as complicated as C++.
But yes, if you're paying attention, Java-the-language can be made somewhat nicer if you ignore Java-the-style (notably, many developers of Java itself are famous for doing this internally). But then you basically give up on the library ecosystem, which is the only reason to write Java in the first place. You can't even add interfaces retroactively!
Yes, I know they say "speed of programming isn't limited by how fast you can type", and it's usually true. But Java proves it can be bad enough to drop your cache.
> `System.out.println` is ridiculous, and you're likely to use it many times
No, you don't use it often.
You can use it as a poor man's debugging tool, but Java actually has very nice debuggers. You can use it as poor man's logging, but then you have pretty good logging frameworks. Or you can use it as application output, but then you probably want to abstract specific output stream away from most of your business logic code and use interface.
So in that highly configurable and scriptable environment you can't create a macro like sout that expands to System.out.println, really?
Also, if it can't even import symbols automatically, then it sounds like a tool problem. Java is like one of the simplest languages, it has no fancy features, has sane imports, ultra-stable tooling, etc.
The point of an IDE is to improve productivity. And I think you just haven't seen someone who knows the ins and outs of an IDE fly while writing Java there.
My point is that "highly configurable and scriptable environment" is a much higher floor than other languages have. You don't need that to be productive in most languages; there are people who write serious code in nano or even notepad!
And what objective metric is there that prevents it from working in java? Because there are, in fact, people that write java in notepad, probably much more than those who write rust and go and swift there, combined.
It's faster. There are all kinds of vim modes and shortcuts in IDEs, but only in terminal you can turn off your mouse completely and just use the keyboard. It's also faster than any GUI program in terms of responsiveness, everything happens in an instant, and there is not a single animation, even when working with a 1GiB log-file. Vim is also a very robust tiling manager, convenient splits and navigation between windows, terminals and editing buffers out of the box.
I find that terminal apps are a lot more respectful of my machine's resources and whatever workflow I want to build. I can make them work like I want to. GUI apps make me work the way they want to, which as an incorrigible non-conformist is a real fly in the ointment.
A programming language is a good abstraction for interacting with the computer. It's a metaphor for how a computer works. Graphical tools usually provide metaphors for how a certain set of tasks are done. The terminal is a REPL for a programming language designed for this purpose.
Simple command line tools become primitives in this language, and they compose together. Learn a few dozen and you have something quite powerful. You can remain in the same mental model to accomplish many tasks. Graphical tools tend to be monoliths that rarely compose, each premised off of a different mental model. This creates friction when moving from one to another.
For better and for worse, the terminal looks pretty much the same now as it did 30 years ago. (There are important improvements in zsh and fish.) Graphical tools tend to evolve quickly. If I don't use a command for 5 years, I can get back up to speed in a few minutes using it's built-in documentation (`--help`). If I don't use a graphical tool for 5 years, I'm pretty close to square one, and need to spend some time with the manual (in a separate application, the browser or PDF reader).
If something is missing from your toolkit, throwing together a proof of concept level CLI is pretty easy. Presumably some people can throw GUIs together very quickly as well. But the CLI is a simpler programming model. (Immediate mode GUIs do narrow this gap, however.)
And now your new CLI can integrate with all your other CLIs out of the box. Eg, a tool that tweaks some values in a JSON file can be used with the `find` command to tweak many JSON files.
(Your mileage may vary. I'm just trying to present a distilled intuition, if I seem to be speaking in absolutes, it's figurative. Whatever workflow works for you is the right one.)
I guess I should have been more specific: I get all that about CLIs, but that doesn't really explain wanting your editor to run in the terminal. I usually have an IDE open alongside a bunch of terminal windows. What am I losing by not also running my editor in a terminal?
You're probably not losing out on anything if that's comfortable for you. The primary advantage to me is avoiding context switching between a GUI and terminal mental model. But that probably just doesn't bother you.
I also need to configure which "plugins" I want whenever I install regular Visual Studio. In fact you can't really even start using it before that initial setup window. The time it takes to install and configure a plugin on vscode, for example, is basically 0 for most languages and platforms.
Today I generally think of an IDE supporting one language (or a few complementary languages) without any configuration, whereas a text editor usually requires configuration to get the same features. Although it's true the features are almost identical now. Though IDEs typically still offer some special sauce features, usually things that still don't fit cleanly into LSP and DAP (language server and debugger protocols respectively) models. On the flip side, text editors typically (lightly) support more file formats out of the box, and scale better, e.g., equally comfortable editing a single file or an entire project. TLDR: the trade off is between flexibility (text editor) or specificity (IDE).
Looks very nice. One thing that always prevents me from using anything other than a full-blown IDE for Java is the fact that most entreprise projects use Maven and structure packages with the default Java way by using the FQDN structure (e.g.: org/example/groupid/packageid/submodule/File.java).
Maybe I'm missing something but navigating and finding/adding files in a structure that's 10-20 directories deep or more seems like a nightmare in pure Vim.
A good fuzzy finder helps a lot with this. You can type something like `ccufFoo` to match `com.company.util.factories.FooWidgetFactory`. I use fzf.vim for this.
Thankfully my company has its own hosted LSP that supports Java (and every other language in our bazel monorepo) so I don’t have to mess around with Eclipse and JDTLS (what happened to eclim?). But at a prior company I just worked without an LSP and just did a lot of referencing Java docs in a browser and split screen files.
I was also curious. The project has been shut down/archived this August recommending java LSP instead but it seems like there hasn't been a lot of work or a release since 2021
> Eclim has reached its end of life. The Language Server Protocol (LSP) and the various implementations are mature enough that eclim has become unnecessary.
> It has been a great run (nearly 20yrs!) and I'm grateful for everyone that helped out, from bug reports to patches, it's been awesome
It has support for fzf and zoxide for these uses. As well as a panoply of other goodies (ripgrep, file previews, commands without exiting the file explorer, etc.)
If one is willing to learn helix instead of nvim, I know there's integrations out there between the two as well. I wouldn't be surprised if there were for nvim as well.
I started down that route and decided it was just a lot of work ie mental effort I didn’t want to do. My motivation was eclipse maven plug-in was buggy and sucked at the time. I found (like most) IntelliJ gave a much more pleasant experience. How long have you been doing it and how have you managed to stick with it?
I wrote Java sans LSP for three years full time (2012-2015), and then occasionally since then.
Since 2015, I mostly worked on the web version of our cross platform C++ project but have contributed substantially to the Android and iOS libraries as well.
I always found the existing bazel integrations annoying. My solution has been to generate .classpath based on a set of bazel queries. Not what's officially recommended, but it has worked great for the projects I've been involved in. Easy to understand, and keeps bazel completely separate and independent from the IDE experience which has some benefits.
FWIW, that is not a Maven-ism that is actually inherent to Java (the language and the runtime)[1]. Including case-sensitivity for the filename, which was an especially bold choice for Sun to make back in 1990, although I guess they're all "we'll sell more Solaris workstations!!1" or something
For example:
$ mkdir foo
$ cd foo
$ printf 'package jimbo;\npublic class Foo2 {}\n' > fred.java
$ javac -g -d . fred.java
fred.java:2: error: class Foo2 is public, should be declared in a file named Foo2.java
public class Foo2 {}
^
1 error
The only exception that I'm aware of is that inner classes don't have to live in their own filename (given that they're more or less property of the owning class)
The Maven-ism that I'm aware of is the by default structure of {src/main/java, src/main/resources, src/test/java, src/test/resources} but (of course) those are customizable via the pom.xml if it jams up your project that much
Package hierarchies are used during class loading from a directory, but there is nothing in the spec that mandates that kind of directory structure for the source code. Your link only uses the word "might", not "must".
Not at all -- if you're something like LazyVim with the stock config, then in a large project it's just <leader>ff to search by filename or <leader>sg to grep across the project (using ripgrep!) or for a symbol search <leader>sS (using symbols provided by the LSP).
I haven't found anything better than Neovim+Lazyvim and switched from ST4 a couple of years ago and never looked back.
<leader><leader> also opens the fuzzy finder in LazyVim. I don’t like it quite as much as <shift><shift> which is the shortcut in Jetbrains but it’s better than <Cmd>-P in VS Code
Yes that works too! I use <leader>fb to fuzzy search over open buffers so <leader>ff is a bit more natural, albeit longer than <leader><leader>.
I think my favorite feature is `gr` (in command mode) to "goto references" for the symbol under the cursor. I use this all the time (as well as `gd` for goto definition which with the LSP is really precise).
In IntelliJ, you don't normally need to look for files unless they're non-source code, as you can just go directly to types regardless of their file names.
Wouldn't that mostly matter if you're really navigating in your source code via the tree panel? In the post-Textmate days, fuzzy file finders seem to be all the rage whether you're using vim or IDEs (or Sublime etc.). Or you go to definition/references immediately.
I mostly use the file navigation when exploring the structure, which I'm not doing that often.
And which I probably should do with a class browser anyways, which I used to do often in Eclipse, way back in time, but it seems that particular SmallTalk-ism isn't very popular in contemporary IDEs.
Doing any work in a project worked on by multiple teams without C-P-style fuzzy file name matching is a recipe for frustration in any editor or IDE, regardless of the language. I've relied on this feature a lot when working in nvim+Python and nowadays in my vscode+typescript job it is one of my most heavily used shortcuts, too.
Honestly having one single dedicated F key for jumping anywhere to a class or method definition is, for me, a killer feature that most alternatives lack. I do a lot of kinds of development with Vim, but for certain languages I find it a far better experience to use a language specific IDE.
One thing that non-Java devs don't get is just how much better the tooling is for Java than literally any other language.
Most jetbrains IDEs I find are indeed comparable to vscode plug-ins and a huge glob of vim plug-ins for most languages, especially the dynamically typed ones where the amount of static analysis you can do is already quite limited.
But for IntelliJ, literally no other editor comes close. Extract method/variable, all the "hey you wrote java 6 but it's 2024 that those 6 lines you wrote are 1 lambda now, do you want to replace", and so many other things.
Did you know that if you paste a maven xml dependency coordinate into a .gradle file, it auto-translates it to gradle format before the paste?
This is absolutely true, but having spent a lot of time The Java ecosystem and then much time outside of it, I now think this is a bit of a curse. It has made the average Java developer actually structure their code and build practices around the IDE, rather than the other way around. If it wasn't for modern CI practices which force a headless build, I wouldn't be surprised if most Java projects wouldn't even build without the IDE to do the building for them. In several places I worked, Even That wasn't really usable outside of the CI environment because it was just taped together as an afterthought and bare minimum since all the developers just used IntelliJ to build locally anyway.
Even little things like variable naming, explicit types, and the like were commonly neglected because in the IDE you could just hover your mouse over the variable to see its type. Because that exists and is so commonly used, developers didn't even think about The impact it might have on someone not using the same IDE. This is just one of several practices that I continually ran into when trying to use vim. There are also plenty of readability issues, such as enormously long methods that the IDE collapses for most developers so they never see it and don't have to think about it, but once you aren't using that IDE anymore, you really see all the nastiness and warts.
So long story short, I agree with you about the tooling, but I think it is actually more of a curse than most people realize.
Most of that could also be considered getting the best out of the tools at hand. Is it necessarily a good idea to always optimize for the highest common denominator? Even for a contributor that at the time of the decision is merely a hypothetical? That same attitude could be brought into a project by someone who refuses to use a build system and insists on everything being laid out for easy compilation by manually launching javac, or on writing makefiles instead of a pom.
I mean sure, there are projects out there where a healthy dose of tool-agnosticism should not be too much to ask for, but a generalized "they are doing it wrong" about people playing to the strengths of their toolkit is really not warranted. The opposite of structuring around what works well with their tooling is structuring around what works well with your tooling. You ask for exactly the thing you are refusing them. Yeah, IDE-only builds are a bad idea, but that's really a concept that has died a long time ago (even if there are probably a few cases around where it still has not stopped moving yet)
You're not wrong, but IME, if people are doing stuff like that, it's not something an IDE or lack thereof would solve anyway. Sometimes you just have to either train/mentor or (if unresponsive) fire people who write such primitively bad code.
I have an engineer on my team that loves RubyMine. I can't even argue with her choice... JetBrains does indeed make very solid products. I'm just not a fan though. Even still, I never want the code I write, or the tools I choose to be IDE/editor specific. Right now we're trying to figure out how to get Biome (JavaScript linter/formatter) to play nicely with RubyMine... it's not as simple as NeoVim/VSCode.
Jetbrains Goland doesn't make your code IDE specific at all. They don't do any magic, go build and everything else all works as expected from the command line. go fmt, go imports, revive, etc., can all be configured in the editor to run on save. My only complaint is that there are so many options, it takes a while to grok everything.
So instead of picking tooling that works with the dev tooling your developers like, you pick tooling that's dime a dozen (js formatter) that doesn't work with the best tools your devs like? Got it. How are you still a manager?
I'm confused at what your comment was designed to achieve. It seems like an attempt to troll. But here it is:
Formatting tooling was chosen before several members joined my team. It was chosen due to having far fewer dependencies than ESLint+Typescript+Prettier etc. One package... one setup.
Secondly, what exactly do you think managing is? Someone has to make the ultimate decision and be responsible for it. Perhaps you think a manager is someone who's constantly wandering around taking a vote from everyone on how they want to steer the ship? While I do strive to find concensus among my team that's not leading. Agree to disagree there.
In my experience VS Code (with TypeScript) even the main refactoring options don't work very well. For example when I rename a method, move a file between directories, or move methods, the imports are not correctly updated and I have to spend time fixing errors before compiling.
With IntelliJ + Java I can do more advanced refactors (change method signature for example) and it compiles without any manual effort.
Ah don't get me wrong, I absolutely agree. For advanced refactoring and bigger project, IntelliJ is very much ahead. I just think that vscode is itself far ahead of emacs/vim in that regard. It's in a middle ground between IDE and an editor once you get a language plugin installed.
Not specifically about Neovim, but I'm curious about the Java situation in general. To a first approximation IntelliJ is what everyone uses. I'm a VSCode user for everything but it seems basically the wrong decision to try to not use IntelliJ for Java. And mixed Kotlin/Java projects are impossible currently in VSCode with the RedHat extension.
So my question is, what are projects like Cursor going to do? Surely the solution isn't to assume that JetBrains will do enough innovation in AI IDE features in the next year or two to prevent is wanting to try out all the other AI IDE innovation?
JetBrains IDEs are highly extensible, and they have support for AI completions. Nevertheless, I think that the assistance and navigation features in IDEs are much more useful than auto-generating half-broken code.
I've spent a few weeks trying the built-in AI in IntelliJ, and the Copilot plugin as well.
I have to say that even though sometimes both AIs offer amazing suggestions, it's really distracting to me to have constant multi-line completions being suggested non-stop! And sometimes it's a suggestion that would probably make sense in a widely different context, but you can see how the AI would believe it was appropriate for you anyway and you start wondering about nonsense. I had to disable that.
The line-completion that IntelliJ has by default now was quite a bit better IMO. It really helped and was not so distracting.
Anyway, I can't tell which AI was best, they both seemed similar in capabilities. The JB AI is a bit more well integrated, obviously, so it's a bit easier for me to accept completions for example (with Copilot, sometimes it competes with the normal IDE completions and I can't easily pick one). Anyone has an opinion on that?
> The line-completion that IntelliJ has by default now was quite a bit better IMO. It really helped and was not so distracting.
I very much agree. The line-completion is a very well done AI integration.
I think there's a lot of potential to integrate AI into IDEs, but it will likely be less of a low-hanging fruit in comparison with simple code completion.
Ah, I see. It sounds like you haven't tried something like Cursor, on tasks/languages that it performs well on. It'll be interesting for you when you discover what it's like. You don't accept large quantities of implementation ab initio; but they're very good nowadays at modifying and extending with non-broken code.
Right now, I’d say the “AI IDEs” like Cursor or Zed are ready to replace less Java-centric environments. I’d put VSCode in this “not really Java centric” bucket. I see VSCode as a “fancy text editor” for Java, i.e., better than an editor like Neovim, but, not by much. So, an AI IDE is more likely going to gain traction on people who have been using VSCode or Neovim than anyone using Eclipse or IntelliJ.
Recently, my company has tried to introduce a “cloud IDE” (the development environment runs in the cloud somewhere). Initially, it only supported VSCode. The only engineers that bothered using it were junior; once people had about 5+ years of experience, they just found it tedious. Once the company included IntelliJ for that cloud IDE, usage spiked massively. (To the point they are restricting usage due to cost.)
These “classic Java IDEs” just launch with features useful for understanding large systems, like, fast navigation and debugging capabilities. Things like “where is method used” or “what implements this interface method” is fast and accurate - i.e., not based on text search. Or the interactive debugger that lets you inspect stream state, track objects, etc.
JetBrains probably won’t be focusing on using AI simply for writing code, but for enhancing all of these other capabilities. This is where I’m not sold on Cursor or Zed replacing these truly language-specific IDEs… yet.
These new upstarts need to improve the ability to navigate and understand. Right now, they only seem to focus on writing, which I don’t think is what’s going to gain traction. I also don’t see any of them doing much other than just fancy autocomplete, which can be awful on a large legacy codebase. So… we’ll see.
This could be generational, I’ve definitely seen poorer DevEx win simply because they gained the attention of younger engineers and lasted long enough.
I mean, yeah if you are using Kotlin you are almost inherently locked in to IntelliJ... by design. But for java proper, it's far from the only viable IDE.
> Surely the solution isn't to assume that JetBrains will do enough innovation in AI IDE features in the next year or two to prevent is wanting to try out all the other AI IDE innovation?
They kind of have been doing just that, their jetbrains AI assistant has an integration comparable to cursor's, just the model itself isn't as good which is a shame
I write most of my code in Emacs, even C# because I find VS* to be a major pain in the ass. But I've always used IDEs to write Java, first Eclipse and lately IntelliJ. They are simply nicer to work in than anything else I've tried, except Smalltalk and Lisp machines. I have a feeling it came as part of the cultural heritage from Smalltalk.
There are more and more successful experiments with nvim and java recently. Considering the amount of black magic happens in idea, and seeing how it fails sometimes, it’s probably tome for me to try migrating again.
The hardest part for me in using nvim for java is the debugger tooling. I primarily use IntelliJ for any JVM related languages, and the debugger has always been invaluable. The debugging has always felt more polished and easy to configure in JetBrains IDEs. The nvim-dap and nvim-dap-ui had a bit too much friction to configure for it to my liking, and inevitably I reverted to IntelliJ. However, I love the keyboard-driven flow I can achieve in nvim where JetBrains IDEs fall short.
What kills me with JetBrains is they work on a barely functional (according to vim coders I talk to) simulation plugin, instead of just investing resources into integrating Neovim as a backend via plugin. You can literally have all the niceness of JetBrains IDEs with the editing power of Neovim. That alone would flip so many die hard Vim users.
I had a few people who wanted the better IDE, but they hated the keybinding hell they were going through. Having a true integration would have flipped them fully.
The problem there is that you'd be integrating two massive codebases, each with different expectations, assumptions etc. No matter how hard you try, they'd clash in places and some things would not work, leaving one side or another unhappy even with this massive effort. IdeaVim makes it work by having a massively simplified vim-like editor, specifically written for IntelliJ.
I switched to IntelliJ and use their vim bindings package, maybe 6 years ago now, exactly because of Java and other “IDE dependent” languages. I got really tired of switching between editors and IDEs and wanted “one to rule them all.” IntelliJ isn’t perfect but it’s pretty damn close to be honest. I admittedly use only a sliver of the features available in it but it also “just works.” And if when I switch languages, and use one heavily dependent on the IDE, I’m pretty much able to be productive immediately. Additionally, I have access to their language specific IDEs and can be off and running with them in a minute or two tops after some copy/pasta of settings (though I wish I didn’t have to do this step).
P.S. If you want to give IntelliJ a try, after installing the vim bindings package, also make sure to install the “string manipulation” package, and set some keybindings, as it’s 100% necessary for quick editing.
I unironically use nano for this (albeit with lots of custom macros).
It just works.
(though obviously jshell kicks in quite a bit during coding sessions, and on top of that I have several templates and custom shell scripts that help navigate docs easily)
1. Note all the things you like about your current IDE vis-a-vis your development workflow. 5 major Lists will emerge : While Code, While Compiling, While Running, Debugging & Test.
2. Set up a current project you are working on in the IDE in neovim.
3. Take some minutes in the day how much cognitive load it takes to switch and use each one of the things in #1. Then ask yourself the 1million $$$$ Question:
- Does adding a bit of complexity give you an advantage? -
This will probably teach you more about your own current IDE and improvements you could do there than neovim
I pay out of my own pocket for Intellij, in case I want to build something that could make money and because contemporary Java is pretty ergonomic and suitable for some prototyping.
But I also maintain a vim config for Java development, because in small projects and some small fixes it has a nicer integration with the shell and cli tools there. If you aren't going to do JavaFX, hairy debugging or non-trivial release management it's good enough.
I tried to give it a shot this year. Autocomplete (and especially Co-pilot) works really well nowadays. What made me reconsider is actually how imports are sorted and organised - they differ from how IntelliJ does it, which all other developers in my team uses. It’s a tiny but nagging issue for which I haven’t found a solution. It doesn’t help that IntelliJ is spectacularly good out of the box hah…
I believe that's _conceptually_ possible but unless you, personally, have actually tried it I wouldn't go so far as to cite that. My hand's on experience was that the thing very easily gets into analysis loops and never terminates. And by "never" I mean that I dialed up the CI timeout to 24 hours just to see if I wasn't patient enough and it still didn't terminate
And that's not even getting into the horror show of trying to view the analysis results of any "hello world" setup wherein it does terminate: a reasonable CI integration would submit those findings as comments on the PR but I had to duct tape one together by transforming the SERIF output into ReviewDog to get that outcome
I am quite possibly the biggest JetBrains fanboy you'll encounter, and was thrilled out of my mind when they announced Qodana, but its execution has been a raging dumpster fire
I am puzzled that you had such a negative experience. I set this up in the summer and it worked just fine, including comments on PRs. I used https://github.com/JetBrains/qodana-action
I feel the exact same way. I've had various iterations of this ftplugin for a couple of years now but... everyone else has figured out how to just install an LSP and move on. Why is Java such a special snowflake here?
I’m a big neovim fan, and I I ever need to do Java, first I’ll enable the Java lang extra in lazyvim . If that doesn’t work I’d look at this and make changes. Then I’d probably go to IntelliJ Idea.
I love the allusion to HTML Goodies in the title. I haven't seen that style for maybe two decades, it even took me a minute to remember the name of the site.
Do you mean the “so you want to ____” format? If so, I don’t think it’s an allusion to HTML Goodies — it’s a decently popular meme that goes back at least the early 80’s (e.g. “So You Want To Be A Wizard”).
Seconded.
As someone who has spent a lot of time configuring editors, but doesn't enjoy it quite as much as he used to, I gave Java on Neovim a shot this summer.
There are two main routes to go - both of which are described in the article. Either install it yourself, "You read the friendly manual", or use someone else's installer, "You use a distro".
My problem with someone else's installer is that I don't understand what it's doing, which in turn gives me the feeling that it's pulling in the kitchen sink, which is exactly the feeling I hoped to avoid by not using my regular IDE.
My problem with installing it myself is that I have to learn the entire ecosystem including, but not limited to, learning how to use Neovim for more than editing a simple text file, learning the Lua scripting language, learning where Neovim keeps its' configuration files and what to put in them, curating a set of plugins for highlighting, launching code, debugging, etc., figuring out how to configure those plugins for Neovim and finally how to make those plugins play nice together.
In the end it just wasn't for me but if Neovim is your primary editor it might be for you.
> Java has one LSP option for Neovim, and that’s JDTLS (Java Development Tools Language Server) by Eclipse.
Just wanted to mention that there is another LSP for Java, https://github.com/apache/netbeans/tree/master/java/java.lsp..., but I don't know if anyone has gotten it to work with Neovim.
reply