Why is Java code almost always notably harder to u...

# getting-started

[LastExceed]

Why is Java code almost always notably harder to understand that Kotlin code?
Whenever i look up code online (be it stackoverflow or a github repo) i am happy with the kotlin examples most of the time but always find myself heavily refactoring converted java samples. I know Java is very verbose by design, but even when using IntelliJ to convert the Java code to Kotlin I often find myself doing heavy refactoring. Everything is needlessly wrapped twice or thrice and the exception handling is completely overkill. is it convention in java to always write code that is very verbose not only syntax wise (which luckily the converter can get rid of) but also structure wise?

example: I am currently looking into software testing and came accross assertions. Let's compare the implementations of assert() from the kotlin stdlib and assertEquals() from junit. the former is basically implemented as

if (!condition)
    throw Exception(message)

its as simple and intuitive as can be. meanwhile the implementation of the latter goes so far down the rabbit hole (I have to navigate through 4 different files for what is actually just 5 lines of code) that I'd have trouble understanding what the function even does if it wasn't for the descriptive name. And this isn't just some random snippet from a stranger on the internet, its one of the most popular testing frameworks out there.

just why??

Edit: I don't just mean to vent, I mean this as an actual question. Why is this? There's gotta be a reason for it

[Mike]

Your specific example isn't comparing like things. You'd have to compare assert() to assertTrue(). assertEquals is attempting to handle the object type correctly, so if it's a List, compare elements. if it's a Map, compare items etc.

A lot of Java examples are likely 'old', too, and still using Java 8. Java 14 has come along nicely, and supports more of what Kotlin allows.

And some of it depends on what you work with most. What we know is always more comfortable than what we don't know or use as often.

People coming from Java to Kotlin often find the use of stdlib functions confusing, and can't understand why their favourite feature from Java isn't present in Kotlin (ternary, static), rather than understanding the idiomatic way.

HTH a bit. JDK8+ really helped reduce the differences, but overall, Kotlin is definitely cleaner. If it wasn't, then JB wouldn't have bothered, as that was one major motivation for them.

[alex]

your example is not really valid, because it's a framework, and framework can abstract a lot, and hide the real logic behind delegates, proxies, another delegate etc etc.
Complex system is complex, no matter what language.

When speaking about Java, you must understand that it's a language with big legacy. Some library code can be Java 5 level, and noone will refactor this, because it works and it makes no sense to refactor for the sake of refactoring.
Java 8 and newer is covering 90% of ugly-code situations (lambdas, functional interfaces, type inference, stream API). You can narrow down other 5% with different addons (like lombok or autovalue, nullable annotations + spotbugs or checker framework), so the real difference with Kotlin comes down to compiler features, like nullable types, smart casting and coroutines. Though Java will receive it in some way later for sure.

[Mike]

About the only one I don't see Java getting anytime soon, if ever, is the nullable types. But I'm happy to be proven wrong 😉

You just have to be patient for the Java features, and be able to upgrade your Java wherever you are.

[alex]

There is a talk to finally standardize java's nullable annotation (and probably some others), but there is no any ETA

[alex]

so, another decade or two maybe 😉

[Mike]

And unless they drastically improve the compiler to do the level of checks Kotlin does, it won't be the same. I wrote some code in Java, being as careful as possible to ensure I flagged things Nullability appropriately.

Converted it to Kotlin, and the compiler found a number of cases where I'd done it wrong...