DEV Community

Why you should NOT HATE Java!

Sahil Pabale on August 06, 2021

Everyone hates Java, even I did (once). The memes, the videos, I mean literally everywhere there is spread one thing - java's popularity is decli...

Read full post

Angius • Aug 7 '21

Question is: why use Java, if C# or Kotlin can do everything it does better and with less boilerplate?

Sergiy Yevtushenko • Aug 8 '21

Don't know about C#, but Kotlin is not an alternative to Java in enterprise setup.

Sahil Pabale • Aug 8 '21

You might be having some POV right? I would love to hear that!

Rudy Nappée • Aug 8 '21

Why ?

Sergiy Yevtushenko • Aug 9 '21

Kotlin requires extra efforts to keep codebase clean and organized: freedom in placing classes/functions across files tend to quickly turn codebase into blob of cold spaghetty. This is solved by defining and maintaining conventions - extra efforts mentioned above.
Extension methods blur class API and tend to spread across code base. As a consequence devs often repeat extension methods with very similar of identical functionality. This is also solved by defining and maintaining conventions - more extra efforts.
Kotlin requires keeping in mind much more implicit context while writing and reading the code - context-specific keywords, default variable names, etc. This impacts productivity in long living projects, especially when team changes.

There are more reasons, but even those listed above is enough to try to avoid Kotlin for enterprises.

Rudy Nappée • Aug 9 '21

Indeed great powers implies great responsibility... DSL and extension methods are valuable tools but should be used sparingly.

In Java because there is no extension methods and we can't define a function outside class, we must define a lot of util classes (*Util, plural classname) with their static import, I'm not sure it's better :/

IMO Kotlin offers interesting patterns to compensate some lacks in Java. But teams are free to define coding standard to avoid exotic code.

Sergiy Yevtushenko • Aug 9 '21 • Edited

I'd rather say that all these are signs of poorly though out and inconsistent language. One laughable example is that code written with infix methods often can be made non-compilable by adding one more line feed.
Another (significant) disadvantage is that Kotlin encourages developer to write hacky, hard to read and understand code. Optional chaining and elvis operator are especially easy to abuse.

Rudy Nappée • Aug 9 '21

I'm not sure

user?.address?.streetName ?: "No street"

is weirder than

Optional.ofNullable(user).map(User::getAddress).map(Address::getStreetName).orElse("No street")

But I'm sure it's shorter :)

About infix notation, I'm not a big fan in everyday code but it can be handy for DSL. Again, great powers...

Sergiy Yevtushenko • Aug 9 '21

Your code is shorted for two reasons:

It assumes that user has type String, although for fair comparison it should have type Optional<String>
You just stepping through object properties (BTW, your code might be a code smell, because it knows too much about User internals). If you try to actually compose operations, your code will not look so short.

You may try to rewrite code below with optional chaining:

public UserProfileResponse userProfileRequestHandler(User.Id userId) {
    User user = userService.findById(userId);
    if (user == null) {
        return UserProfileResponse.error(USER_NOT_FOUND);
    }

    UserProfileDetails details = userProfileService.findById(userId);

    if (details == null) {
        return UserProfileResponse.of(user, UserProfileDetails.defaultDetails());
    }

    return UserProfileResponse.of(user, details);
}

For comparison, monadic version of this code looks so:

public UserProfileResponse userProfileRequestHandler(User.Id userId) {
        return userService.findById(userId)
            .map(user -> UserProfileResponse.of(user, userProfileService.findById(userId)
                .orElseGet(UserProfileDetails::defaultDetails)))
            .orElseGet(() -> UserProfileResponse.error(USER_NOT_FOUND));
    }

Rudy Nappée • Aug 9 '21

Just assumed User/Address were kt data classes / java POJO but Indeed callee could've been returned a Optional

Rudy Nappée • Aug 7 '21

Because companies are chilly ? 😁

In mine just replacing Java with Kotlin (keeping same framework, same supervision tools, same IDE...) is quite complex 😔

