Nicolas Fränkel

I’ve been following GraalVM with a lot of interest. One of the interesting areas is its ability to compile bytecode Ahead-Of-Time, and create a native image. Such images have a lot of advantages, including small size, no dependency on a JRE, etc. However, AOT has some limitations. In particular, the native image executable cannot compile what it doesn’t know about. This post aims to describe how to configure the compilation process when code is using reflection. Let’s start

Last week, I wrote on how to migrate an existing Spring Boot application with a functional approach toward configuration. Since then, I got interesting feedback, and I had a presentation on that subject at Rockstar Night in Kiev, which made me think further. Here’s how I would refine my previous code.

In the latest years, there has been some push-back against frameworks, and more specifically annotations: some call it magic, and claim it’s hard to understand the flow of the application. It’s IMHO part of a developer’s job to know about some main frameworks. But it’s hard to argue in favor of annotations when there are more annotations than actual code.

It seems pretty popular right now to bash widespread software design practices, e.g. dependency injection, frameworks, annotations, etc. While there are some downsides of adopting those practices, I believe there are more benefits. In that post, I’d like to address those points, and come up with arguments in favor.

I’m not a regular StackOverflow user, neither as a contributor, nor to ask questions. However, I recently stumbled upon a question, tried to help…​ and failed. I was pointed out my answer was wrong - thanks for everyone who did. I think failures are great occasions to learn something new! In this post, I’d like to detail what I learned after digging further: there are several ways to combine elements from an existing collection in Kotlin stdlib.

Distributing Java webapps via Docker is pretty widespread. However, regarding replacing desktop applications, it suffers from a not-so-great integration with the user’s desktop. On OSX, a quite popular distribution channel is Homebrew. Let’s dedicate this post to check how to distribute our desktop webapp via Homebrew.

Two weeks ago, we studied how to replace desktop Java apps with Java webapps. Now is the time to think about distributing such desktop webapps. The current trend now is to use Docker. I assume readers are at least familiar with the technology. The most straightforward way is to create a WAR and deliver it inside a Tomcat image. Another option is to create a fat JAR with Tomcat embedded as per the previous post, and run it inside a image with the JRE only. One of the deciding factors is the si

One of my first talk at an international conference was about cargo cult in the Java world. The story behind cargo cult is quite interesting: indigenous peoples were living their life on some islands in the Pacific Ocean. During World War II, both Japanese and American forces happened to come to those islands which were important to their respective military supply chain. Both sides did what every armed force in the world does to achieve their goal: they brought soldiers, constructed airplane r

Though I fancy myself a backend developer, I love the frontend. It’s always magic to visualize what you coded. Believe it or not, 15 years ago, I wrote JavaScript to dynamically add rows to an HTML table for Internet Explorer 5.5. That was called Dynamic HTML. But I was still a Java developer at heart.

I admit the title is a bit provocative. Of course, you need to push your changes. I should probably have renamed it Don’t just git push, or Don’t simply git push. But I’m sucker for clickbait titles. My point is, you should never ever type: git push This begets the question, why? Answering this question is the subjet of this post.