Hello World 👋

So the other day I started using Jujutsu … for the moment “just” with two repositories at work. But willing to learn and potentially ramp up usage. This is after Daniel Danner was “advertising” it on last year’s Seneca Camp in Erlangen. Motivation Reason for trying it out is that I want to benefit from Jujutsu megamerges and the jj absorb feature. So at work I’m currently working on a single long-running project, and most of the time working alone on some feature branches in parallel....

So this applies to all coding agents, but I’m just exercising it with aider here. TBH I even trust aider pretty much and have more concerns with other beasts like Codename Goose, Claude Code, PI and others … … so in order to constrain those tools I first went with Docker … which felt like a natural choice. Especially since I’m pretty fluent with it … which I unfortunately still cannot say is true regarding systemd....

In Camunda Service Tasks can be implemented using so-called delegate expressions, which, in the context of CDI, resolve to @Named annotated beans. This task class has to implement the JavaDelegate interface, which mandates a method named execute, which receives a single argument with a DelegateExecution instance. However there is the Dependency Inversion Principle (DIP), and this way our business code directly depends on two classes from Camunda. Can’t we do better?...

A few weeks ago, I came across Harper Reed’s blog post, My LLM codegen workflow atm, which made the rounds in the developer community. While his approach to using a LLM to collect and refine requirements was interesting, … what really caught my attention was him mentioning, that he uses Aider to let LLMs modify his code. So what is Aider? Simply put, Aider is a CLI tool that isn’t tied to a specific LLM....

Today I learned, that IntelliJ has support for Wayland Compositor since version 2024.2, so seems like im rather late to the game. Simply go to Help > Edit custom VM options and add -Dawt.toolkit.name=WLToolkit. For me it so far works nicely. And the issue of some overlay windows (like object inspector) not being resizable in Sway … are just gone. Yay 🥳

Recently I learned, that it’s possible to script IntelliJ. I picked up on it while Writing an IntelliJ Plugin for my Coverage Tracker project, aka “Undercovered”. So there is the IDE scripting console, which comes out-of-the-box. You just open the Action panel and search for IDE Scripting Console, next a tiny popup menu should show, asking for whether it should be Groovy or Kotlin (beta). Right away you can enter some code and evaluate it by pressing Control + Return....

In a way, this is the last part of my journey creating a Java (Line) Coverage Analyzer. This article concentrates on creating an IntelliJ plugin, that adapts it to show the results collected by the analyzer created in Let’s create a Coverage Analyzer, Part 4. To get started, check out JetBrains’ Developing a Plugin article. With recent IntelliJ versions you need to install the Plugin DevKit first, then create a new Project and select the IDE Plugin Generator....

This is part four of my journey creating a Java (Line) Coverage Analyzer. This time around we’ll test the implementation created in part three and look into details what still goes wrong. One (simplified) example that crashes the current analyzer implementation is this one: public class Demo3 { public static void main(final String[] argv) { final Stuff stuff = new Stuff( !getBoolean()); bla("value: " + stuff.boolValue()); } public static boolean getBoolean() { return true; } private static void bla(final String greeting) { System....

This is part three of my journey creating a Java (Line) Coverage Analyzer. This time around we’ll look into improving the very naive implementation created in part two. That one ended in a VerifyError and the message Expecting a stackmap frame at branch target 41 So what is this branch target, and the stackmap frame that it’s suddenly missing? To have an easier time inspecting the Byte Code, let’s first create a little CLI version of our instrumentation code....

This is part two of my journey creating a Java (Line) Coverage Analyzer. Here we’ll actually implement the Byte Code Instrumentation, as pointed out in the first part. Since processing the Byte Code itself, i.e. reading the classes, finding the methods, processing line number information, is in itself a huge task, let’s rely on the ASM library for that. After all JaCoCo and Cobertura also rely on that, so this seems to be a valid choice 😂...