The Oracle Java Platform Extension for Visual Studio Code

The gap is closing but it's still noticable.

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.

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.)

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.

And yet the very opposite of this is the source of JetBrains success.

- https://www.eweek.com/development/eclipse-behind-the-name/

- https://en.wikipedia.org/wiki/Eclipse_(software)#Name

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.

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.

Java has some plusses and minuses like any language.

Java has:

* Fantastic concurrency support (Better than Javascript, Python, or C)

* One of the largest most mature library systems in existence, with far fewer amateurish "left pad" type libraries like Javascript or Python

* Supported basically everywhere by any vendor you can imagine

* Pretty good strong type system to reduce bugs, and making refactoring very easy

* plethora of frameworks for your use case, whether its server side rendering, monolithic apps, Raw SQL or ORM, microservices, reactive.

* Probably the best tooling and ides in software development.

* getting lots of new features to alleviate pain points with the newer rapid development

Negatives for Java:

* C# has linq

* Type system isn't as advanced as OCaml

* Generics have type erasure due to backwards compatibility

* verbose and lots of boiler plate

- 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.

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.

> 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.