Nicolas Fränkel

Two weeks ago, I started a completely new position at a new company: I’m now Developer Advocate (or to be more accurate, Developer Relationships Manager) at a company called Exoscale that offers Cloud Computing resources. There’s nothing technical this week, but a lot about me. You’re welcome to skip if that’s not your cup of tea. Or read on if you’d like to know more about me.

This is the 4th post in the JVM Security focus series. In one of my previous posts, I described how to create a custom policy file for one’s application. The process was manual and incremental. Because of that, it was painstakingly long, and hence not really useful. Since I wrote the post, I found a way to write the policy file under in a couple of hours, instead of days.

Java 8 introduced default methods in interfaces. This post describes what they are, and how they can change the design of APIs. A nominal design Earlier, in Java, interfaces could only have contracts - method signatures with no implementation. In order to add some implementation, a class was required, whether abstract or not. Hence, traditional API design then followed this hierarchy: The root interface defines the contractAn intermediate class implements common behavior i.e. BarIf

After years of near-ubiquitous usage of Dependency Injection, I see more and more posts and talks questioning its value. Some even go to the point where they argue against it. Most of it however is based on a whole lot of misconceptions, half-truths and blatant lies. In this post, I’d like to go back to the roots of DI, describe some related features and lists available frameworks.

Recently, I had some some fun writing functional Kotlin to solve the FizzBuzz test. I asked for some feedback, and one of the answer I received was in Clojure: In Clojure there's the classic way, with condp and mod. There's also another way using cycle that I saw some years ago. The range and the 2 cycles will generate the fizz & buzz, the rest just decides what to print.Will be easier for you with syntax highlighting -> screenshots pic.twitter.com/wOPJD0BpGM— Alexandre Gris

In one of my recent courses, we talked about Java 5 annotations. I told my students that before that time, one had to use marker interface instead: an interface without any method. Then, I showed the Serializable interface as an example. I started to explain it, then realized I would need a lot of time to fully cover it. This post is an attempt at that. Serialization is the process of transforming an existing in-memory Java object to a stream of bytes. That stream can then be transferred over t

If you’re developing with Spring Boot, IntelliJ IDEA does offer a lot of niceties to speed up development. Let’s browse through some of them.

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.