Project Valhalla seems to be on the verge of being incorporated into the JVM…​ as a preview feature in JDK 28 that is. This blog might be a bit premature, since it isn’t likely value types will be final in JDK 29. Premature, yes, but the JEP is already worth a careful read. I stumbled upon some interesting behavioral changes regarding equality.

Over the last few years, the software industry has been in the grasp of an all-overshadowing discussion on the use of AI and LLMs. What started as a fun experiment with ChatGPT showing this “intelligence” was sometimes capable of writing somewhat coherent compiling code has quickly grown into a plethora of LLMs, AIs, IDE plugins and tools built upon AIs influencing (or taking over) every aspect of software development.

While the discussions do address the value and shortcomings of the tools I find myself pondering the effect this will have on our profession more.

Simon Brown’s C4 Model for architecting your software solutions provides a clean and structured way of modeling software. Structurizr is not a new tool, but with some new "Solution Architecture" responsibilities flowing my way I was looking for a way to create maintainable models. I found Structurizr extremely useful for creating easy to maintain models to use and change(!) during discussions with architects and developers alike.

Some time ago I went to a Meetup session “Death To Null” by Ties van de Ven from JDriven. During the presentation it became clear that it wasn‘t so much about null checks and NullPointerExceptions but more about Immutability and how it can help keep your software free of bugs and NullPointerExceptions. One of the statements that got me thinking was (something along the lines of): “Java chose the wrong default. Instead of making everything explicitly final when we want an immutable variable, everything should be implicitly final unless the developer makes it explicitly mutable”. Not knowing that much about the implementation of annotations I thought it would be fun to try to write an annotation which would do exactly that. The first bump I encountered is that annotations cannot modify the programmers source code, or the classes generated from this source code; they can generate new sources or validate code. This quickly turned my attention to project Lombok which does that already. If you use project Lombok for the generation of getters and setters these never show up in your source code. How can your IDE still hint at the existence of the getters and setters?