DEV Community

loading...

Discussion on: Java is Dead - Long Live Java

Collapse
gklijs profile image
Gerard Klijs

It's funny you start with a ship analogy. In a discussion recently Java was the mammoth tanker, moving steadily, but slow. It has some advantages. Like with new features it can look at some of the other JVM languages and learn from it, to do it right the first time. These is some disadvantage to being backwards compatible. Like nullability which seems better in Kotlin. But if you make wrong assumption in nullability in Kotlin the whole program crashes. While in Java you can do the same, check at the borders, you do need a bit more disapline.

Collapse
stealthmusic profile image
Jan Wedel Author

Thanks for this comment, that was exactly my point.

Collapse
siy profile image
Sergiy Yevtushenko

Kotlin does one right thing: clearly separates nullable and non-nullable types and lets compiler do the rest. But same thing is possible in Java by using class like Option (Optional does not always does the job) to mark nullable values. There are more details about this approach in my article

Collapse
gklijs profile image
Gerard Klijs

Option could still be null. There are several annotations that could help with nullability but some work compile time and some runtime, it's easy to get it wrong.

Thread Thread
siy profile image
Sergiy Yevtushenko

Annotations are useless. And this is just a matter of properly handling of null values coming from external code and matter of habit to use Option where value can be nullable. There should be no cases when Option itself can be null. In fact this is extremely convenient to assume that all variables are not null and removes a lot of headache and mental load. But, well, convenient use of this approach is impossible without a significant doze of functional code. Which is good too, but, of course requires changes in habits and mental model.