Posts

This week, I’m attending the 19th edition of the Devnexus conference in Atlanta! In those 19 years, Devnexus has truly grown to being one of the biggest Java and JVM-related conference in Nothern America, and it’s always been a pleasure to be there. This year marks my fourth attendance as a speaker, and I’ll be doing two talks myself.

In this post, I’ll be live blogging about some of the sessions that I’ve joined. Enjoy!

Last week, I attended JavaZone, the annual conference ran by javaBin, the Norwegian Java User Group. I have attended JavaZone in the past (2018) so I knew what to expect - and the bar was high! Because of that, I was looking forward a lot to join JavaZone again. Also, this would be my first conference as a Java Champion, which made it even more special.

A quick note, this time. Recently, I wanted to do some hacking around on Jakarta EE and MicroProfile. I chose to work with the OpenLiberty runtime, as I previously had good experiences with it. My pet project also needs a database, so for starters, I chose HyperSQL Database (HSQL DB). Here’s how I set it up.

Earlier, I wrote about integrating PIT with the Stryker Mutator Dashboard. The setup for that was pretty complicated, with some shell scripting that extracted the JSON payload for the report from a JavaScript file. Today, I’m introducing a much simpler approach to that: the Stryker Mutator Dashboard reporter for PIT.

If there’s one topic that has kept the Java community excited over the last years, it’s Project Loom. We all know it’s coming someday, but when? What will it look like? And how will it change the way we write concurrent code? In this blog, I’ll try to play a bit with what Loom currently looks like.

It’s been a while since the first two posts about Dapr! In those first installments, we looked at the basics of Dapr, from a very conceptual point of view. We also looked at the bare minimum HTTP API that Dapr exposes to the applications that use it. But writing enterprise applications that way would be slow, and it would inevitably lead to mistakes. In this article, I will introduce you to a higher abstraction level of working with Dapr.

Earlier this month, I introduced you to Dapr, the Distributed Application Runtime. That was a mostly conceptual introduction, showing you how Dapr works and what it can do for you. But how do you integrate it into an existing application? That’s the topic for today.

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.

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?