Sergiy Yevtushenko • Aug 8 '21

And has no sense. Kotlin "features" make keeping code clean and maintainable much harder, than with Java.

Rudy Nappée • Aug 8 '21

Lol.... Not sure if you're trolling , but in my experience it's exactly the opposite. Less code lines, using ADTs, powerful pattern matching make your code so much expressive and safer.

Sergiy Yevtushenko • Aug 9 '21

See my comment above.

Sahil Pabale • Aug 7 '21

yeah it's bit hard though

Pham Duc Minh • Aug 8 '21

Simple, MS SQL and Window Server isn't free.
.Net Core may be mature now and it available on Linux
But migrate whole company infrastructure will not easy

pazvanti • Aug 6 '21

I've been a Java developer for the past 7 years. Was even a C/C++ dev for another 4 prior to that. Yes, Java is a bit "hated", but it has some really good features and it evolved a lot in the past years. I heard many arguments against Java, like "it is slow" or "it uses a lot of memory" and I don't find them all true. JIT speeds things up a lot and Java is capable or working with big quantities of data without a problem. In today's age, hardware is cheap, engineers are expensive. I would rather pay 50$ more per month for a bigger instance, than pay a few thousand to try and optimize the code so much or use a more efficient programming language but with features or libraries that are not so widely available.
There is a reason why many web apps run on Java or JVM-compatible languages (Spring, Spring boot, Play), even high-profile ones.

Sergiy Yevtushenko • Aug 8 '21

Spring and Hibernate are two main reasons why Java considered "memory hog" and "slow". Applications built without these frameworks usually fast and consume reasonable amounts of memory.

Sahil Pabale • Aug 6 '21

Yes it's just that many newbies are scared of those class names. Even i was but then i dived deep into learning Java and found it pretty amazing!

michelemauro • Aug 6 '21

Most of the reasons you cite:

are getting fixed in the recent releases (switch expressions, road to pattern matching, records)
are problems unrelated to the languages but derived from external conventions or specifications (not every object needs to be a JavaBean with all getters and setters; and nowadays, almost none)
can be solved with some specific projects (Quarkus will take your web application and make a native container that starts in 1/10th of the time and uses 1/10th of the memory)

More than that, there is no reason to hate almost any language: every language has its history, its ecosystem and its peculiarities. There is a problem only when you can't choose a language that is better suited to the job you have to do.

Moreover, Java has a very, very solid and high quality ecosystem, that is tamper-resistant by design: it is very, very hard to publish a java library that contains malicious code and getting away with it, because it is very difficoult to publish something on Maven Central without giving them a really good idea of who you are.

So, there are many jobs and use cases where Java is an excellent choice, and a pleasure to work with. And there are other options (Kotlin, Scala, Groovy) if you want to access the same ecosystem but want less OOP, more FP or simply less syntax.

Just keep on codin'!

Phantz • Aug 7 '21

Yeah, pretty much. Java has already realized that the world has moved on, and it has started to move on as well. The new features are so beautifully functional. It's great that Java is taking a few pages from the C# book. Though even with said features, I'd pick kotlin over java any day.

The problem, though, with any mainstream language, that is widely inferior but impressively improving, is adoption. The deed has already been done. The industry is mostly bound to the ugly chains of Java 8, and not many of them are going to upgrade.

michelemauro • Aug 7 '21

More recent surveys paint a slightly different picture: Snyk JVM Ecosystem Report 2021 Finds Increased Usage of Java 11 in Production.
It looks like 11 has already surpassed 8 in production. And everone is waiting for 17.
Maybe they are waiting more for the JVM than the language, but Java remains an approachable and solid solution for many use cases and many teams.

Sahil Pabale • Aug 6 '21

Yeah you are absolutely correct😊😊

Sergiy Yevtushenko • Aug 8 '21

Try functional style with Java and you will see how concise and expressive Java could be.