"Am I using the correct language runtime distribution (or version thereof) so I don't get into legal trouble?" Is a question none of Java's competitors have to ask.

Even using OpenJDK is a sword of damocles waiting to fall. If I forget to update OpenJDK, Oracle could come after me. It's just risk that I don't have to worry about by choosing not to go with Java. It's probably not a lot of risk, but it's risk nonetheless that doesn't exist with Java's competitors.

Competition is so fierce in the language space and there are so many good options that java can't afford to have any friction points like this.

EDIT: I got oracle openjdk and oracle jdk mixed up. They're different things. It looks like the oracle openjdk does not have its license change, the oracle jdk does. This is a problem/risk I don't have to worry about with any other language, but getting the two mixed up is on me.

> only downside is you have to upgrade every half year

LTS OpenJDK distributions from eg Eclipse (17, 21 etc) stick around for longer[1]. Heck, you can still get updates for JDK 11 and even 8.

You do have to update the runtime for security and other fixes, but that’s true for other languages too.

[1] https://adoptium.net/support

All that just seems like friction when there are frictionless alternatives available. Life's too short for friction.

If we look at .NET vs Java, then yes, Microsoft is better. Microsoft may charge for some of its dev tools (Visual Studio etc), but .NET itself is and was always totally free.

Depends. If you were there during the Steve Ballmer time then you know that Microsoft will absolutely betray you on almost every dev tech they roll out.

Otherwise C# and .NET have had a pretty solid track record.

> just get some openjdk distribution

From several sources:

- Oracle themselves, at jdk.java.net - Microsoft, at microsoft.com/openjdk - Red Hat ... - Azul Systems ... - Amazon - Bell Soft - Canonical (Ubuntu ships OpenJDK binaries built by them) - build yourself?

I'm not sure where things fall on your timeline, but in case you missed it, Amazon has their own Java distribution called Corretto. It was first publicly released in 2018:

https://downloads.corretto.aws/#/overview

This conspiracy theory would explain not only success of Rust, but also Go language and C#/.NET, and any other Java competitor.

I'd say it's 90% because of Oracle and its lawyer-driven business, and 10% because the language is just ugly, and existing libraries are super-ugly and unreadable, with all these Factories and AbstractFactories, and all design patterns forced like a religion whether they're useful or not in a specific context.

> seduced by the promises of a language simple to learn, build, and deploy

That's actually quite correct and I'm saying this as someone that does Java on daily basis. Go is in fact superior in terms of deployment. I would rather deploy a Go-written service than a Spring Boot one. That being said, I love using Java for monoliths - large code bases crammed with business logic. I personally don't see Go doing very well in that direction.

Go is slowly becoming Java 1.5+ -- see the addition of generics.

Btw, you can AOT compile Java if you wish... it'll probably be a larger binary than a Go binary, but that's whatever...

[Meta] ... God, I'm turning in pjlmp here, lol

Creators of Go within Google conveniently left out the fact that within Google there's still far more Java code than Go code.

> by several large engineering organizations, which made the move

The problem with this type of trend is it's often hype and you never know what actually happens or how does it evolve over time.

I've seen organizations make certain announcements, switch maybe 5%, give up and go in different directions, but only the initial announcement ever hit the news.

> and seduced by the promises of a language simple to learn, build, and deploy

It's always simple if you rip it all up. Nice and shiny toys are always great.

> tl;dr -- containers eliminate Java long term

Why can't they co-exist?

> has eliminated the argument that would favor the JVM

This complaint is taking technology definitions too literally. I doubt new adopters of Java or the JVM are really going on about that now. It's more been about the ecosystem, the maturity, etc.

Oh I didn't know about that. Is JetBrains improving on accessibility, at least, or not really?

As of somewhat recently, Kotlin has a language server: https://github.com/Kotlin/kotlin-lsp

Using it in vscode, while not perfect yet, is starting to be alright.

I mean, I agree that it is really good! I'm just hoping that it will come in fashion, versus those ElectronJS... things.

Nobody complains about the Rust turbo-fish operator which is pretty verbose too. Java has already has introduced a direct toList()/toArray() anyways.

    let v = (1..5).collect::<Vec<i32>>(); // Cool Rust

starting with JDK 16, Stream has .toList() that will save you ten characters for the .collect()

It's very difficult for a language designer to satisify the aesthetes.

I feel there's much more to it. There are so many pieces in Clojure that just feel like they're done right. Even after a decade of using it, I remain happy. Not a single other language (and I tried more than a few) has kept me happy for so long.

Well, there are lots of people out there who view "Pythonic" as a euphemism for awful tbh. Throughout my career I've seen multiple large Python codebases be rewritten in Java after they turned into a mess, including - perhaps most embarrassingly - Google's internal code review tool Mondrian, which was written by Guido van Rossum himself.

One reason Java codebases feel more abstract is that they're attempting to solve problems that the scripting worlds tend to just punt on, or handle in ways that don't scale well. And because Java's type system is nominal, solutions to those problems require names.

