#24 A New Future for Java
Logging vs Memory. Immutability we can afford. Agility ≠ Speed. Data fallacies to avoid.
Welcome to the twenty-fourth edition!
You have to finish things - that's what you learn from, you learn by finishing things.
The ARM architecture is getting a lot of attention and Microsoft is putting resources to support it, and is offering a collaboration with Apple for its Apple Silicon.
A New Future for Java
Why is Java so widely used despite its “problems”? Probably because its problems as language are outweighed by its robustness as a platform.
In “A New Future for Java” the author expresses my ideas about Java (the language) and how the competence of new languages (mainly Kotlin and Scala) is driving the evolution of Java.
The Java Platform is getting better than ever (Valhalla, Loom, Graal), and the Language is also improving (Amber), but is far from other languages that don’t have the legacy and backward compatibility pressure than Java.
Given the limited resources Oracle is putting into Java, I think the balance they are making between platform and language is fine. If you miss something from Java, you can always use one of the other languages proposed in the article.
How hard would it be to decouple Java from the JVM and make it have independent life cycles like Scala and Kotlin?
Logging vs Memory
Everyone knows that logging is one of the key pillars in application operability (Logging, Monitoring, and Observability), and we populate our code with logs.
But the way you build those logs can greatly impact the performance of your application.
Will Sargent, as the creator of a logging utility for Scala, shares his experience in the performance of logging in: “Logging vs Memory”.
The article focuses on memory consumption and memory allocation pressure, giving a lot of references to multiple articles about it. He also gives advice on how to detect and avoid these problems using different tools available in the JVM ecosystem.
The article goes into some implementation details in logging utilities. But in your day-to-day life, you don’t need to go into this detail, and you should look into how you use it. The first thing I look for when I arrive to a new codebase are expressions like this:
log.trace(“Elements in collection: “ + list);
because each time you execute this line, even when the log level is not trace you are executing the list.toString()
method. Use the lazy version of the logger:
log.trace(“Elements in collection: {}“, list);
Immutability we can afford
Immutability is required when you work with shared state and concurrency, and it is recommended in non-concurrent code to avoid unexpected changes by third-party code.
Usually, immutability has not been adopted because its implementation has a cost we couldn’t afford: copying data constantly is expensive in time and resources.
In “Immutability we can afford“, Roman Elizarov reflects on the cost of immutability and whether we have already reached a point where its benefits outweigh its drawbacks.
The need to execute code concurrently and the existence of abstractions and memory friendly implementations are driving us to adopt immutability. For example, new Java Records are immutable.
If you want to learn how to build efficient immutable data structures, I recommend start reading about Persistent data structures, widely adopted by functional languages in the implementation of their collections libraries.
If you want your head to explode, start with this video from MIT:
The video is part of a Course from MIT and every single one of Erik Demaine classes are mind-blowing.
Agility ≠ Speed
An obsession with speed often overtakes the core values of agile software development. It's not just development of software; it's development of working software. Sprints are not about sprinting; they're about sustainable pace
As an anecdote, in my latest two jobs (Nextail and Clarity), I’ve applied some kind of Kaban (usually without a strict WIP restriction), and for me is the best way to provide a sustainable pace, not conditioned to artificial timeframes and forcing you to finish things.
These and more topics about Software Development are discussed in this talk by Kevlin Henney:
Data fallacies to avoid
Everyone says that is data-driven, but our mind is hackable and we can misinterpret the information if you don’t pay attention:
Here you have an introduction and related reading for each fallacy