How to Become a Java Specialist: Lessons in Concurrency and Performance
Becoming a real specialist in Java isn’t just about knowing the syntax. It’s about understanding performance, concurrency, and the data structures that can make or break your application when it scales.
We had a fascinating conversation with the legendary Dr. Heinz Kabutz, a Java Champion and creator of The Java Specialists’ Newsletter. He shared some unique stories and deep technical insights. This post breaks down his most important lessons on concurrency, performance, and the mindset of an expert.
Why Stories Matter in Tech #
Before diving into the technical details, Heinz shared some wisdom about communication. He has been starting his newsletters with personal stories, and it’s what his readers love most.:
I’ve been writing my newsletter for 25 years, and the thing people always come back to is that they love stories. People love stories because we’re humans and humans love stories. So yes, for me that’s really, really important
Lesson for you: Don’t just dump facts. Wrap your technical lessons in stories or analogies. People will remember the experience, not the code.
Find Your Unique Style #
It can be tempting to copy other people. But just copying what someone does isn’t good. You need to understand who they are and develop your own unique style.
Heinz shared this insight about his friend and fellow Java Champion, Bruno Souza:
You really need to discover your personal style, your personal trademark … The thing which makes Bruno special isn’t what he does because anybody can do what he does. What makes him special is who he is. His personality is so warm. He’s so kind. He’s always doing nice things for people. And that’s what makes him special.
So, find your style. Maybe you’re the developer who uses funny visuals, or the one who explains with real-world analogies. But it should be yours, not a borrowed act.
Consistency and Persistence: Writing for 24+ Years #
When asked how he kept up writing his newsletter monthly for over 24 years, Heinz said consistency often came from small mental tricks:
The way I see it is — ‘I’m paying for my newsletter service monthly, so if I don’t write it, then I’m like paying for nothing.’ I know that doesn’t really make sense, but…you trick yourself into doing it. Sometimes I write them very quickly and other times it takes me days and days of research to write them so it really depends. The funny thing is I never know which one’s going to be good or which one people are going to like.
The lesson: Don’t wait for “perfect inspiration.” Build little systems or tricks that push you to deliver regularly.
Passion for the Audience #
A listener asked about the role of passion in giving a great technical talk. Is being passionate about your topic the most important thing? Heinz had a surprising answer.
I’ve seen very passionate people who are very passionate. Very passionate. And no one has a clue what they’re talking about because they’re so passionate about their thing.
Instead of passion for the topic, Heinz believes the key is passion for the audience. It’s about connecting with them and trying to understand their perspective.
When I do a course or a talk, I go in there and my starting place is I love my audience. My starting place is that the people in my class, every single one of them, is actually smarter than me. I love them because they are here to pay my bills. They’re paying me to do something I actually enjoy doing…I want to answer their question before they even ask the question.
Architecture vs. Programming Language: What Really Matters? #
A question came from the audience: is choosing a good architecture or concurrency strategy more important than the programming language?
Heinz re-framed the question and his perspective was direct:
The programming language doesn’t matter that much. What matters are the people. Good engineers will build an amazing system with Visual Basic. And if you have terrible people, they’ll build a terrible system with Java.
This is an important reminder for all of us: don’t get lost in language wars. Focus on problem-solving, algorithms, data, and teamwork.
Live Coding: ArrayList vs. LinkedList Performance #
One of the best segments was Heinz live-coding a performance experiment:
- He created a large
ArrayListand the program repeatedly removed the middle element until the list was empty. - Then he tried the same with
LinkedList. Most people expect LinkedList to be faster. But it turned out much slower.
Why? Because before removing the middle element of a LinkedList, you first have to go and find the middle position.
Most people think LinkedList is faster. But in reality, removing from the middle of an ArrayList is usually faster, because bulk array copies are quicker than pointer chasing.
This is very basic computer science 101 and it’s extremely uncommon knowledge.
The lesson: It is very important to know data structures and understanding how things connect and what the implications are for memory access.
Bugs in the JDK: A Very, Very, Very Large Test #
Heinz shared another wild discovery. What happens if you try to create a LinkedBlockingDeque with more elements than Integer.MAX_VALUE?
- In the experiment it produced wrong results (size as a negative number).
- This bug had existed for years until he reported and fixed it, it is now part of the upcoming Java 26 release.
During the demo, Heinz ran the same massive memory allocation test using different garbage collectors, the default and ZGC. It turned out that you have to take care of what GC you use for which kind of problem.
Another interesting thing he stated: In Java, when you start off your virtual machine, if you have less than 32 GB of memory then it uses CompressedOops. So each object uses less memory in space. But if you have more than 32 GB then each object uses more memory. So when we make an extremely large collection or if we make a LinkedBlockingDeque with all these elements inside then it’s going to make a LinkedList of those objects and these objects will take more memory once you exceed 32 GB. So it’s like if you just below 32 GB, you actually use a lot less memory for the same amount of objects than if you go over 32 gigabytes.
This example also featured in Heinz’ JavaSpecialists Issue 328
Structured Concurrency: Why It Matters #
Another audience question was how structured concurrency impacts readability. Heinz’ answer was crystal clear:
Using
CompletableFuture, you’re basically building up an abstract syntax tree by hand…Structured concurrency makes it much easier to write complex workflows.
So if you’re getting serious about concurrency in Java, structured concurrency and virtual threads (from Project Loom) are game-changers.
The Role of AI in Programming #
A thought-provoking moment came when Heinz compared programmers using AI to doctors using it for diagnostics. An AI can give you a convincing answer, but it might be completely wrong. A specialist — whether a doctor or a developer — has the deep knowledge and experience to ask the right questions, validate the answer, and understand the context.
In medicine, doctors are not allowed to consult chatGPT about medical issues… it’s unethical. …It should be considered unethical for programmers to write production code with chatGPT…
AI might get it right, or it might get it horribly wrong, like really, really badly wrong
Final Thoughts #
True expertise comes from understanding how things work under the hood. Becoming a Java specialist is about developing curiosity, testing assumptions, and pushing systems where others don’t. Heinz reminded us that deep knowledge often comes from asking uncomfortable questions and building experiments.
YouTube link to the original OotBD session
More insights in this short video from JCrete: