DEV Community

Cover image for Why you should NOT HATE Java!

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...
Collapse
 
angius profile image
Angius

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

Collapse
 
siy profile image
Sergiy Yevtushenko

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

Collapse
 
devdufutur profile image
Rudy Nappée

Why ?

Thread Thread
 
siy profile image
Sergiy Yevtushenko
  • 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.

Thread Thread
 
devdufutur profile image
Rudy Nappée

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.

Thread Thread
 
siy profile image
Sergiy Yevtushenko • 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.

Collapse
 
pazvanti profile image
pazvanti

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.

Collapse
 
sahilpabale profile image
Sahil Pabale ByteSlash

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!

Collapse
 
siy profile image
Sergiy Yevtushenko

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.

Collapse
 
michelemauro profile image
michelemauro

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'!

Collapse
 
totally_chase profile image
Phantz

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.

Collapse
 
michelemauro profile image
michelemauro

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.

Collapse
 
sahilpabale profile image
Sahil Pabale ByteSlash

Yeah you are absolutely correct😊😊

Collapse
 
siy profile image
Sergiy Yevtushenko

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