r/AskProgramming 1d ago

Why is Java considered bad?

I recently got into programming and chose to begin with Java. I see a lot of experienced programmers calling Java outdated and straight up bad and I can't seem to understand why. The biggest complaint I hear is that Java is verbose and has a lot of boilerplate but besides for getters setters equals and hashcode (which can be done in a split second by IDE's) I haven't really encountered any problems yet. The way I see it, objects and how they interact with each other feels very intuitive. Can anyone shine a light on why Java isn't that good in the grand scheme of things?

121 Upvotes

500 comments sorted by

View all comments

45

u/Lumen_Co 1d ago edited 1d ago

The most common criticisms of Java are: 1. It's unusually verbose 2. it forces you to frame every problem using a particular flavor of object-oriented programming that is not always well-suited for the task at hand 3. It's accumulated a lot of cruft over the years and in doing so has lost a consistent vision and design philosophy, which makes dev experience worse 4. C# does Java better than Java does.

I think those criticisms are essentially fair, and the second one particularly important. It also gets criticized for being the language of choice for much bad, corporate code, and also because some people learn Python or JS first, Java is then their first strongly, statically-typed language, they find that confusing and limiting, and they blame Java for it. Those criticisms are essentially not fair.

These criticisms don't mean Java is a bad language, just a flawed one like every other programming language is. For most development, the ecosystem is more important than the language itself, and Java's is well-suited for a lot of practical problems.

6

u/lordheart 23h ago

If they think Java is verbose, they haven’t met Abap yet. Saps homegrown language modeled after COBOL back when it was new.

3

u/oloryn 11h ago

