Its standard library reads like someone's Object Oriented Programming 101 final project, and they probably got a B- for it. Everything works and follows OO principles, but they didn't stop to think about how it's actually going to be used.

Let's try to read a file line-by-line:

BufferedReader reader = new BufferedReader(new FileReader("sample.txt"));
String line = reader.readLine();

We're having to instantiate two objects (FileReader and then BufferedReader) just to get an object that has a readLine() method. Why? Can't BufferedReader take a file name on its own and work it out? Or FileReader just provides readLine() itself?

Not only that, but being parsimonious with what we import would result in:

import java.io.BufferedReader;
import java.io.FileReader;

But we're much more likely to be lazy and import everything with import java.io.*;. Which is sloppy, but I understand.

I can see what they were thinking when separating these concerns, but it resulted in more complexity than necessary.

There's a concept of "Huffman Coding" in language design. The term itself comes from data compression, but it can be generalized to mean that things you do often in a programming language should be short and easy. The above is not good Huffman Coding.

I think a lot of it is "ceremony", so it's pretty common in java to:

• create a get method for every object variable
• create a set method for every object variable

Then add on top that you have the increased code of type annotations PLUS the increased code of having to check if a value is null all the time because all types are nullable.

None of that is hugely complicated compared to sone of the concepts in say Rust, but it does lead to a codebase with a lot more lines of code than you'd see in other similar languages.

Java itself is kind of blissful in how restricted and straightforward it is.

Java programs, however, tend to be very large and sprawling code-bases built on even bigger mountains of shared libraries. This is a product of the language's simplicity, the design decisions present in the standard library, and how the Java community chooses to solve problems as a group (e.g. "dependency injection"). This presents a big learning challenge to people encountering Java projects on the job: there's a huge amount of stuff to take in. Were Java a spoken language it would be as if everyone talked in a highly formal and elaborate prose all the time.

People tend to conflate these two learning tasks (language vs practice), lumping it all together as "Java is complicated."

$0.02: Java is the only technology stack where I have encountered a logging plugin designed to filter out common libraries in stack traces. The call depth on J2EE architecture is so incredibly deep at times, this is almost essential to make sense of errors in any reasonable amount of time. JavaScript, Python, PHP, Go, Rust, ASP, C++, C#, every other language and framework I have used professionally has had a much shallower call stack by comparison. IMO, this is a direct consequence of the sheer volume of code present in professional Java solutions, and the complexity that Java engineers must learn to handle.

Some articles showing the knock-on effects of this phenomenon:

• https://stackoverflow.com/questions/11865307/how-to-expand-size-of-java-stack-trace-to-see-bottom-of-stack-triggering-a-sta
• https://www.reddit.com/r/java/comments/16g30jx/can_java_errors_stack_traces_be_longer/
• https://www.quora.com/Why-does-the-Java-Spring-Framework-produce-gigantic-unreadable-stack-traces
• https://community.splunk.com/t5/Splunk-Dev/What-are-the-best-extraction-methods-for-Java-Stacktrace-Errors/m-p/380397
• https://stackoverflow.com/questions/65436457/springboot-stack-trace-logging-filter-only-from-my-packages

Char count for same functionality is still at least double in java vs python. It just feels like a chore to me. jetbrains helped, but still python is just so light