For example, a lot of the abstraction in Java codebases is to make things deeply testable. That's what drives dependency injection, which is where a lot of BeanFactory stuff comes from. What's the Python solution to that problem? Often they just hardly have tests by the standard of Java developers! This is why Python is big in ML research where codebases are often small disposable experiments, and why after a brief era where Django was popular it sort of died off in the wider server / big data space.

Another source of complexity and abstraction is a focus on pluggable ecosystems. Databases are abstracted by JDBC, and then again by an ORM, which then might be abstracted again by Micronaut or Spring, and at each layer there are multiple competing implementations available which implement standard APIs. This kind of thing happens much less in the scripting world. The downside is that scripting codebases are far more locked-in to their choice of libraries. Porting a Java codebase from one database or ORM to another is hugely easier, because the core APIs are all standardized.

It's a culture, not language thing. Here is a JSON parser implementation (part of PlantUML) that lacks endless levels of abstraction.

https://github.com/plantuml/plantuml/blob/master/src/main/ja...

Those are not Java paradigms per se - they're just practices of mediocre enterprise developers, of which Java has many, owing to being such a mainstream platform.

As for the language itself, a lot of verbosity has been culled in later language versions, with diamond operators, lambda expressions, local variable type inference, etc.

In either case, code is read more than it is written, so if a bit of verbosity makes code easier to read, I'm okay with it.

As others are saying, it's a culture not the language. C++ and even some Python etc written in the late 90s, 00s era has the same pattern-itis. It comes from slavish adherence to the Gang Of Four patterns books and an obsession with OO generally. Also the languages themselves were weak on non-OO abstractions and ways of doing code re-use, so for example it took forever for Java to get lambda expressions ... so people used one-off helper classes with "invoke" methods, etc.

ThingDoer.doThing was often just functional programming squeezed into an object-oriented straightjacket. Java 8 added first-class functions and lambdas over a decade ago, eliminating a lot of the need to turn simple behavior into full-blown classes.

One reason for that Java style is that Java was not such a powerful language for a long time. For example lambda expressions were only introduced in Java 8 (2014) and before that developers need to work around this restriction. A common workaround were/are some annotations above of methods and some reflection magic on top. For example a life cycle callback method annotated with @PrePersist is basically the same a registering a _function_. The whole Lombok library is a massive hack to circumvent some inconveniences in Java (and in my opinion no longer needed).

I think a lot of it is the people using it and certain parts of the culture. There are a lot of Enterprise TM programmers that seem to believe as many layers of abstraction and as much verbosity as possible with little tiny methods that do practically nothing leads to better solutions. It is totally possible to write concise and pragmatic code with Java. One thing that will be a thorn in your side though is null handling. The traditional approaches increase line count and branching. The newer(ish) Optional-based null handling is quite verbose but in width.

I think it doesn't have to be like that, but it's the way Java code has been written for ages, so those habits stuck. You can see it clearly when you bring a Java programmer to collaborate on a Ruby or Python codebase, if you let them, the will turn your codebase into an enterprise-ready mess with layers on top of layers of indirection in a blink.

> by-product of Java's strict type system

1. Lack of first class functions till Java 8 is one reason old APIs are horrible with inheritance and reflection everywhere. You had to extend class and override methods even for simplest of tasks.

After Java 11 the code is much more succinct and functional style. But old libraries remain.

There are places where the overextensibility these libraries provide is useful. But those are few.

2. the annotation processors were late to the game - so many libraries which need to inspect object structure (such as serialization) were written with heavy use of reflection.

I will give you an example of how frameworks designed for "modern" Java look like.

Micronaut has something called Micronaut data JDBC - in which you just declare methods with few annotations eg `List<Book> queryTop10BooksByYear(int year)` and it will auto generate the JDBC + SQL code and handle injecting it into your service. The returned object can be a POJO without all the Proxy object circus ORMs come with. I haven't seen something as easy in Python yet. And all this happens in compile time with an annotation processor.

As someone who has seen awful code in pretty much every language I've worked with, I'd blame this more on inertia and reluctance to change habits. The bad patterns that have entrenched deep into the ecosystem are very hard to shed even when the language and platform is making progress at impressive speed.

As other sibling comments have said, it's cultural. Fortunately, there's some push toward functional & ADT-style modelling in the Java community and they've decided to call it "data-oriented programming" for some reason.

Eh, I don't think Java type system is strict, nor is it the root cause of this cargo cult mess. It's probably due to many enterprise programmers who think design patterns are the building blocks of everything rather than an invisible, emergent structure.

I think it is quite high, especially for newcomers to the ecosystem. The popular sdkman CLI tool for managing JDK installations provides 17 different JDKs to install:

https://sdkman.io/jdks/

With the DotNet SDK for comparisons sake, there is but one provider, and package management is provided as first class citizen in the compiler CLI, removing the need to even pick a "gradle" or "maven" style build tool in the first place for almost any project.

    $ cat Foo.java
    interface Foo {
        private String jimbo() {
            return "yup";
        }
    }

    $ javap -c -private Foo
    Compiled from "Foo.java"
    interface Foo {
      private java.lang.String jimbo();
        Code:
           0: ldc           #1                  // String yup
           2: areturn
    }

    interface Bar {
      default boolean isAwesome() {
        return true;
      }
    }