I love VS Code, but I will never be able to work with Java code outside of IntelliJ. Hopefully this extension is a bit more stable than the Red Hat one, whenever I've attempted to use VS Code for Java it's hit or miss whether plugins or the language server crash.
Not sure IntelliJ has a crown here. I use Eclipse and it has some pretty amazing refactoring options. And I really prefer it to IntelliJ (for my use cases at least). Are there particular things IntelliJ can do that Eclipse can't?
I tried eclipse again last year and, while I cannot say it has bette for worse refactoring, I don’t understand how it could possibly be better given that its detection of available symbols seems to be little more than an RNG.
2008 was 15 years ago and many of the people I've spoken to formed their opinion of Eclipse (and IntelliJ) at that time. But what you saw back then and now isn't anywhere near being the same software.
Can you explain why Eclipse is worse than IntelliJ today?
I think I last used eclipse about 5 years ago, when I switched to VSCode. At the time, eclipse still felt like 2008 software, extremely sluggish and clunky. In particular, it really suffered taking advantage of multiple monitors.
What's changed since then? Has it gone through some kind of massive redesign?
Could you please explain? You say you don't know if it's better or worse for refactoring and then you say it's detection of symbols is like a random number generator? How so?
When I used eclipse, it is suggesting symbols from locations that are not even contextually available. Given how much refactoring often relies on accurate contextual symbol detection, there’s about a 0% chance that it does better than IntelliJ.
I didn’t even get to trying eclipse features because everything else in it is so remarkably stupid, useless, and actively battling me compared to IntelliJ.
I have been working on enterprise Java projects (basic consulting) which uses eclipse almost exclusively. We do not use Smurf naming convention (SmurfDto, SmurfDao, SmurfService, SmurfController) just for being able to find related classes. We do it because eclipse seems to randomly refactor classes based on non fully qualified names. No to naming something Constants as that will (randomly) refactor the codebase to break partially if you decide later to refactor something in that class.
I have tried everything from no vendor plugins for app servers to a vanilla eclipse and it still messes up.
I do like the product, but it can be very frustrating at times.
Kotlin. I switched to Intellij due to Kotlin, in is slow in Eclipse
But seriously, Eclipse was helping me more then Intellij does and has better defaults. It shows all errors and warnings at once etc. Even things Intellij actually has like call hierarchy tend to be sort of hidden by default.
"The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin."
I find all these posts slamming java and suggesting to use all the either much smaller jvm languages or something like python / go / rust utterly hilarious. If you want to get paid the big bucks in a high col city, you are a java or c++ dev, simple as. Sure work on your smaller languages, more pay for the rest of us!
RedHat one is buggy and slow, but it works after tinkering and display a lot of warnings and code suggestions.
This extension loads instantly without any issues but it show 0 warnings/errors in my project. "Find all references" works as expected.
Java developers are spoilt for choice right now. IntelliJ is on it's own plane of existence, newest versions of Eclipse are really really nice, and now this which is based on the Netbeans engine!
Hands down Java tooling, and especially the JVM debugger, is the absolute best across all languages available today. Truly is an incredible platform
I think it's something you have to try out. I use all three.
IntelliJ has just a billion little streamlined features that make the entire experience just smooth. Eclipse is in second place here, but VsCode with Java is a very distant third.
IntelliJ is functions without a lot of annoying bugs; everything is well tested and just works. Eclipse is buggier, and usually lags behind on supporting the latest JVM/Java/Framework features without bugs, but Eclipse has nothing compared to VsCode. VsCode just is just full of half completed features that work in very narrow circumstances. I don't know what to say; it's just not very well integrated, lacks a singular vision, and things generally are just broken.
So - I'm not a Java programmer, but I do a lot of C# in Visual Studio 2022, Visual Studio Code and JetBrains Rider (which is built on the InteliJ engine), so I guess I have a unique perspective. Rider is hands down better at refactoring and generally having features "out of the box". Visual Studio 2022 is pretty buggy recently, especially for mobile, which is the bulk of what I do recently. VSCode is okay... got better recently (the C# Plugin is now a full on full Microsoft first party offering), but VSCode is still less like an IDE, more like a code editor.
I guess VSCode seems to march to its own drum and some of how it integrates things is really clunky still. I spent a long time ignoring JetBrains, but once I started to use Rider (and Android Studio) I realised how much better they were in general.
With Android development (which to be fair I mainly do on the side), I remember Eclipse being reasonably hard to get set up. That might have just been with how immature the Android tooling was back then. But from the very first version of Android Studio, it all seemed coherent. And with all the built in refactoring and tooling there is now, it is really a full circle and you don't exactly need anything else.
Edit: it is also worth pointing out that adding Resharper to VS2022 makes it a lot nicer, but in my book that is basically the same as using Rider because then most of the refactoring is taken away from the Microsoft IDE's engine and goes though the same/similar path as it does in Rider (as Rider uses the Resharper Engine too.)
Most of the serious programmer oriented editors support LSP to some degree now. Vim, emacs, Sublime, etc. Even JetBrains’s IDEs support it in addition (or alternative) to their own custom tooling.
Sorry if dumb question, but is LSP similar to what Steve Yegge talked about years ago, I think on a StackOverflow podcast, whereby a language would declare its capabilities to tooling?
I haven't listened to the podcast you mention, but the answer to your question is yes. Quoting the langserver.org homepage[0]:
> The Language Server protocol is used between a tool (the client) and a language smartness provider (the server) to integrate features like auto complete, go to definition, find all references and alike into the tool
In LSP terms, these are called "capabilities". The relevant section in the LSP spec is here [1].
There's some variation across editors in exactly how the config works - or, at least, part of it. Some config is done in native files that form part of the plugin. Those are largely editor-specific. The protocol itself defines messages for the server to indicate which facilities it supports. Those are (mostly) editor neutral from my experience thus far (mostly VSCode, a little Emacs).
--
EDIT: added link to capabilities section in the LSP spec.
Yes, the genius of LSP is that it doesn't attempt to define common semantic operations across languages, which would be (and has been) an endless impossible task to get right. It operates at the level of editor UI. So you don’t ask LSP “what are the members of this struct”, you ask it “what are the autocompletions of this code fragment”. It leaves the decisions about what would be appropriate in the language to the language server written by the experts in the language.
Sort of, except not really. It’s largely the other way around: LSP gives the editor a way to declare its capabilities to the language.
The key insight with LSP is that languages are _way_ too different to have that notion of language capabilities. Instead, the LSP defines functionality that the editor wants to use (syntax highlighting, refactoring, autocomplete, etc) and the language server tells the editor what to display.
When you trigger autocomplete in VSCode, the editor has no clue whether it’s autocompleting a method, a class name, or a variable. It’s just telling the language server “hey the user asked for autocomplete in file X, offset Y” and the language server tells the editor what completion options to offer.
This is great news. I'm trying to move from Idea to vscode and Java support could be better. I think that Jetbrains missed the chance to introduce their tooling to vscode.
More LSP servers for Java is good. The Eclipse based one seems to work for me as part of lsp-mode for Emacs, but equally I'd love to see the IntelliJ one mature, and a Netbeans one isn't bad to have either.
Are you able to get proper jump-to-definition for stuff in jars? Say you’ve declared an import from a jar, and you get to that import and run ‘jump-to-definition’ (or whatever it is), are you taken to the source of the import? I’m sure IntelliJ idea does this but I cannot get emacs+jdtls+eglot to do this
Oracle needs to refocus on Eclipse and leave Visual Code crap alone, focus on Eclipse and kick the enterprise Red Hat yahoos out of the Java space. Red Hat gave up on developers when they split Red Hat into the enterprise version and Fedora garbage.
"It turned out Sun wasnt the target of the Eclipse moniker, though. In his keynote at the EclipseCon 2005 conference in March, Lee Nackman, chief technology officer and vice president of Design, Construction, and Test Tools at IBMs Rational Software division, said Microsoft Corp. was actually the company IBM wanted to 'eclipse' and was the true object of IBMs attention."
Serious question, is Red Hat a risk to the Quarkus project? I haven't started any new applications on anything but Quarkus for a couple of years. I would love to use Helidon, but the features and production stability just aren't there yet.
Any single vendor product that does not conform to a specification is, ergo Quarkus (was).
Now, Quarkus _finally_ got pulled into JakartaEE certification kicking and screaming, however, it has a million out-of-spec features that I see as risky and likely to break in the future... Spring Framework is now big fat and ugly for this reason!
Quarkus's initial philosophy of "Kubernetes first" really isn't such a good rally cry anymore. They've toned down on that, but it does influence the framework to this day.
I think if you program and stick to "just the" Jakarta Spec you are in good hands (which Quarkus now implements, along with other APIs). CDI absolutely rocks and is probably the easiest to write fast code for, but also make it composable so it's very testable.
I'm hoping someday the Apache Foundation (maybe the TomEE crew?) comes out with a leaner competitor to Quarkus, basically something thats "just the cdi container" and you can pull in stuff as needed.
The stable and mature ecosystem and fantastic tooling along with very low amount of library churn makes it one of the better options for anything server-side.
I've not seen a new project started in Java in a decade, and it's pretty far down in the StackOverflow developer survey [1]. Do you have some data to back your claim up?
Every language above Java in that list (except possibly TypeScript) is forced by the development target or domain. JavaScript and HTML are forced by web dev. SQL is forced by databases. Python is forced by machine learning. Bash is forced by targeting UNIX.
Also there’s no such thing as “an HTML project” or “a SQL project.” So I don’t think your survey link is telling you what you seem to think it’s telling you.
> It's less of a popular choice for new projects than it ever was.
Totally disagree. I think it was at its trough of popularity in the Java 8 initial release timeframe around 10 years ago, when many companies were still stuck on Java 6 and other languages had moved way ahead. In the last few years, since around Java 17, there has been a ton of enthusiasm and I think it would be the best choice for a huge number of use cases.
You're loose with the terms. Java is not "literally reference implementation", it's the platform language of JVM.
While this is a major advantage, Java has also its fair amount of problems, some of them unfixable (or rather, the Java team is unwilling to fix them). It looks like Java will never get a proper fix for the whole in the type system named null, while there are some great languages running on JVM solving that.
No he's saying that java gets the features implemented from the bytecode spec first. And you well know it, or maybe you have no idea and are just a kotlin fan boy...
COBOL is probably better compared to PHP or Ruby. COBOL was never as popular as Java, and its popularity was relatively short lived; by the time it was 20 it was quickly falling out of favour. In 2023, Java is the #1 most popular choice for serious server side applications, and is in the top 3 overall on pretty much any language ranking you can find. In terms of longevity and super-popularity, its only counterparts are C, JS, and Python. Comparing Java, or Python or JS for that matter, to COBOL completely misses both COBOL's history and the current state of the ecosystem.
Honestly, Java has a lot going for it. Amazing library ecosystem. Simple to learn, like Go but with essential quality-of-life improvements. Community without PLT sadists. Fast as all hell when written with care. Vast variety of jobs. Super-polished dev tooling.
I know there problems too (verbose, OOP and enterprise over-design, some horrible legacy systems) but Java is as strong as ever I think.
I'm interested, have you worked in Java before on a bad project and have scars, or have you built up a negative impression from afar?
> have you worked in Java before on a bad project and have scars
My guess is that the opinion is just used as a way to signal their status as a 'pro' developer much in the same way people used to hate on PHP/Perl/VB/etc. endlessly.
Ironically, this makes them look like amateurs posing as pro developers, as real pro developers demonstrate their status through their work, not their posts on social media.
> * Probably the best tooling and ides in software development.
Agreed on the IDEs, nothing can beat IntelliJ... but general tooling? Definitely not. Maven is a hot mess of XML where people tend to do horrible horrible hacks just to survive, and Gradle projects tend to be even messier because of Groovy's syntax allowing about five different ways of doing the same thing.
> Gradle projects tend to be even messier because of Groovy's syntax allowing about five different ways of doing the same thing.
Spoken like a true "I've never seen Gradle beyond copy pastes from Stackoverflow". Modern Gradle is all about plugins written in Kotlin. Your buildscripts shouldn't have anything beyond `implementation` block.
> Spoken like a true "I've never seen Gradle beyond copy pastes from Stackoverflow".
Which is what the majority of legacy, grown Gradle scripts are in my experience among multiple government and private companies' projects. The older the project, the worse state the build scripts tend to be. The worst I ever encountered was a project that was mainly done with Maven, but that called out to Gradle and Ant for weird manipulations to get the build artifact to the formats required... gives me nightmares to this day.
I'll give you gripes with maven/gradle (even though maven tends to just work for me), but look at all of the observability tools like Mission Control, Flight Recorder, and VisualVM. What other language has all of this?
There's nothing really wrong with it, but it's core design is pretty outdated in ways that are difficult to fix without putting together a totally new language. Couple of examples
- Support for nullable values. Swift and Kotlin have first class support for these, which are meant to minimize or reduce the number of null pointers in your code. You can mostly fix this with annotations, but those your team using them very consistently, and are not supported by most java libraries.
- It's approach to concurrency. Java built in synchronization primitive is based upon an older model of concurrency whose name I cant remember but it involves every object basically being able to maintain internal consistency with it's own state. No one still uses it like this, with most method creating an `Object lock` as a synchronization primitive.
- Serialization. Java has built in binary serialization support that ended up being a massive security hole. Most people are now forced to use some json serialization, but the old serialization format is still lurking in the background to ensnare less knowledgeable programmers.
- Generics. Smarter people than me can probably give you more detail on this, but generics were grafted on to the language long after it was introduced, and it shows. At runtime, there are no generic types kept, meaning it is technically possible to break the generic typing of an object.
None of these it should be noted are deal breakers or reasons why you shouldn't use the language. Almost every single one has some form of workaround for it. But if you're not aware of them (or stuck with an older legacy codebase like a lot of people are) they can be major headaches that can just be avoided by using a more modern language.
I use the termal and I make binaries for my use.
I'm not going to try to pipe input through several stages of "java -jar myUtil.jar", even if I bother to clear the hurdles of trying to find and configure the right maven plugin to build a "fat" jar.
Null drives a big hole through whatever you try to achieve with the type system. Need a Key for this Lock? Open the Lock anyway, just find out at runtime that the Key was null, rather than at compile time.
Bizarre omissions from the standard library. What do you do with Sets: Union? Intersect? Nope, write them yourself. Wait for a multiple futures? Write a for-loop. Cancel a future? Forget about it. Wait - better than forgetting about it: include cancel() on the class but make it a no-op.
Non-extensible. Let's say the language designers for some reason didn't put takeWhile into Stream. Can you add it?
No way to avoid mutation in order to avoid non-local reasoning about state. If I submit a list as a parameter or accept a list as a parameter, who else has mutated or will mutate that list.
No transactions. Synchronised blocks don't compose: synchronised get() and synchronised set() do not become synchronised getThenSet();
I'm sick of the 'backward compatibility' at all costs. The 'legacy code' that you're thinking of that you don't want to break was written after any of these problems could have been fixed.
> I use the termal and I make binaries for my use. I'm not going to try to pipe input through several stages of "java -jar myUtil.jar", even if I bother to clear the hurdles of trying to find and configure the right maven plugin to build a "fat" jar.
> Null drives a big hole through whatever you try to achieve with the type system. Need a Key for this Lock? Open the Lock anyway, just find out at runtime that the Key was null, rather than at compile time.
If you want to grow, I'd look at diving into a language with a fundamentally different paradigm like Common Lisp/Clojure/Scheme/Erlang/Elixir/F#/OCaml/Haskell.
It's not nothing, it's a solid step on from the Redhat Java LSP. Intellij's refactoring crown is not at risk here though.