Stop using Java just let it die for the love of all that is holy
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.
[1]: https://survey.stackoverflow.co/2023/#section-most-popular-t...
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.
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.
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.
[Citation needed]
Java has an incredibly mature ecosystem, and Java 11/17/21 fix a _lot_ of the problems Java had.
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.
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
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.
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.
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.
- 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.
https://docs.gradle.org/current/userguide/distribution_plugi...
> 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.
https://github.com/uber/NullAway and bunch of rest.
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.