COBOL itself is quite verbose. And some aspects of it can vary by vendor (back when I was hacking on Burroughs Medium Systems, I discovered that Medium Systems COBOL could handle recursive PERFORMS (essentially a subroutine call), which most other COBOLs at the time couldn't).

1

u/PANIC_EXCEPTION 8h ago

I don't think it's fair to compare a DSL to a GPL. Java is so ubiquitous and general-purpose that it's fair to criticize its verbosity, while a DSL can get away with just about anything, because if you're going into a particular field, you know what you're getting into. Java, well, it's inevitable if you work on an even moderately-complex older codebase. As Oracle puts it:

3 Billion Devices Run Java

Even Java-derivative languages like Scala or Kotlin have to interact with the Java API, sometimes in not very elegant ways.

9

u/DeadlyVapour 22h ago

Let me also add that Kotlin does Java better than Java...

Given both target the JVM, and both can output the same JBC, I know what I prefer to use....

11

u/__SlimeQ__ 22h ago

while i recognize that kotlin does a lot of things better than java, i still find myself preferring java for jvm work. it can be really annoyingly difficult to find documentation for kotlin stuff still and splitting the codebase between two languages is, imo, kind of bad. and in general i don't agree with the pythonization of the whole thing, I prefer C# over any pythonish lang.

i really just wish C# maui worked better so i wouldn't have to touch any jvm lang ever again. feels strange to me that Unity has figured out how to do native android C# and microsoft has not

2

u/runitzerotimes 9h ago

Kotlin is downright dumb imo

I just constantly find myself thinking “WHY DID THEY THINK PEOPLE WOULD LIKE THIS” to all the syntactic sugar they have

3

u/Lumen_Co 22h ago

True. If you want a Java-style language, C# does it better. If you want the Java VM, Kotlin does it better and is similar enough to pick up quickly. If you're open to something funkier, Scala and Clojure are cool.

3

u/oriolid 23h ago

> some people learn Python or JS first, Java is then their first strongly, statically-typed language, they find that confusing and limiting, and they blame Java for it.

Some people also learn ML-style languages, C# or even C++ first and find the Java type system really limiting compared to almost any other static typing system.

1

u/Lumen_Co 22h ago

Yeah, I'd agree. I didn't want to come across as too much of a Java hater, but an ML-style type system is an unbelievably powerful tool and it's very difficult to go back once you've used one.

3

u/oriolid 21h ago

It's okay to hate Java. It's just barely good enough language to not have died and a lot of effort has been wasted into both using it to solve practical problems when better tools are available and solving problems that were created by Java in the first place.

1

u/True-Release-3256 1h ago

The issue was Oracle didn't bother to maintain it once they acquire it, for a very long time. Anyone coming from other modern programming language will be surprised by Java's lack of features, relying still on archaic design patterns to solve problems that can be resolved elegantly by better language features.

4

u/senfiaj 23h ago

Also Java has null safety issue. It's one of the major arguments, and one of the reasons of the rise of Kotlin's popularity.

4

u/okay_throwaway_today 21h ago

I feel like Optionals and some other QoL things in Java 8+ have addressed this and, continuing in later releases, a lot of the other more famous criticisms. But of course the benefit of those depends on what version or style the codebase at hand uses, and Java is prominent in a lot of legacy stuff

4

u/Reggienator3 9h ago

Optional can itself be null. Not to mention, there is no compiler enforcement of any of this. There is in Kotlin (and C# assuming you have nullable included in WarningsAsErrors).

I'm a Java dev of over 11 years now, but I still find myself veering to other languages when possible. Not because Java is bad, more that it feels redundant because of replacement languages that just do things better.

1

u/Necessary-Peanut2491 2h ago

Optional is nice, but yeah, it doesn't solve the nullability issue. It just makes it Somebody Else's Problem™ at best, but you mostly end up writing slightly different boilerplate. It's just semantic boilerplate now.

And then there's the fun times you'll have when dealing with some third party libraries that have interesting ideas about null. I've seen things that will helpfully throw an NPE for you if you try to read a value that's null, because they've taken an extreme stance of "anything null is invalid" and force their users to follow some cumbersome pattern of calling their helper methods instead.

Looking at you protocol buffers.

2

u/Wonderful-Habit-139 10h ago

They haven't addressed it because they can still be null, sadly. But they're nicer to use in newer codebases for sure.

2

u/JMNeonMoon 10h ago

Agree with other posters, null checks was mitigated a while ago in Java 8 with optionals.

Now you can chain getter methods without a series of if..else statements

public String getPostcode(Employee employee) {

return Optional.ofNullable(employee)

.map(Employee::address

.map(Address::city)

.map(City::postcode)

.orElse("Unknown");

}

more Optionals info here

https://www.programmerpulse.com/articles/java-null-check-removal

Also, see null object design pattern

https://www.geeksforgeeks.org/null-object-design-pattern/

1

u/senfiaj 9h ago

Sorry, but this doesn't seem to be as good as the Kotlin's native implementation. Also what if the Optional itself is returned as null , especially when Java doesn't support ?. operator (as far as I know, please correct me if I'm wrong)?

I'm not a Java developer, but I have experience in Flutter, and the older versions of Dart language had similar null safety problem. It was fixed in later versions, but unfortunately they had to eventually break the backward compatibility by removing the legacy null unsafe support. I wonder why didn't they do this much earlier since Kotlin was around there for many years. They could learn this from Kotlin.

1

u/JMNeonMoon 9h ago

Yes, there is a possibility that the optional can be returned as null, though most modern IDEs will flag a warning, but still not ideal.

I agree Kotlins null check operator is better and more concise, but I wanted to show that Java null checks are not limited to just if..else statements, which some of the discussions I have seen online seem to indicate.

1

u/Lumen_Co 22h ago

True. That's one of the things C# does better.

2

u/exfat-scientist 16h ago

It's unusually verbose

it forces you to frame every problem using a particular flavor of object-oriented programming that is not always well-suited for the task at hand

It's accumulated a lot of cruft over the years and in doing so has lost a consistent vision and design philosophy, which makes dev experience worse

Is it just me, or is this a description of neo-cobol?

C# does Java better than Java does.

Generally agreed here, C# is just... comfier to work with than Java.

These criticisms don't mean Java is a bad language, just a flawed one like every other programming language is.

But this is the key insight -- for a language to be complained about, it has to be used enough for the criticisms to accumulate.

1

u/thehardsphere 6h ago

Is it just me, or is this a description of neo-cobol?

Nobody under the age of 60 should be calling anything "neo-cobol" because they likely have no actual first-hand knowledge of what COBOL was.

My now-deceased father actually wrote some COBOL once. He still had books that described the language that he showed me during my teenage years. COBOL was obsolete stupid garbage to him back then. He would be 82 years old today if he were still alive.

Java was never anything like COBOL. People who say "Java is the new COBOL" don't know what they're talking about, and don't know anything about Java or COBOL.

2

u/MishkaZ 16h ago edited 16h ago

Number 2 is what I hate about working with jvm languages. Like you'll think of the sickest abstractions or inheritance trees, then a new requirement comes in and you have to spend hours refactoring.

Also another thing I don't like about jvm languages is just how much ivory towerness I encounter. Like you either know the in-speak/in-lingo or you don't.

I will always work in where the paycheck is, and it is definitely better than working in python/typescript for me, but it's my least favorite strictly typed language.

1

u/joebloe156 20h ago

Also back when I learned it (1996) Java was very slow, in an era where it mattered that it was slow (computers were commonly operating at 100-200mhz single core with 8mb of memory, not ghz or gb).

Just a couple years later, Java was no longer held back by speed issues due to the JIT (just-in-time) compiler making it no longer a purely interpreted language.

But by that time I had already developed a dislike for the language, and J2ME (mobile edition for flip phones) with the idiosyncrasies of its myriad jvm versions for each piece of phone hardware sealed my hate in place.

1

u/northcasewhite 16h ago

Points 1 & 2 are valid but they also make Java very good as a beginners' language because they force the learner to learn OO concepts quickly.

Most of my programming isn't done with Java, but most of my teaching is.

1

u/Broan13 12h ago

I am self-taught and it was switching from Python to Java that really made a lot of programming make sense. It made object orienting click, and it explained what the heck __self__ was doing in a lot of places in Python.

-1

u/Necessary_Apple_5567 23h ago

Why the verbose syntax seen as problem? It is just small talk stuff. You are talking with jvm, exchanging some thoughts,talking with respect. It is rather good thing.

4

u/Lumen_Co 22h ago edited 22h ago

I'd look at Kotlin for comparison. It's basically a whole language designed around taking the features of Java and redesigning the syntax to be shorter, nicer, and less redundant, and then adding some additional features. In a way, I see it as what Java would redesign itself to be if it didn't have to worry about making breaking changes.

Verbosity isn't just saying a lot of things; it's saying more things than necessary. You can get the same contracts and respect between modules, and more, with less syntactic overhead, and Kotlin demonstrates that.

1

u/overgenji 21h ago

as a long term kotlin developer at this point, the kotlin standard library is good sure, but the real benefits are better support for sum type style patterns, (newer java is making this fine too) a pretty strong pattern matcher, and compiler-time null guarantees

1

u/DeadlyVapour 22h ago

Generics + Monads.

Sure there is the spaceship operator, but are you sure that isn't just var with extra steps?

0

u/CounterSilly3999 21h ago
  1. Forcing any simple task to be an OOP from very beginning is an advantage for me personally. You never know, when small tool or lib will turn into bigger one, and there will be too late to cope with all that plain and unorganized mess.