Building distributed applications or microservice applications brings a whole new range of problems. All those application components, or microservices, need to communicate with each other. How will we do that: using messaging, or would direct HTTP calls be a better choice? Often, we must make such decisions early in a project. Since it’s hard to change it later, we call it an “architectural decision”. But this is often an excuse so we can blame the architect if the choice turned out to be wrong.
This site started as a list of personal notes, interesting findings or whatsoever. Over time, I’m adding content that more looks like a regular blog. Either way, I hope you’ll find it useful. If so, drop me a line, I’d love to hear it! Feel free to get in touch; for options, see the right pane.
Following the recent kerfuffle around the security manager deprecation, I was curious to see if a codebase I’m working on would also suffer. But how could I find out? There are no early access builds of Java 17 yet with the latest changes for this JEP. Maybe… I should set out and try to build it myself? But that’s sure going to be a lot of work… Or is it?
Java evolves at a much faster pace than it used to do. But not all of the projects we work on keep up with that pace. I have projects on Java 8, 11 and 15 - and sometimes I want to play with early access builds of newer versions as well. How to make sure I can build them without having to constantly switch Java runtimes?
During my work on Maven today, I found a very specific bug.
The error message wasn’t that clear, and I couldn’t make a guess what might’ve caused it.
I read about
git bisect a few times and figured that today, I would use that tool to find the bug.
Recently, the Maven community decided to push forward and start working towards a 4.0.0 release. The first question after this announcement is of course: what can we expect Maven 4 to bring us? A lot - and in this post, we want to highlight some of the features that we are particularly excited about.