Yes there are.

...but the parent assertion that Java will one day be like cobol; no longer taught in intro to CS course (where now we see python), considered bloated and legacy, and not picked for new projects (where we see the rise of languages like kotlin eating into what was once the primary growth for the language with mobile apps) and encumbered by problematic licensing issues...

Seems quite valid.

You have to live in a bubble right now not to get the feeling Java is stumbling, and there’s no indication to me that the overall direction of the language is positive right now.

...I’m sure there are still years ahead for earning a good living as a java developer, don’t get me wrong, but that’s a different issue.

But I disagree that Java is like Cobol. The syntax and general situation is extremely similar to C++. There's still tons of work being done on it, but it's a mature language that will be around for decades. IMO it's still the best language to run on the server for a multitude of reasons.

> But Spring is dated and not often used for new projects.

Spring Initialzr (https://start.spring.io) is used millions of times per year.

Thanks, looking it ip

Fast is a poor word to talk about benchmarks between languages. Memory, throughput, latency are the things we should be talking about. There’s also trade offs where predictable scaling of latency under massive load is important (Erlang, Elxir), or spending less memory and starting up quickly in order to scale horizontally is important (Golang), or speed of development is important (PHP, Python), or correctness is important (Haskell, Rust). Java is rarely the winner in any area in favor of being well rounded, but as we should be using tools that meet at least the broad requirements it is always possible to make a better choice than Java.

> I’ve seen apps run for years straight.

This is why Java is dated. I am an Erlang developer, which is known for being hot reloadable and running forever. It turns out this model is actually juxitposed to Kubernetes and severless, which both presuppose letting processed crash at the host level and starting and stopping quickly. This also gets into the tooling argument because profiling in Java would rather the VM be long lived.

> The tooling.

I too have an operating system with great tooling, it’s called Linux. My knowledge of tooling is more broadly applicable, I can introspect any binary and attach probes to the kernel with bpf. Profiling for a VM is table stakes because you’re on your own. Not only do you have to figure out what’s going on in the JVM you also need to duplicate your effort to figure out how the JVM is running on the host.

> Java OO is fine.

OO in general is not fine.

Isn't that true for all other languages you mentioned? python, erlang, php, golang bundles a runtime, etc..

Go and Rust are interesting to follow. A highish and low level language both using lightweight runtimes

I smell a zealot or a troll.

Smalltalk is exactly like that - other objects' state is only mutable through explicit message passing. It's also widely considered the penultimate pure OO language.

> Pretty much all of the OO languages are walking back OO features

About the only feature I can think of for which this is somewhat true is inheritance, and that's because we realized that aggregation is often a better model, and can be easily supported by the language to be no more verbose. But it doesn't fundamentally change OO - it was never about inheritance first and foremost; I mean, prototype-based OO doesn't even have that conceptually.

> and trying to add type classes (contracts)

In most OO languages, these typically naturally evolve out of interfaces.

> functional pieces, mapping and filtering a la linear data transformations.

This is not contradictory to OO in any way. Again, Smalltalk has had "select" (filter) and "collect" (map) from the get go.

Lombok makes immutable data classes trivial. Improved interface support for default methods make it possible to largely ignore OO if you don't want it.

FP is mostly a community effort at this point, but solid. Java Streams are decent for basic stuff like map/filter but RXJava is extremely powerful if you want the complexity it comes with. Vavr is nice for adding more FP types too

IMO Java is the most well rounded language, but I'm not trying to convince you of that.

Also there's nothing with java that stops threads from being restarted. In a modern web framework it's virtually impossible to crash the JVM. You just crash a thread, at most (usually the framework catches the exception and it doesn't even do that). Java is also hot reloadable if you use the right framework.

Your tooling argument doesn't make much sense IMO. You can attach to a Go binary but that's about it. Attaching to a VM or interpreter will tell you almost nothing. I would wager you haven't used a Java profile if you're making these arguments. It's vastly superior to anything but maybe C#

You’re not understanding what I’m talking about when I say restarting. I’m talking about the JVM process. I also just said hot reloading is counter to modern practices.

You’re not understanding what I told you.

You can also compile AOT for some performance loss at runtime but zero startup time. Android has been doing this forever but you can also do it on a PC using Graal.

And yes Java will destroy Erlang at concurrent connections if you use an async framework like Vert.X or fibers using Quasar/Comsat. It has lower per thread overhead than Erlang and runs code faster in general.

Both Java and Erlang will max out Linux TCP connections before running out of steam so this is kinda academic though

I don't drool over the raw horsepower of each of my individual boxes.[1] All I care about is that I can cost effectively create a cluster of them to serve the application's needs.

Because of this, even if Java could not handle as many concurrent connections, you might still chose it over this fabled 10M socket erlang server you keep talking about.

You might chose Java because:

* It is well understood and has a lot of mature libraries surrounding it.

* You can easily hire people to work on it.

* It is a stable language.

And so on...

I would summarize your original post like this: "I don't like Java, I prefer other things," which is fine as far as it goes, but then you basically say: "Therefore, everyone should also prefer the same things I do," which does not follow.

[1] I never particularly cared how many fps I can get on my machine, and I'm not that chuffed about my machine's geekbench score. IMHO this obsession with hardware metrics beyond diminishing returns is mostly a gamer thing.