[HN Gopher] So you want to write Java in Neovim
       ___________________________________________________________________
        
       So you want to write Java in Neovim
        
       Author : ralphsebastian
       Score  : 120 points
       Date   : 2024-12-28 13:41 UTC (9 hours ago)
        
 (HTM) web link (ptrtojoel.dev)
 (TXT) w3m dump (ptrtojoel.dev)
        
       | pyrale wrote:
       | 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.
        
       | dotancohen wrote:
       | 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.
        
         | jhardy54 wrote:
         | 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").
        
       | przmk wrote:
       | 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.
        
         | qup wrote:
         | you want the ctrl+p plugin
         | 
         | It's a fuzzy file finder.
         | 
         | For your example of
         | `org/example/groupid/packageid/submodule/File.java` I might
         | write "[Ctrl+P] pamodFi[Enter]"
         | 
         | If `File.java` is unique enough, I can just type that and it
         | finds it without issue.
         | 
         | There's also filetree plugins if you really want the visual
         | clutter
        
           | vips7L wrote:
           | This is even how I navigate files in IntelliJ.
        
             | brabel wrote:
             | 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.
        
         | wffurr wrote:
         | 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.
        
           | le-mark wrote:
           | 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?
        
           | fire_lake wrote:
           | What's the LSP tool that integrates with Bazel?
           | 
           | Is it open source?
        
             | gorset wrote:
             | 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.
        
           | VHRanger wrote:
           | I can recommend the yazi CLI tool for filesystem traversal:
           | 
           | https://yazi-rs.github.io
           | 
           | 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.
        
             | fleekonpoint wrote:
             | There's a yazi nvim plugin too!
        
               | metaltyphoon wrote:
               | Been using yazi for the terminal but not as a plugin yet.
               | Perhaps I should give it a try. I've been happy with
               | oil.nvim too
        
           | fernandotakai wrote:
           | another solution for fuzzy finding is telescope.nvim
           | https://github.com/nvim-telescope/telescope.nvim
           | 
           | the thing i like the most about it is the amount of plugins
           | you can add (including things like looking at nvim's paste
           | ring).
        
             | slowmovintarget wrote:
             | I believe that the Neovim Kickstart project gives you
             | Telescope as the fuzzy finder. (The YouTube video by TJ is
             | linked in the README.)
             | 
             | https://github.com/nvim-lua/kickstart.nvim
        
           | rat87 wrote:
           | > what happened to eclim
           | 
           | 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
           | 
           | https://github.com/ervandew/eclim
           | 
           | > (Aug. 03, 2024)
           | 
           | > 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
        
         | lsllc wrote:
         | 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.
        
           | pjot wrote:
           | Similarly, I found the kickstart.nvim immensely helpful as a
           | jumping off point.
           | 
           | https://github.com/nvim-lua/kickstart.nvim
        
           | jitl wrote:
           | <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
        
             | lsllc wrote:
             | 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).
        
         | mhd wrote:
         | 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.
        
         | BeefWellington wrote:
         | 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.
        
         | mdaniel wrote:
         | 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
         | 
         | 1:
         | https://docs.oracle.com/javase/specs/jls/se6/html/packages.h...
         | _(it 's the oldest spec version they still link)_
        
           | brabel wrote:
           | > The only exception that I'm aware of is that inner classes
           | don't have to live in their own filename
           | 
           | Not only inner classes, you can have many top-level classes
           | on the same file but they cannot be public.
        
         | baq wrote:
         | 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.
        
         | konfekt wrote:
         | Try filepicker.vim [0] to navigate these in one of the many
         | popular millers like lf, yazi, ranger or nnn
         | 
         | [0] https://github.com/Konfekt/filepicker.vim
        
       | chessweb73 wrote:
       | No, I don't.
        
         | alexvitkov wrote:
         | This is not an unpopular opinion you needed to make a new
         | account for. None of us do.
        
         | gilleain wrote:
         | Agreed. With some decades of Java experience, I would only use
         | Eclipse or IntelliJ or similar to develop non-trivial Java
         | programs.
        
         | aomix wrote:
         | Even the post is in terms if "Dear god why? But if you must..."
        
       | haltcatchfire wrote:
       | 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...
        
         | soraminazuki wrote:
         | I always choose standalone tools for formatting so that it can
         | be integrated into any editor/IDE and checked by CI.
        
           | shepherdjerred wrote:
           | You can run Intellij's checks in CI:
           | https://www.jetbrains.com/qodana/
        
       | SvenL wrote:
       | 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).
        
         | ramon156 wrote:
         | 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!
        
           | Carrok wrote:
           | > There's a theory that actively thinking about this will
           | prevent u from making mistakes like forgetting a semicolon.
           | 
           | I never want to waste a single brain cycle on a missing
           | semicolon. That is what the editor (or autocomplete or AI or
           | whatever) should be doing for me.
        
             | robenkleene wrote:
             | 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.)
        
             | mekoka wrote:
             | 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.
        
               | tsimionescu wrote:
               | 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).
        
           | sureglymop wrote:
           | 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.
        
             | mnsc wrote:
             | 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".
        
           | tolciho wrote:
           | 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!
        
             | freedomben wrote:
             | 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.
        
           | soraminazuki wrote:
           | LSPs visually warns you the instant you forget a semicolon,
           | so that error will only happen when you _don 't_ use LSPs.
        
         | robenkleene wrote:
         | 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).
        
         | vbezhenar wrote:
         | 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.
        
           | tsimionescu wrote:
           | > notepad.exe, vi, emacs/vim/notepad++, vscode, idea
           | 
           | You forgot the natural root of this hierarchy: ed, the
           | standard text editor.
           | 
           | https://www.gnu.org/fun/jokes/ed-msg.en.html
        
         | Kwpolska wrote:
         | 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.
        
         | rat87 wrote:
         | 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
        
         | serial_dev wrote:
         | 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.
        
           | rafaelmn wrote:
           | > 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 ?
        
             | nobleach wrote:
             | 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.
        
           | ghm2180 wrote:
           | > the frameworks and the actual project.
           | 
           | This.
           | 
           | 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.
        
         | mardifoufs wrote:
         | 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.
        
         | imron wrote:
         | My .exrc file is about 10 lines long and has no plugins.
         | 
         | Combined with ctags and a terminal it's all I need for the
         | languages I'm familiar with (c, c++, rust, python and several
         | others)
        
         | o11c wrote:
         | 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.
        
       | Myrmornis wrote:
       | 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?
        
         | mr_tristan wrote:
         | 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.
        
         | JavierFlores09 wrote:
         | > 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
        
         | Kwpolska wrote:
         | 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.
        
           | brabel wrote:
           | 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?
        
         | mardifoufs wrote:
         | 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.
        
       | nelup20 wrote:
       | I like the idea of LSPs and have tried switching to
       | Vim/Neovim/Emacs a few times, but Jetbrains'
       | refactoring/intellisense is just so much better imo
        
         | atomicnumber3 wrote:
         | 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?
        
           | Kwpolska wrote:
           | JetBrains Rider for C# is equally awesome. And you don't need
           | to paste XML snippets for dependencies, it's in the GUI.
        
             | neonsunset wrote:
             | Nowadays, the package management can also be easily done
             | with CLI:                 dotnet add package GxHash
             | dotnet remove package ...
        
           | freedomben wrote:
           | 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.
        
             | atomicnumber3 wrote:
             | 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.
        
             | usrusr wrote:
             | 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. Baby ask for what 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)
        
             | winrid wrote:
             | Your issue was going against the grain and using Vim.
             | Everyone was using an IDE because they found the optimal
             | workflow and just wanted to work.
             | 
             | It's like joining a team of roofers and using a hammer
             | while everyone else is using nail guns... sorry, the right
             | tools are faster.
             | 
             | Also FYI you don't need to use a mouse to get the types,
             | moving a cursor over the variable is enough.
        
           | TiredOfLife wrote:
           | There is nothing in lsp world that comes close to PhpStorm
           | for PHP and RubyMine for Ruby.
        
             | nobleach wrote:
             | 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.
        
               | cwbriscoe wrote:
               | 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.
        
               | winrid wrote:
               | 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?
        
           | mardifoufs wrote:
           | Vscode provides extracting methods and variables too, at
           | least it does for python and c++. I didn't know it was a rare
           | feature.
           | 
           | What other platforms and languages have you used recently to
           | compare with java?
        
             | shepherdjerred wrote:
             | IntelliJ's refactoring functions are significantly more
             | powerful than what VS Code has.
             | 
             | Compare:
             | 
             | https://www.jetbrains.com/help/idea/refactoring-source-
             | code.... (note the possible refactors in the sidebar)
             | 
             | https://code.visualstudio.com/docs/editor/refactoring
        
         | mardifoufs wrote:
         | Vscode uses LSP, and for most mainstream languages it can
         | provide refactoring, definition lookup, symbol renaming, etc.
        
       | tofflos wrote:
       | > 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.
       | 
       | 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.
        
         | jitl wrote:
         | 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.
        
         | itronitron wrote:
         | Is there a Java code assist utility for neovim that isn't a
         | language server?
        
       | cess11 wrote:
       | 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.
        
       | carlinm wrote:
       | 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.
        
         | giancarlostoro wrote:
         | 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.
        
           | TiredOfLife wrote:
           | > That alone would flip so many die hard Vim users.
           | 
           | It wouldn't. Diehard Vim and Emacs users might hate each
           | other, but they hate IDEs more.
        
       | 77pt77 wrote:
       | No.
       | 
       | I don't whant to write Java, let alone in *vim.
        
       | mdaniel wrote:
       | Relevant:
       | 
       |  _Ask HN: Programmers who don 't use autocomplete/LSP, how do you
       | do it?_ - https://news.ycombinator.com/item?id=42492508 - Dec
       | 2024 (625 comments)
        
       | rubyn00bie wrote:
       | 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.
        
       | gorset wrote:
       | There's a lot of ceremony to run jdtls!
       | 
       | I find it easier to just install language servers using brew.
       | Then the command can be simplified to                     cmd = {
       | 'jdtls', '-data', home_dir .. '/.local/state/jdtls/' ..
       | project_name },
       | 
       | My ftplugin/java.lua is about 100 lines, with most of it being
       | settings and key bindings.
        
         | nobleach wrote:
         | 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?
        
       | helsinki wrote:
       | Interesting. JVM langs are the only ones I don't write in Neovim,
       | due to abysmal support (namely, Metals). I'll go through your
       | instructions.
        
       | samgranieri wrote:
       | 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.
        
       | ghm2180 wrote:
       | Here is what I would do to even approach this
       | 
       | 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
        
       | codr7 wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2024-12-28 23:01 UTC)