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.
