A Java geek

This is the 6th post in the The state of JVM desktop frameworks focus series.

This is the 5th post in the The state of JVM desktop frameworks focus series. The previous posts of this series were dedicated to frameworks that were pretty similar to each other. This week’s post is dedicated to Jet Compose for Desktop, the new kid on the block that offers an original approach.

This is the 4th post in the The state of JVM desktop frameworks focus series. The two previous posts of this series were respectively dedicated to Swing and SWT. This post is dedicated to Tornado FX, which itself is built on JavaFX.

This is the 3rd post in the The state of JVM desktop frameworks focus series. This series is dedicated to the state of JVM desktop frameworks. After having had a look at Swing the previous week, this post focuses on the Standard Widget Toolkit. SWT originates from the Eclipse project, an IDE. For Eclipse, the developers built a dedicated framework to build their graphic components upon. Swing implements the drawing of widgets in Java from scratch. On the opposite, SWT is a thin wrapper API that r

This is the 2nd post in the The state of JVM desktop frameworks focus series. In the first post of this series, we went through the rise and fall of some of the desktop frameworks, mainly Java ones. This post and the following will each focus on a single JVM framework. To compare between them, a baseline is in order. Thus, we will develop the same application using different frameworks.

When your application goes beyond a dozen of lines of code, you should probably split the code into multiple classes. At this point, the question is how to distribute them. In Java, the classical format is the Java ARchive, better known as the JAR. But real-world applications probably depend on other JARs. This post aims to describe ways to create self-contained executable JARs, also known as uber-JARs or fat JARs. What is an executable JAR? A JAR is just a collection of class files. To be

This is the 1st post in the The state of JVM desktop frameworks focus series. I’m interested in GUI applications since I’ve starting coding. Building a back-end app that manages teraflops of operations is an impressive engineering feat. But the feedback cycle when developing a desktop app is much shorter. That makes it, at least for me, much more motivating. This is even truer for side-projects.

If you like cool stories about how an engineer, faced with an impossible problem, overcame all odds and solved it, this post is not for you. This is a story of how I spent a non-trivial amount of time, how I hit a couple of walls, and how I nearly came back to square one. Why do I write it? The first reason is for me: I want to document my journey so if I ever think about trying again in the future, I’ll have some arguments against it. Second, in opposition to the actual zeitgeist, you le

Last week, I wrote a post that described how to hack the Maven dependency resolution system. I admit it was a dirty hack, it’s even in the post name. But I got it wrong. Thanks Stéphane Nicoll for pointing it out: "It boils down to excluding the spring-boot-starter-logging in every Spring Boot starter"Since you've put every in bold, I assume you meant it. That's actually wrong and not what the documentation states.Here is an example: https://t.co/JKgPXCh0Nb— Stéph

Logging is one of the fundamental components of any application which runs in production. Yet, between performance and logging in critical environments, I’d favor the former. For that reason, modern logging frameworks should implement at least two requirements: Async appenders: the write operation shouldn’t be blocking the execution of the programLazy computation: the framework doesn’t run expensive computations until they are needed - or never if that’s the case. The fi