As of September 16th, year of our lord 2025, this is no longer the first Java program you need to write.

public class Main {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        System.out.print("What is your name? ");
        String name = scanner.nextLine();
        System.out.println("Hello, " + name);
    }
}

This is.

void main() {
    var name = IO.readln("What is your name? ");
    IO.println("Hello, " + name);
}

Good Fucking Riddance.

I'll be nuanced later, we've all earned some catharsis now.

Holy fucking shit did this suck¹. There is a comments section below. Give your eulogy for that piece of shit sorcerous incantation there or wherever else.

new Scanner(System.in) and System.out.println too. Don't let your sense of dignity hold you back.

Just record yourself giving a guttural scream and post it. Sing a song, do a dance, cast aspersions.

Honestly just let it all out.

1: When I was a Freshman in High School I asked a Junior what it meant. He had no clue.

That Junior later went on to drop out of college and become a Minecraft Youtuber. I vividly remember him making videos where he and his girlfriend pretend to be toddlers in a Minecraft day-care. What a life.

<- Index

Named arguments are a language feature where you can provide arguments to a function call by name instead of positionally. This is usually paired with some mechanism to have default values that a caller does not need to specify

Take the definition of k_means from scikit-learn for example.

def k_means(
    X,
    n_clusters,
    *,
    sample_weight=None,
    init="k-means++",
    n_init="auto",
    max_iter=300,
    verbose=False,
    tol=1e-4,
    random_state=None,
    copy_x=True,
    algorithm="lloyd",
    return_n_iter=False,
):
    # ...

It takes two arguments positionally and then has a very large number of optional arguments which have default values.

If a caller wants to only change the max_iter parameter they do not need to specify the others

k_means(X, n_clusters, max_iter=10000)

Java does not (yet) have this or an equivalent as a language feature. Not only can you not specify parameters by name, you cannot get default values for said parameters easily

// This is unideal for multiple reasons
k_means(
    X,
    n_clusters,
    null,
    "k-means++",
    "auto",
    300,
    false,
    1e-4,
    null,
    true,
    "lloyd",
    false
);

There are many strategies for coping with this. The most notable is using the builder pattern to make an "input object".

var input = KMeansInput.builder(X, n_clusters).maxIter(10000).build(); 
var o = k_means(input);

This requires you to make both a class that holds all the input values in addition to an intermediate mutable class which holds all the same values.

public final class KMeansInput {
    private final Object X;
    private final int nClusters;
    private final Double sampleWeight;
    // ... Need to have all the data here
    
    private KMeansInput(Builder builder) {
        // copy from and potentially validate what is in the builder;
    }
    
    public static Builder builder(Object x, int nClusters) {
        return new Builder(x, nClusters);
    }
    
    public static final class Builder {
        private final Object X;
        private final int nClusters;
        private Double sampleWeight = null;
        // ... AND all the data here
        
        private Builder(Object x, int nClusters) {
            this.X = x;
            this.nClusters = nClusters;
        }
        
        // Then mutating methods
        public Builder sampleWeight(double sampleWeight) {
            this.sampleWeight = sampleWeight;
            return this;
        }
        
        // ...
        
        // and a build()
        public KMeansInput build() {
            return new KMeansInput(this);
        }
    }
}

And all of that is a non-trivial amount of boilerplate.

Of course you could just have a public class with all the fields exposed.

public class KMeansInput {
    public final Object X;
    public final int nClusters;
    public Double sampleWeight = null;
    // ...
    public int maxIter = 300;
    // ...

    public KMeansInput(Object x, int nClusters) {
        this.X = x;
        this.nClusters = nClusters;
    }
}

Since setting a field value puts the name of that field on the page, this also works as an approximation of named arguments.

var input = new KMeansInput(X, n_clusters);
input.maxIter = 10000; 
var o = k_means(input);

But there are two major downsides here. One is that you have a mutable object now and those are hard to reason about. You don't really know if k_means will mutate its "input object" or not.

var input = new KMeansInput(X, n_clusters);
input.maxIter = 10000; 
// All is well for the first call
var o1 = k_means(input);
// But this second call is dodgey
var o2 = k_means(input);

The other is the classic "there is no way to evolve a call to a field in a binary compatible way" issue.

If you wanted to make sure maxIter is never negative but still want a mutable aggregate, here come the getters and setters.

var input = new KMeansInput(X, n_clusters);
input.setMaxIter(10000); 
var o = k_means(input);

But this reintroduces boilerplate.

public class KMeansInput {
    private final Object X;
    
    public Object getX() { return x; }
    
    private final int nClusters;
    
    public int getNClusters() { return nClusters; }
    
    private Double sampleWeight = null;
    
    public Double getSampleWeight() { return sampleWeight; }
    
    public void setSampleWeight(Double sampleWeight) {
        this.sampleWeight = sampleWeight;
    }
    
    // ...
    private int maxIter = 300;
    
    public int getMaxIter() {
        return maxIter;
    }
    
    public void setMaxIter(int maxIter) {
        this.maxIter = maxIter;
    }
    
    // ...

    public KMeansInput(Object x, int nClusters) {
        this.X = x;
        this.nClusters = nClusters;
    }
}

So now not only do you have about a lot of boilerplate, just like the builder approach, but you are stuck with a mutable object in the end.

The next best candidate is records. They work well for getting an immutable aggregate with default values.

public record KMeansInput(
        Object X,
        int nClusters,
        Double sampleWeight,
        String init,
        String nInit,
        int maxIter,
        boolean verbose,
        double tol,
        Object randomState,
        boolean copyX,
        String algorithm,
        boolean returnNIter
) {
    public KMeansInput(Object X, int nClusters) {
        this(
                X, 
                nClusters, 
                null, 
                "k-means++", 
                "auto", 
                300, 
                false, 
                1e-4, 
                null, 
                true, 
                "lloyd", 
                false
        );
    }
}

Downside is that the constructor(s) you make to delegate to the canonical constructor will be fiddly. There aren't any names in that this(...) invocation.

There is also the fact that records expose a pattern matching API that is not currently generally available to all classes. This means that, unlike the Builder -> input object flow, adding new components to an input object record is always a sort of breaking change.

You will eventually be able to use withers to take a fully constructed record, update one part, and recreate the record.

var input = new KMeansInput(X, n_clusters).with {
    maxIter = 10000;  
};

But withers are also still not in the language. You can emulate them by making your own mutable aggregate and using it as a temporary for "reconstruction."

import java.util.function.Consumer;

public record KMeansInput(
        Object X,
        int nClusters,
        Double sampleWeight,
        String init,
        String nInit,
        int maxIter,
        boolean verbose,
        double tol,
        Object randomState,
        boolean copyX,
        String algorithm,
        boolean returnNIter
) {
    public KMeansInput(Object X, int nClusters) {
        this(
                X,
                nClusters,
                null,
                "k-means++",
                "auto",
                300,
                false,
                1e-4,
                null,
                true,
                "lloyd",
                false
        );
    }

    public KMeansInput with(Consumer<MutableKMeansInput> consumer) {
        var mut = new MutableKMeansInput(this);
        consumer.accept(mut);
        return mut.freeze();
    }
}

public final class MutableKMeansInput {
    public Object X;
    public int nClusters;
    public Double sampleWeight;
    public String init;
    public String nInit;
    public int maxIter;
    public boolean verbose;
    public double tol;
    public Object randomState;
    public boolean copyX;
    public String algorithm;
    public boolean returnNIter;
    
    MutableKMeansInput(KMeansInput input) {
        this.X = input.X;
        this.nClusters = input.nClusters;
        // and so on
    }
    
    KMeansInput freeze() {
        return new KMeansInput(X, nClusters, sampleWeight, ...);
    }
    
}

Using this scheme would look something like this.

var input = new KMeansInput(X, nClusters).with(it -> {
    it.maxIter = 10000;
});

You might notice that its somewhat like "builder, but backwards." A builder starts out with a mutable aggregate and later builds a (hopefully) immutable one. A record with this style of wither emulation starts off with an immutable aggregate and uses a temporary mutable aggregate which gets turned into the immutable verson later

Unfortunately this didn't really solve our boilerplate problem. Records once withers are in the language come the closest though. As with all boilerplate a degree of code generation can help a little, so you can reach for recordbuilder or similar.

The last way I can think of is a Java classic. Instead of having a method that takes in arguments, turn the whole process into an object.

class KMeans {
    private final Object X;
    private final int nClusters;
    private Double sampleWeight;
    // ...
    
    public KMeans(Object X, int nClusters) {
        // ...
        // initialize all the defaults
    }
    
    // then setters for all the knobs
    public void setSampleWeight(Double sampleWeight) {
        this.sampleWeight = sampleWeight;
    }
    
    // ...
    
    // and finally the ability to run the algorithm
    public KMeansOutput run() {
        // ...
    }
}

The overall object lifecycle of "make it, tweak it, run it" comes up a lot, but often especially when reading code from Java's early days. I don't have a coherent explanation as to why, but I think at some point this style of code fell out of favor.

var kMeans = new KMeans(X, nClusters);
kMeans.setMaxIter(10000);
var o = kMeans.run();

So of all these options suck in their own ways.

Records with withers has the most potential in my eyes, but its important to remember that this whole process only solves for the situation where most of the parameters are optional and have defaults.

While I'd say rare-ish, its not impossible to end up wanting to make something where all 20 or so parameters should be defined and have no defaults. Named arguments as a general feature could handle that, but it's going to be quite awhile before that is top of anyone's priority list.

Edit: As has been pointed out, you can also pass a callback that operates on a mutable object without necessarily exposing the object to be directly constructed.

kMeans(X, nClusters, opts -> opts.maxIter = 1000);

Same general sorts of tradeoffs between direct fields vs. methods that set exist there.

I don't know why I forget about that one all the time.

Also with the setters you can still do the builder thing where you make then chainable.

new KMeansInput(X, nClusters)
    .setMaxIter(1000)
    .setTol(1e-8);

<- Index

This list is the result of a question posed by Mika Moilanen. It's not comprehensive, but I think it's illustrative of a way to break down these choices that's a tad more healthy than "always choose X" or "never do Y." Specifically because you can take these properties and evaluate them against a given set of conditions.

"List all the differences between using an abstract class and using a delegate object when sharing common functionality."

Both let you reuse a method definition

class Adder {
    int add(int x, int y) {
        return x + y;
    }
}

class Composition {
    private Adder a = new Adder();
    
    int add(int x, int y) {
        return a.add(x, y);
    }
}

abstract class Adder {
    int add(int x, int y) {
        return x + y;
    }
}

class Inheritance extends Adder {
    // Implicitly inherits add
}

Composition requires you re-list every method you want to borrow

class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return x - y;
    }

    int mul(int x, int y) {
        return x * y;
    }

    int div(int x, int y) {
        return x / y;
    }
}

class Composition {
    private MathDoer m = new MathDoer();

    int add(int x, int y) {
        return m.add(x, y);
    }

    int sub(int x, int y) {
        return m.sub(x, y);
    }

    int mul(int x, int y) {
        return m.mul(x, y);
    }

    int div(int x, int y) {
        return m.div(x, y);
    }
}

abstract class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return x - y;
    }

    int mul(int x, int y) {
        return x * y;
    }

    int div(int x, int y) {
        return x / y;
    }
}

class Inheritance extends Adder {
    // Implicitly inherits add, sub, mul, and div
}

Inheritance can lead to observing otherwise hidden method relationships

abstract class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }
}

class Inheritance extends Adder {
    // Will print for both add and sub
    // but brittle if sub is ever redefined
    // to be "return x - y;"
    int add(int x, int y) {
        IO.println("Add called. x=" + x + ", y=" + y);
        return super.add(x, y);
    }
}

class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }
}

class Composition {
    private MathDoer m = new MathDoer();

    // Resilient to whatever internal relationships
    // add and sub have within MathDoer
    int add(int x, int y) {
        IO.println("Add called. x=" + x + ", y=" + y);
        return m.add(x, y);
    }

    int sub(int x, int y) {
        IO.println("Sub called. x=" + x + ", y=" + y);
        return m.sub(x, y);
    }
}

Inheritance implicitly gives polymorphic dispatch for all exposed methods

abstract class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return x - y;
    }
}

class Inheritance extends MathDoer {
    int add(int x, int y) {
        IO.println("Add called. x=" + x + ", y=" + y);
        return super.add(x, y);
    }
}

void main() {
    MathDoer m = new Inheritance();
    IO.println(m.add(1, 2));
}

// To get dynamic dispatch you need an intermediate interface
interface IMathDoer {
    int add(int x, int y);
    int sub(int x, int y);
}

// This in turn means methods must be public.
//
// If you want "package-private" dynamic dispatch you
// are out of luck.
class MathDoer implements IMathDoer {
    public int add(int x, int y) {
        return x + y;
    }

    public int sub(int x, int y) {
        return add(x, -1 * y);
    }
}

class Composition implements IMathDoer {
    private MathDoer m = new MathDoer();
    
    public int add(int x, int y) {
        return m.add(x, y);
    }

    public int sub(int x, int y) {
        return m.sub(x, y);
    }
}

void main() {
    IMathDoer m = new Composition();
    IO.println(m.add(1, 2));
}

You can compose behavior from multiple objects. Inheritance is linear

abstract class Adder {
    int add(int x, int y) {
        return x + y;
    }
}

abstract class Subber {
    int sub(int x, int y) {
        return x - y;
    }
}

class Inheritance extends Adder { // Cannot also extend Subber
    
}

class Adder {
    int add(int x, int y) {
        return x + y;
    }
}

class Subber {
    int sub(int x, int y) {
        return x - y;
    }
}

class Composition {
    private Adder a = new Adder();
    private Subber s = new Subber();

    // Resilient to whatever internal relationships
    // add and sub have within MathDoer
    int add(int x, int y) {
        return a.add(x, y);
    }

    int sub(int x, int y) {
        s.sub(x, y);
    }
}

Inheritance lets you define protected members which are public only to classes in the same package and extenders

package a;

abstract class MathDoer {
    protected abstract int addInternal(int x, int y);
    
    public final int add(int x, int y) {
        return addInternal(x, y);
    }

    public final int sub(int x, int y) {
        return addInternal(x, mul(y, -1));
    }
}

package b;

// If extending the class, can see addInternal 
// despite being in a different package
class Inheritance extends MathDoer {
    protected int addInternal(int x, int y) {
        return x + y;
    }
}

package a;

// No way to define a method or field that will
// be visible across package boundaries only to things
// that are "composing".
final class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }
}

Inheritance requires you directly expose constructors

abstract class MathDoer {
    // Subclasses need to call a super-class constructor
    MathDoer() {}
    
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }
}

class Inheritance extends Adder {
    Inhertiance() {
        super();
    }
}

class MathDoer {
    private MathDoer() {}
    
    public static MathDoer getIt() {
        return new MathDoer();
    }
    
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }
}

class Composition {
    // Meanwhile composition can allow you to keep constructors hidden
    // and only expose static factories or builders.
    private MathDoer m = MathDoer.getIt();
    
    int add(int x, int y) {
        return m.add(x, y);
    }

    int sub(int x, int y) {
        return m.sub(x, y);
    }
}

Inheritance leaves you exposed to new methods with incompatible signatures

abstract class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }
    
    // int mul(int x, int y) {
    //     return x * y;
    // }
}

class Inheritance extends Adder {
    double mul(int x, int y) {
        // This is fine initially, but poses a problem 
        // if an incompatible method is added to the superclass later
        return ((double) x * y);
    }
}

class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }

    int mul(int x, int y) {
        return x * y;
    }
}

class Composition {
    private MathDoer m = new MathDoer();

    // Resilient to whatever internal relationships
    // add and sub have within MathDoer
    int add(int x, int y) {
        return m.add(x, y);
    }

    int sub(int x, int y) {
        return m.sub(x, y);
    }

    // Any methods not taken via composition
    // do not pose a problem.
    //
    // A caveat is that this is an issue
    // with interfaces as well, so its more a property
    // of polymorphic dispatch
    double mul(int x, int y) {
        return ((double) x * y);
    }
}

Once I am able to cohere my thoughts without foaming at the mouth and twitching, expect a rant on "mechanics-ism."

<- Index

Ed Zitron, or as my friends call him while doing the SpongeBob thing "EdWaRd," Seems to think that AI is in some manner a bubble.

This is patently ridiculous. To understand why you need to understand a little basic kindergarten level economics.

The Lemonade Stand

Imagine a lemonade stand run by three plucky 12-year-olds. Call them Ed, Edd, and Eddy.

Each day of operation for this lemonade stand will both cost money to run and bring in money from sales. These costs are expenses and the money brought in is revenue.

Subtract expenses from revenue, and you get the total profit (or loss) for that day of operations.

Say they sell $10 worth of lemonade and the cost of sugar, lemon, and water totals up to $6. For that day they will have made $4 in profit.

Startup Costs

Businesses have all sorts of expenses.

We can simplify these broadly into one-time expenses (like the lumber to make the booth) and recurring expenses (like the materials to make the lemonade.)

One-time expenses needed for the business to begin operations are called "startup costs."

Since the business is not yet running - at least not at full capacity - the funds to cover these startup costs needs to come from somewhere else. For a lemonade stand this is likely a parent of one of the children. This, depending on the preferred child-rearing strategy, can make that parent an "investor."

So if it costs $20 to get all the supplies for the first day of operations, how long until the lemonade stand can repay their startup costs?

Unit Economics

It is generally understood that the more customers a business has the more money it makes.

To know exactly how much money to expect you need to understand the "unit economics" of the business. This is just the amount made per unit of product sold.

So if you sell 1 cup of lemonade for $1.00, and it took $0.50 to make, you will profit $0.50 per cup of lemonade sold.

This means that once you sell 40 cups of lemonade you will have made back the initial $20 investment.

Economies of Scale

Unfortunately sugar and lemons are not sold in clean "amount needed for a cup of lemonade" increments.

If you buy a small bag of sugar it might cost $5 but contain enough sugar for 20 cups of lemonade. If, however, you buy a large bag of sugar it might cost $100 but contain enough sugar for 1000 cups of lemonade.

This is what people mean by "economies of scale." If you can expect to sell more than 1000 cups of lemonade you can make your per-unit cost go down by buying the larger bag of sugar. If you aren't yet selling that much lemonade you might need to make do with the smaller bag.

Subsidies

It is always possible for a business to run at a loss. There are two broad reasons for this.

First is that it might not yet be profitable. It takes time for customers to discover and use your lemonade stand. For a period of time you might be stuck buying small bags of sugar. If you actually priced your product so that you make a profit-per-unit you might never get enough customers to "activate economies of scale."

Second is that it might never be profitable.

In both situations a business needs to be subsidized. This means that cash needs to be continuously injected to keep operations afloat.

Investors generally do this because they believe that, with enough time in the proverbial oven, the business can become profitable. One way that can happen is that the aforementioned "economies of scale" can drive down per-unit costs.

The other is "market capture." If you pour enough money into a lemonade stand that it can open branches on literally every street corner you can prevent new lemonade stands from opening. Being the only option in town for lemonade means you can jack up the price to become profitable. This has some limits - you can't make lemonade $2000 and expect anyone to be able or willing to afford that - but monopolies and oligopolies are almost the ideal state for a business.

If a business will never become profitable investors still might subsidize it. Lemonade stands are often used to teach children life lessons, not to become profitable. For this reason a parental investor might contribute money that they never expect to make back. The thing they are purchasing is not future returns but instead the existence of the lemonade stand itself.

With a particularly affluent parent a modest lemonade stand can be kept in operation almost indefinitely, even if they sell the lemonade for free.

Anthropic

Anthropic, a major AI company, loses money on every active user. This is because they charge people a monthly rate, and it costs multiple times that monthly rate to provide them the product they paid for.

The numbers aren't fully known, but it seems safe to say that for everyone who pays for and uses their platform they probably lose at least ~3x what that person paid them. The more someone uses their AI the faster they lose money.

There aren't any economies of scale left for them to activate. They are already plenty big and the GPUs they bought are expensive. But the more expensive part is actually running them. The costs of doing that aren't going to go down any time soon and actually increase the more usage they see.

They also can't make up the difference by capturing the market. Their users are costing them multiple thousands of dollars and only paying them at most a few hundred. Not enough people will drop a mortgage payment on AI to make up the difference.

Anthropic is just one AI company, but the broad math seems to be the same for all of them.

Why this still works

But here's the part that critics don't understand.

People aren't investing in AI companies to make a profit. It's clear these companies will never be profitable and, because the market famously is never irrational, investors must be taking this into account.

Instead, these companies are kept healthy and thriving by "parental investors." Just like how a lemonade stand keeps a kid occupied on the weekend and out of trouble, generative AI companies keep a large number of business and tech brothers off the streets. You'd much rather have then doing ZYNs and Addies in a safe office setting where they can chill with their homies and learn valuable life skills.

These investors have, from my perspective, almost infinite money. It only makes sense that they will be able to keep investing that infinite money forever, regardless of how much money the AI companies lose.

The future is bright and this economy - our economy - is invincible.

<- Index

Specifically using the Foreign Function and Memory API.

I've written about some of these issues before, but now I have a project I can use as an example.

Stick around to the end for an open challenge to the audience.

Context

Yu-Gi-Oh is a children's card game from Japan. Each player has "life points" and the goal of the game is to use your monsters, spells, and traps to reduce your opponent's life points to zero.

This game is how I first learned to read.

My Father likes playing a Yu-Gi-Oh game from the early 2000s called "Power of Chaos: Yugi the Destiny," named after the character in the anime who solves a puzzle and gets possessed by the spirit of an ancient Egyptian Pharaoh.

Since he figured out it supports multiplayer and can let me play against him, he has also started playing "Power of Chaos: Joey the Passion." This is also from the early 2000s and is named after the character in the anime who is a Japanese high school student that for some reason speaks with a Brooklyn accent.

Every now and then a character will die because they lost this children's card game. This got censored as them being "sent to the shadow realm," a place of eternal torture where their soul will never know peace. Much more kid friendly.

In my opinion the "Power of Chaos" series of games have by far the best visual, audio, and interaction design of any Yu-Gi-Oh game. This includes unofficial fan projects.

So something I threw on my large list of back-burner projects is to make my own Yu-Gi-Oh game that closely emulates the design of those early games.

Unfortunately the actual card game is crazy complicated. Every card is basically its own tiny program and there are decades of special case rulings to implement. It is well beyond the scope of what I am capable of as an individual.

Fortunately there is both a crowdsourced repository of lua scripts for all the cards and a community maintained engine for simulating the rules of the game. This engine has a relatively minimal C API and is, I think, a perfect example of the kind of thing that should have bindings written for it. The depth of expertise that went into it is unrepeatable.

Problem 1: C libraries aren't always pure C

Despite having a C API some of the headers of this particular library made use of C++ features. This is often ignorable in the C/C++ world since the major C compilers also support C++. It is not ignorable when you use jextract to generate bindings. jextract only supports C.

You could interpret this as a one-off, but my suspicion is that it's a problem that will naturally recur for libraries written in C++ that expose a C API. Especially if they are never tested in this context.

The solutions are to either make issues/open PRs or to enhance jextract to be able to support a limited subset of C++. Despite the words "limited subset" the latter is likely a nightmare pit of a task, so you should be ready to do the first.

Problem 2: You need different Java code per-platform

jextract takes as input a C header file and spits out a folder of Java classes. These classes include information about available functions as well as the memory layouts of defined structs. Unfortunately C is a protocol where memory layouts can change based on both the target operating system and the underlying CPU architecture.

This means you need different Java code for macos-aarch64 than you do for windows-x86. Pop-quiz: how do you do this in Maven? In Gradle?

You also need access to the target platform to generate this code. jextract doesn't have the zig cc magic that lets it compile for any platform from any platform. So you are left with having to use services like Github Actions.

In the absolute best case scenario you can just swap out a source set when compiling. OCG_CardData might have a platform specific layout, but the generated methods and struct members will be the same.

If you want to have one library support all platforms you'll need to contrive a system for selecting methods to call at runtime. This can lead to some pointless duplication.

Problem 3: C libraries are often special snowflakes

Question: what is the Maven Central for C?

Answer: ha. hahaha. ha. ha. ha. ha.

While there are things like Conan and vcpkg out in the world it's far from a given that any particular library you'd want is on them.

Its likely you'll end up either adding a GitHub repo as a submodule or writing a script to download the repo or some random .zip/.tar.gz file.

From there every C library has its own build instructions and flags you may or may not need to pass.

Pop-quiz: how do you do this in Maven? In Gradle?

Problem 4: You need to figure out packaging

From here we'll assume that the C library you are binding is going into a library. Either to be shared with the wider world or to be one module in a larger project tree.

Firstly, you probably need to make one artifact per target platform. In Maven repositories the way people share such artifacts is with a classifier scheme. Each artifact should be published with a -macos-aarch64 or similar classifier and modules depending on these libraries need to select the right one.

Then for the actual .dll/.so/.dylib that is the compiled artifact for the C library you have a few options.

1. Expect the user to just have it on their machine already or install it separately.
2. Expect the user to provide it manually with -Dsystem.library.path.
3. Package that file into a jar and extract it dynamically at runtime.
4. Package your code as a .jmod and expect that to be usable.

Option 1 sucks for obvious reasons.

Option 2 is just option 1 but without it needing to be a global system-level thing. Tools like Maven are, best I can tell, built around the concept that a "Set of Dependencies" should become a --class-path. You can't really have C shared libraries as automatically resolved dependencies.

Option 3 is what most libraries do today. LWJGL has "natives" jars which contain the actual shared libraries. It then uses a shim to extract the shared libraries to the filesystem. This is annoying firstly because its finicky code. Extracting a file atomically to the filesystem is a whole thing. It also requires that you are deploying code in a context where you have a writable filesystem. This is not always the case.

But most importantly it annoys me because it is so clearly a forced move. If you could actually just put the shared library on the -Dsystem.library.path automatically in the same way other dependencies are automatically put on the --class-path I don't think people would be doing it. Well, that and if people weren't universally using uberjars as their deployment mechanism.

Option 4 I think has potential. It's what I've done for the Yu-Gi-Oh bindings. For those unaware, .jmod files have delineated locations for classes, legal metadata, configuration files, and shared libraries. This is how the JDK bundles the shared libraries needed for making things like Swing work.

One problem is that .jmods aren't usable at runtime. You need to link them together with jlink to produce a JDK then use that JDK. You can technically extract the contents of a .jmod and put the extracted classes folder on the --module-path and libs on the -Dsystem.library.path.

Pop-quiz: how do you do that in Maven? In Gradle?

Problem 5: Nobody uses the --module-path

In discussions about the --module-path the focus tends to be on one of three aspects.

1. I heard a friend of a cousin say it broke a library nearly a decade ago in Java 9.
2. It was needed to turn off deep reflection for JDK internals.
3. Wow, tooling does not support this well at all.

The 3rd aspect is most relevant here because you can't really expect anyone using your library to have put it on the --module-path. This is unfortunate because modules are the only mechanism to group up and hide whole packages from external consumers.

jextract will generate a large number of public classes which contain calls to fundamentally unsafe APIs. Not only that, unless you go through and manually allowlist functions and symbols with --include-function et al. it will contain a lot of stray functions you may or may not be using in your actual binding code.

What you would ideally want is to just not export those autogenerated classes and only export the code you wrote that wraps them up. This would be needed for someone writing --enable-native-access=your.specific.module to mean "I have audited or otherwise trust the producer of this module to have interacted with the native world in a way that won't crash the JVM."

This is in contrast to --enable-native-access=ALL-UNNAMED and "yeah whatever, just let me use native stuff. Who cares where it comes from."

Even if you don't particularly care about that story, autogenerated bindings don't make for the world's best public API.

Challenges

So with that prelude, here is the challenge for the audience.

1. Using your build tool of choice (Maven, Gradle, bld, Mill, etc.) replace the Justfile I have to build the project. I mean replace, not do a different or worse job. Produce as a final artifact a .jmod, procure the C library, run jextract, include the proper legal metadata, etc.

2. Put it in a local maven repository and use it from a Maven project. Good luck.

3. Bonus points, actually work on the unfinished binding code. Would be appreciated, but it's also my burden to bear and not super relevant to the rest of this post.

<- Index

This might come as somewhat of a shock to my regular audience, but I don't only write Java.

The reason I focus so much on specifically Java education is because it is often the first language people are taught. This matters for a lot of reasons, not all of which I have the page space to get in to, but crucially being taught first has a direct impact on a language's popularity.

I'm writing this because I think Clojure now has a real shot at becoming a first language.

Why

Of all the less-than-massively-popular-languages out there, Clojure is probably hurt the least by not having widespread adoption. This is in large part because it gets to piggyback on existing libraries and ecosystems.

Clojure is a hosted language. Clojure on the JVM can use any Java library, Clojure in the browser can use any JavaScript library, and so on. It is always good when Clojure-native libraries get written, but they've never been an absolute necessity.

So why pursue popularity?

1. Paper Clipping.

A lawyer has a duty to be a zealous advocate for their client. There's a non-trivial tribal monkey aspect to wanting your programming language to be popular and, at a certain point, pursuing that end has no fundamental justification.

But we make our own meaning in life so screw it.

2. It's Better.

The value proposition of Clojure is different to most other languages. I'm not going to s*** Paul Graham's d*** or wax poetic about macros, but it's hard to deny that Clojure codebases tend to be quite different to those written in Python, JavaScript, Java, R, etc.

There are reasons to think that Clojure could be a better fit for producing certain genres of software. Popularity would therefore lead to "better" software being produced, which is reasonable to want.

I'm being vague on purpose here. The difference between closed and open aggregates alone could be its own essay.

3. Money.

The more people who use Clojure the more Clojure jobs there are. The more Clojure jobs there are the more secure Clojure experts can be, etc.

TypedClojure is a one-man-show. TypeScript is funded by Microsoft paychecks. Popularity opens the door to all sorts of support.

How

So to become popular you need to be someone's first language. To be someone's first language you need to be what they learned in school. This means convincing teachers and curriculum makers.

For CS education I think this is a lost cause. There are very well-made CS 101 courses that use lisps and face cosmically stupid pushback for doing so. It is hard to imagine winning that fight.

But people going for Computer Science degrees aren't the only people who program. When my brother got his Masters in Marine Biology he was taught R. Analyzing data, making charts, etc. is needed for a wide variety of fields.

I think Clojure could steal significant market share here.

Noj is a collection of a bunch of data science libraries for Clojure. With what is in there you can:

• Load data into data frames
• Make visualizations
• Train ML models (including deep learning)
• Do anything Python can do (by directly calling Python libraries)
• Do anything R can do (by directly calling R libraries)
• Do anything Wolfram can do (by directly calling Worlfram)
• ... and more

This has the makings of an extremely compelling pitch.

The biggest missing piece, as I see it, is resources tailored to people learning Clojure as a first language.

Historically the vast majority of Clojure programmers have been transplants from other languages. We have books like Clojure for the Brave and True that serve this crowd, but few-to-none for people who are starting truly from scratch.

This has also affected the way people talk about Clojure. Keep in mind that you don't need to convince people of functional programming, homoiconicity, or anything else when it's the first thing they learn. The pitches you'd use to pull in a Ruby programmer should be kept in their lane.

So that's the gap. The data science people are presumably going to keep chugging away at the things they do. If you are interested in making Clojure a "First Language" give a shot at making something that fills that gap.

<- Index

java.util.Optional is a class that breaks peoples brains a bit.

It offers a way to represent a potentially missing piece of information. If your method might not produce a result you can use an empty Optional to represent that.

Optional<LocalDate> birthday(String name) {
    return switch (name) {
        case "Mr. Rodgers" -> 
                Optional.of(LocalDate.of(1928, Month.MARCH, 20));
        case "Mr. T" -> 
                Optional.of(LocalDate.of(1952, Month.MAY, 21));
        default -> 
                Optional.empty();
    };
}

void main() {
    for (var name : List.of("Mr. T", "H.R. Puffinstuff")) {
        IO.println(name + ": " + birthday(name));
    }
}

This has a few pros over the other standard option of returning null.

For one, Java's type system (currently) does not track null values as part of a type. This means that a programmer needs to infer nullability from written documentation and context clues.

LocalDate birthday(String name) {
    return switch (name) {
        case "Mr. Rodgers" -> 
                LocalDate.of(1928, Month.MARCH, 20);
        case "Mr. T" -> 
                LocalDate.of(1952, Month.MAY, 21);
        default -> 
                null;
    };
}

void main() {
    for (var name : List.of("Mr. T", "H.R. Puffinstuff")) {
        // .getMonth() is not always valid to call
        IO.println(name + ": " + birthday(name).getMonth());
    }
}

This is mitigated somewhat when an API makes use of nullability annotations. Today that requires you to use special null-aware tooling but null-aware types are slated to come to Java proper at some point.

// LocalDate? in the future (probably)
@Nullable LocalDate birthday(String name) {
    return switch (name) {
        case "Mr. Rodgers" -> 
                LocalDate.of(1928, Month.MARCH, 20);
        case "Mr. T" -> 
                LocalDate.of(1952, Month.MAY, 21);
        default -> 
                null;
    };
}

void main() {
    for (var name : List.of("Mr. T", "H.R. Puffinstuff")) {
        // Tooling should catch this mistake
        IO.println(name + ": " + birthday(name).getMonth());
    }
}

But null values in Java always require explicit checks to handle.

if (v == null) {
    // ...
}

// or

v == null ? ... : ...;

// or Objects.requireNonNullElse(v, ...)
// but that's just a method

This makes them ill-suited to the task Optional was originally introduced for - being part of the customary chain of method calls that form stream operations. This is most important when an Optional appears in the middle of a stack of such operations, but even when the Optional handling is at the end it's at least aesthetic.

Stream.of(1, 2, 3)
    .filter(x -> x < 2)
    .findFirst() // Here is where we get an optional
    .orElse(0); // And we can preserve the method chain stack 

People are far more likely to remember to write the above when Java forces them to. That's the point of it.

Integer first = Stream.of(1, 2, 3)
    .filter(x -> x < 2)
    .findFirst(); 
// Not forced to handle null usually and it's aesthetically
// inconvenient. This leads to mistakes in the context of chained methods.
if (first == null) {
    first = 0;
}

But because it "solves null" (it doesn't) it sees a lot of use. A very common pattern has been for folks to take a null returning method and refactor it to use optional instead.

When this works its generally fine, what isn't fine is how callsites are often adapted.

User user = findUserById(id);
if (user != null) {
    // Logic
}

The code above is often turned into something like the following.

Optional<User> userOpt = findUserById(id);
if (userOpt.isPresent()) {
    User user = userOpt.get(); // or .orElseThrow() if civilized
    // Logic
}

Callsites refactored like this are strictly worse. Often an extra intermediate variable needs to be created, that intermediate has a stupid name, and static analysis tools will either not know what is happening or have special carve out exceptions so they know "when .isPresent(), .get() is okay."

Those carve out exceptions may or may not also apply to other ecosystem Optional types.

// It's hard to argue that java.util.Optional really deserves
// special treatment over vavr's Option, but because code like
// this exists it's going to get it.
Option<User> userOpt = findUserById(id);
if (userOpt.isDefined()) {
    User user = userOpt.get();
    // Logic
}

And the general sort of advice to deal with this is to use .map and .ifPresent - the methods that let you work with the value in an Optional without "unboxing" it.

findUserById(id).ifPresent(user -> {
    // Logic
});

// or keep chaining and deal with it later

findUserById(id).map(User::email);

When this works, it can be better. It just stops working when the code you want to run that involves the value might throw a checked exception - .ifPresent and friends cannot cope with that.

findUserById(id).ifPresent(user -> {
    // Logic
    if (...) {
        // Difficult to know what to do.
        // Do we wrap the exception?
        callRemoteAPI();  
    }
    // Logic
});

It also stops working when you have multiple Optionals, at least from a readability perspective.

findUserById(idA).ifPresent(userA -> {
    findUserById(idB).ifPresent(userB -> {
        findUserById(idC).ifPresent(userC -> {
            // Logic
        }); 
    });
});

And also when you want to mutate some local variables relevant to the rest of the function.

int existingUsers = 0;
findUserById(id).ifPresent(user -> {
    // Logic
    existingUsers++; // Lambda rules - does not work
    // Logic
});

And just in general, beyond the small and clean usages, I think using these methods makes code net worse.

What I suggest, and I think people don't consider specifically because they are viewing Optional as a replacement for null, is to use .orElse(null) and write the rest of the code in the method like normal.

User user = findUserById(id).orElse(null);
if (user != null) {
    // Logic
}

Static analysis tools can eat "local variable known to sometimes be null" for breakfast and there are no problems handling checked exceptions, multiple optionals, or mutating local state. It's a much more seamless refactor.

int existingUsers = 0;

User userA = findUserById(idA).orElse(null);
User userB = findUserById(idB).orElse(null);
User userC = findUserById(idC).orElse(null);
if (userA != null && userB != null && userC != null) {
    // Logic
    existingUsers++;
    if (...) {
        callRemoteAPI();  
    }
    // Logic
}

The fact that it might be null also becomes explicit in the source code at every usage site, which is a strict improvement over the equivalent code with null returning methods.

int existingUsers = 0;

// Back to inferring from context or documentation
User userA = findUserById(idA);
User userB = findUserById(idB);
User userC = findUserById(idC);
if (userA != null && userB != null && userC != null) {
    // Logic
    existingUsers++;
    if (...) {
        callRemoteAPI();  
    }
    // Logic
}

There are more bike sheds to have on Optional, don't get me wrong, I just want to strongly encourage you to reconsider blanket advice to "avoid .isPresent/.get, use .map/.ifPresent" and highlight that .orElse is useful for more than valid default values.

<- Index

I'm not a professional Go programmer so feel free to correct me on anything.

The rest of this post is going to follow the example program from this piece of Go Documentation. I'm even going to straight rip a lot of the prose.

My intent is to highlight how you can do spiritually similar things in Java.

The code in this guide, god willing, will work unaltered in Java 25.

Prerequisites

• Java.
• Some Libraries. The repo at the end will have them all in a folder. Java dependency management is a whole adventure, for now just follow along the ride.

Getting Started

Make a new directory for this tutorial and cd into it:

$ mkdir javawiki
$ cd javawiki

Create a file named Wiki.java, open it in your favorite editor, and add the following lines:

void main() {
}

Data Structures

A wiki consists of a series of interconnected pages, each of which has a title and a body (the page content). Here, we define Page as a record with two components representing the title and body.

record Page(String title, byte[] body) {}

The Page record describes how page data will be stored in memory. But what about persistent storage? We can address that by creating a save method on Page:

record Page(String title, byte[] body) {
    void save() throws IOException {
        var filename = title + ".txt";
        Files.write(Path.of(filename), body);
    }
}

The save method throws an IOException to let the application handle it should anything go wrong while writing the file. If all goes well, Page.save() will return without throwing.

In addition to saving pages, we will want to load pages, too:

record Page(String title, byte[] body) {
    void save() throws IOException {
        var filename = title + ".txt";
        Files.write(Path.of(filename), body);
    }

    static Page load(String title) throws IOException {
        var filename = title + ".txt";
        var body = Files.readAllBytes(Path.of(filename));
        return new Page(title, body);
    }
}

The method load constructs the file name from the title parameter, reads the file's contents into a new variable body, and returns a reference to a Page object.

At this point we have a simple data structure and the ability to save to and load from a file. Let's update the main method to test what we've written:

void main() throws IOException {
    var p1 = new Page(
            "TestPage", 
            "This is a sample Page.".getBytes(StandardCharsets.UTF_8)
    );
    p1.save();
    var p2 = Page.load("TestPage");
    IO.println(new String(p2.body, StandardCharsets.UTF_8));
}

After executing this code, a file named TestPage.txt would be created, containing the contents of p1. The file would then be read into p2, and its body component printed to the screen.

You can run the program like this:

$ java Wiki.java

Click here to view the code we've written so far.

Introducing the jdk.httpserver module (an interlude)

Here's a full working example of a simple web server:

import module jdk.httpserver;

void handler(HttpExchange exchange) throws IOException {
    exchange.sendResponseHeaders(200, 0);
    try (var os = exchange.getResponseBody()) {
        os.write(
                "Hi there, I love %s!"
                        .formatted(exchange.getRequestURI().getPath().substring(1))
                        .getBytes(StandardCharsets.UTF_8)
        );
    }
}

void main() throws IOException {
    var server = HttpServer.create(
            new InetSocketAddress(8080),
            0
    );
    server.createContext("/", this::handler);
    server.start();
}

The main method begins with a call to HttpServer.create, which creates an http server that will listen on port 8080. (Don't worry about its second parameter, 0, for now.)

Then server.createContext tells the server to handle all requests to the web root ("/") with handler.

It then calls `server.start(). This method will block until the program is terminated.

If you run this program and access the URL:

http://localhost:8080/monkeys

the program would present a page containing:

Hi there, I love monkeys!

Introducing the dev.mccue.jdk.httpserver module (an interlude within an interlude)

The jdk.httpserver module does not see as widespread use as Go's equivalent. As such, I think there are some ways to improve the API that should be rolled into the standard library at some point.

I put the most important of these - a Body abstraction - into a library. I'm going to ignore how to procure libraries in Java for the moment, but suspend your disbelief in the meantime.

With this library the server example above becomes the following:

import module jdk.httpserver;
import module dev.mccue.jdk.httpserver;

void handler(HttpExchange exchange) throws IOException {
    HttpExchanges.sendResponse(
            exchange,
            200,
            Body.of("Hi there, I love %s!".formatted(
                    exchange.getRequestURI().getPath().substring(1)
            ))
    );
}

void main() throws IOException {
    var server = HttpServer.create(
            new InetSocketAddress(8080),
            0
    );
    server.createContext("/", this::handler);
    server.start();
}

Using jdk.httpserver to serve wiki pages

Let's create a handler, viewHandler that will allow users to view a wiki page. It will handle URLs prefixed with "/view/".

void viewHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/view/".length());
    var p = Page.load(title);
    HttpExchanges.sendResponse(
            exchange,
            200,
            Body.of(
                    "<h1>%s</h1><div>%s</div>"
                            .formatted(
                                    p.title, 
                                    new String(p.body, StandardCharsets.UTF_8)
                            )
            )
    );
}

To use this handler, we rewrite our main function to initialize an HttpServer using the viewHandler to handle any requests under the path /view/.

void main() throws IOException {
    var server = HttpServer.create(
            new InetSocketAddress(8080),
            0
    );
    server.createContext("/view/", this::viewHandler);
    server.start();
}

Click here to view the code we've written so far.

Let's create some page data (as test.txt), compile our code, and try serving a wiki page.

Open test.txt file in your editor, and save the string "Hello world" (without quotes) in it.

java --module-path lib --add-modules ALL-MODULE-PATH Wiki.java

With this web server running, a visit to http://localhost:8080/view/test should show a page titled "test" containing the words "Hello world".

Editing Pages

A wiki is not a wiki without the ability to edit pages. Let's create two new handlers: one named editHandler to display an 'edit page' form, and the other named saveHandler to save the data entered via the form.

First, we add them to main():

void main() throws IOException {
    var server = HttpServer.create(
            new InetSocketAddress(8700),
            0
    );
    server.createContext("/view/", this::viewHandler);
    server.createContext("/edit/", this::editHandler);
    server.createContext("/save/", this::saveHandler);
    server.start();
}

The method editHandler loads the page (or, if it doesn't exist, create an empty Page record), and displays an HTML form.

void editHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/edit/".length());
    Page p;
    try {
        p = Page.load(title);
    } catch (NoSuchFileException e) {
        p = new Page(title, new byte[]{});
    }
    HttpExchanges.sendResponse(
            exchange,
            200,
            Body.of(
                    """
                    <h1>Editing %s</h1>
                    <form action="/save/%s" method="POST">
                        <textarea name="body">%s</textarea><br>
                        <input type="submit" value="Save">
                    </form>
                    """.formatted(
                            p.title,
                            p.title,
                            new String(p.body, StandardCharsets.UTF_8)
                    )
            )
    );
}

This function will work fine, but all that hard-coded HTML is ugly. Of course, there is a better way.

(I mean honestly the bigger issue is XSS vulnerabilities, but whatever. Following along.)

The com.samskivert.jmustache module

com.samskivert.jmustache is a library available in the Java ecosystem. We can use it to keep the HTML in a separate file, allowing us to change the layout of our edit page without modifying the underlying Java code.

First, we must add com.samskivert.jmustache to the list of imports. Again, we are glancing over how you procure libraries for this tutorial.

import module jdk.httpserver;
import module dev.mccue.jdk.httpserver;
import module com.samskivert.jmustache;

Let's create a template file containing the HTML form. Open a new file named edit.html, and add the following lines:

<h1>Editing {{title}}</h1>

<form action="/save/{{title}}" method="POST">
    <div><textarea name="body" rows="20" cols="80">{{body}}</textarea></div>
    <div><input type="submit" value="Save"></div>
</form>

Modify editHandler to use the template, instead of the hard-coded HTML:

void editHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/edit/".length());
    Page p;
    try {
        p = Page.load(title);
    } catch (NoSuchFileException e) {
        p = new Page(title, new byte[]{});
    }
    
    var template = Mustache.compiler()
            .compile(Files.readString(Path.of("edit.html")));
    HttpExchanges.sendResponse(
            exchange,
            200,
            Body.of(template.execute(Map.of(
                    "title", p.title,
                    "body", new String(p.body, StandardCharsets.UTF_8)
            )))
    );
}

Since we're working with templates now, let's create a template for our viewHandler called view.html:

<h1>{{title}}</h1>

<p>[<a href="/edit/{{title}}">edit</a>]</p>

<div>{{body}}</div>

Modify viewHandler accordingly:

void viewHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/view/".length());
    var p = Page.load(title);
    var template = Mustache.compiler()
            .compile(Files.readString(Path.of("view.html")));
    HttpExchanges.sendResponse(
            exchange,
            200,
            Body.of(template.execute(Map.of(
                    "title", p.title,
                    "body", new String(p.body, StandardCharsets.UTF_8)
            )))
    );
}

Notice that we've used almost exactly the same templating code in both handlers. Let's remove this duplication by moving the templating code to its own function:

void renderTemplate(
        HttpExchange exchange,
        String tmpl,
        Page p
) throws IOException {
    var template = Mustache.compiler()
            .compile(Files.readString(Path.of(tmpl)));
    HttpExchanges.sendResponse(
            exchange,
            200,
            Body.of(template.execute(Map.of(
                    "title", p.title,
                    "body", new String(p.body, StandardCharsets.UTF_8)
            )))
    );
}

And modify the handlers to use that function:

void viewHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/view/".length());
    var p = Page.load(title);
    renderTemplate(exchange, "view", p);
}

void editHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/edit/".length());
    Page p;
    try {
        p = Page.load(title);
    } catch (NoSuchFileException e) {
        p = new Page(title, new byte[]{});
    }

    renderTemplate(exchange, "edit", p);
}

Click here to view the code we've written so far.

Handling non-existent pages

What if you visit /view/APageThatDoesntExist You'll get no response. This is because Page.load errors. Instead, if the requested Page doesn't exist, it should redirect the client to the edit Page so the content may be created:

void viewHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/view/".length());
    Page p;
    try {
        p = Page.load(title);
    } catch (NoSuchFileException _) {
        exchange.getResponseHeaders()
                .put("Location", List.of("/edit/" + title));
        HttpExchanges.sendResponse(exchange, 302, Body.empty());
        return;
    }
    renderTemplate(exchange, "view", p);
}

To do this we send an HTTP status code of 302 and a include Location header in the response.

Saving pages

The function saveHandler will handle the submission of forms located on the edit pages. To parse the form body we are going to add another library - dev.mccue.urlparameters.

import module dev.mccue.urlparameters;

void saveHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/save/".length());
    var body = UrlParameters.parse(
            new String(
                    exchange.getRequestBody().readAllBytes(),
                    StandardCharsets.UTF_8
            )
    ).firstValue("body").orElseThrow();
    var p = new Page(title, body.getBytes(StandardCharsets.UTF_8));
    p.save();
    exchange.getResponseHeaders()
            .put("Location", List.of("/view/" + title));
    HttpExchanges.sendResponse(exchange, 302, Body.empty());
}

Click here to view the code we've written so far.

Etc.

There is more in the Go tutorial, including caching templates, making sure there aren't path traversal vulnerabilities (which, very important!), and some other potpourri.

But the purpose of this is just to illustrate that Java is capable of the same sort of "simple" web development that Go is known for. I'm leaving that stuff (and introducing a proper mux) as exercises for you the reader.

And just as a note: If you dig into the jdk.httpserver module you will see some "for development only" warnings around it. This is because the actual server implementation in the JDK is mostly there to serve the jwebserver tool. (jwebserver is more or less equivalent to Python's http.server) You can seamlessly swap to using a production quality server like Jetty and others by adding the appropriate dependencies.

Tell me all about your past traumas with Java in the comments below.

<- Index

"Groyper" is the term used to describe the followers of Nick Fuentes.

Nick Fuentes is a "Hitlerist," meaning he agrees with specifically the policies of Adolf Hitler. You might also know him as the "Your Body, My Choice" guy.

"Big Balls" is the name of one of the young fascists recruited by DOGE. He gained particular notoriety for being young, very punchable, and having a head turning nickname.

Another DOGE fascist is Gavin Kliger. Gavin Kliger is very much a Groyper.

They are all Groypers.

This is why when DOGE fascist Marko Elez posted "Just for the record, I was racist before it was cool" and "Normalize Indian hate" Elon Musk went out of his way to keep him on the team.

DOGE has announced plans to rewrite the computer systems of the Social Security Administration. The timeline they give for this endeavor is several months.

This will not work out for the people who are dependent on their Social Security checks. The way in which it won't work out is t.b.d., but there are a few possibilities that come to mind.

For one, they are supposedly replacing tens of millions of lines of COBOL. That is an amount of code far beyond anyone's capacity to fully understand, let alone recreate, in a few months.

So best case scenario they miss something. More likely scenario they don't care if they "miss" something. These are fascists. They are predisposed to make things worse on purpose out of condescension, intentional malice, or some other goblin emotion.

Then there is the overarching plot-line of dismantling the social safety net. The template for those sorts of actions tends to be to take over a public service, make it worse, then privatize it as a solution. This would fit that template.

The stated plan is to accomplish this with AI. The practice of using AI to produce large chunks of code has been christened by the venture capital tech space as "Vibe Coding."

Training programs have already sprung up seeking to capitalize on the term, reinforcing the convenient smuggling it gives to obvious negligence.

As was the pattern with Big Data and "Web 3" before it, the programming and tech world seems to have few antibodies to nonsensical claims of future potential. Even skepticism will end up wrapped in the framing of "Well this is obviously the future, but."

Social Security's systems are reportedly currently in COBOL, but the plan is for them to be rewritten into Java.

There would be, in a saner time, reasons for that. Java can run on what we would call "commodity hardware" and there is a statistically younger pool of trained people to pull on to write it. It wouldn't be the first system "modernized" in such a way and doing so could make longer term maintenance simpler in a few ways.

But while COBOL Mainframes have a casual reputation of being relics of the past, they are some of the only systems in the world where you can have leader + follower replication of the results of individual CPU instructions.

IBM, the "Made the Holocaust Possible" company, has an online transaction system called CICS that I have been informed is "nuclear attack resistant." I rest easy believing that, if we ever have the privilege to suffer through a Threads, my bank account will have its correct balance.

Unless they found a well-thought-out plan tucked in the desk of a more competent person they fired, these considerations will not be approached with nuance.

I mean, presuming there is a plan at all. It could just be, intentionally or not, a distraction while they pull out more important copper wiring like the FDIC.

If I'm found dead it wasn't a suicide. If I'm disappeared find and rescue me. Leave comments wherever.

<- Index

Believe it or not, I don't think that title is clickbait.

There is a set of things that you can do when working with a Postgres database which I have found made my and my coworker's lives much more pleasant. Each one is by itself small, but in aggregate have a noticeable effect.

Use UUID primary keys

UUIDs have downsides

• Truly random UUIDs doesn't sort well (and this has implications for indexes)
• They take up more space than sequential ids (space being your cheapest resource)

But I've found those to be far outweighed by the upsides

• You don't need to coordinate with the database to produce one.
• They are safe to share externally.

CREATE TABLE person(
    id uuid not null default gen_random_uuid() primary key,
    name text not null
)

Give everything created_at and updated_at

It's not a full history, but knowing when a record was created or last changed is a useful breadcrumb when debugging. Its also something you can't retroactively get unless you were recording it.

So just always slap a created_at and updated_at on your tables. You can maintain updated_at automatically with a trigger.

CREATE TABLE person(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    name text not null
);

CREATE FUNCTION set_current_timestamp_updated_at()
    RETURNS TRIGGER AS $$
DECLARE
_new record;
BEGIN
  _new := NEW;
  _new."updated_at" = now();
RETURN _new;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER set_person_updated_at
    BEFORE UPDATE ON person
    FOR EACH ROW
    EXECUTE PROCEDURE set_current_timestamp_updated_at();

You need to create the trigger for each table, but you only need to create the function once.

on update restrict on delete restrict

When you make a foreign key constraint on a table, always mark it with on update restrict on delete restrict.

This makes it so that if you try and delete the referenced row you will get an error. Storage is cheap, recovering data is a nightmare. Better to error than do something like cascade.

CREATE TABLE person(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    name text not null
);

CREATE TABLE pet(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    name text not null,
    owner_id uuid not null references person(id)
                on update restrict
                on delete restrict
);

Use schemas

By default, every table in Postgres will go into the "public" schema. This is fine, but you are missing out if you don't take advantage of your ability to make new schemas.

Schemas work as namespaces for tables and for any moderate to large app you are going to have a lot of tables. You can do joins and have relationships between tables in different schemas so there isn't much of a downside.

CREATE SCHEMA vet;

CREATE TABLE vet.person(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    name text not null
);

CREATE TABLE vet.pet(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    name text not null,
    owner_id uuid not null references vet.person(id)
                on update restrict
                on delete restrict
);

Enum Tables

There are a lot of ways to make "enums" in sql. One is to use the actual "enum types," another is to use a check constraint.

The pattern introduced to me by Hasura was enum tables.

Have a table with some text value as a primary key and make columns in other tables reference it with a foreign key.

CREATE TABLE vet.pet_kind(
    value text not null primary key
);

INSERT INTO vet.pet_kind(value)
VALUES ('dog'), ('cat'), ('bird');

CREATE TABLE vet.pet(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    owner_id uuid not null references vet.person(id)
                on update restrict
                on delete restrict,
    kind text not null references vet.pet_kind(value)
                on update restrict
                on delete restrict
);

This way you can insert into a table to add more allowed values or attach metadata like a comment to explain what each value means.

CREATE TABLE vet.pet_kind(
    value text not null primary key,
    comment text not null default ''
);

INSERT INTO vet.pet_kind(value, comment)
VALUES 
    ('dog', 'A Canine'),
    ('cat', 'A Feline'),
    ('bird', 'A 50 Year Commitment');

CREATE TABLE vet.pet(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    owner_id uuid not null references vet.person(id)
                on update restrict
                on delete restrict,
    kind text not null references vet.pet_kind(value)
                on update restrict
                on delete restrict
);

Name your tables singularly

This isn't even Postgres specific, just please name your tables using the singular form of a noun.

SELECT * FROM pets might seem nicer than SELECT * FROM pet but the moment you start doing anything more interesting with your queries you will notice that your queries are actually working in terms of individual rows.

SELECT *
FROM pet
-- It's a cruel coincidence that in english an "s"
-- suffix can sometimes work both as a plural
-- and a possessive, but notice how the where clause
-- is asserting a condition about a single row.
WHERE pet.name = 'sally' 

The deeper you dig the more annoying edge cases you'll run into with plural table names. Just name your tables the same as what an individual row in that table represents.

Mechanically name join tables

Sometimes there are sensible names to give "join tables" - tables which form the basis for "many to many" relationships between data - but often there isn't. In those cases don't hesitate to just concatenate the names of the tables you are joining between.

CREATE TABLE vet.person(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now()
);

CREATE TABLE vet.pet(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now()
);

-- pet_owner would work in this context, but
-- I just want to demonstrate the table_a_table_b naming scheme
CREATE TABLE vet.person_pet(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    person_id uuid not null references vet.person(id)
                on update restrict
                on delete restrict,
    pet_id uuid not null references vet.pet(id)
                on update restrict
                on delete restrict
);

CREATE UNIQUE INDEX ON vet.person_pet(person_id, pet_id);

Almost always soft delete

I will reiterate that storage is cheap and recovering data is a nightmare.

If you have some domain specific need to delete (or otherwise mark as irrelevant) some data, use a nullable timestamptz column. If there is a timestamp filled in, that's when it was deleted. If there is no timestamp it isn't deleted yet.

CREATE TABLE vet.prescription(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    pet_id uuid not null references vet.pet(id)
             on update restrict
             on delete restrict,
    issued_at timestamptz not null,
    -- Instead of deleting a prescription,
    -- explicitly mark when it was revoked
    revoked_at timestamptz
);

Even outside the context of a soft delete, timestamps are usually more useful than a boolean. If you want to know whether something happened, you generally also want to know when it happened.

Represent statuses as a log

It is very tempting to represent the status of something as a single column. You submit some paperwork and it has a status of submitted. Someone starts to look at it then it transitions to in_review. From there maybe its rejected or approved.

There are two problems with this

1. You might actually care about when it was approved, or by whom.
2. You might receive this information out-of-order.

Webhooks are a prime example of the 2nd situation. There's no way in the laws of physics to be sure you'll get events in exactly the right order.

To handle this you should have a table where each row represents the status of the thing at a given point in time. Instead of overloading created_at or updated_at for this, have an explicit valid_at which says when that information is valid for.

CREATE TABLE vet.adoption_approval_status(
    value text not null primary key
);

INSERT INTO vet.adoption_approval_status(value)
VALUES ('submitted'), ('in_review'), ('rejected'), ('approved');

CREATE TABLE vet.adoption_approval(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    person_id uuid not null references vet.person(id)
                on update restrict
                on delete restrict,
    status text not null references vet.adoption_approval_status(value)
                on update restrict
                on delete restrict,
    valid_at timestamptz not null
);

CREATE INDEX ON vet.adoption_approval(person_id, valid_at DESC);

Just having an index on valid_at can work for a while, but eventually your queries will get too slow. There are a lot of ways to handle this, but the one we've found that works the best is to have an explicit latest column with a cheeky unique index and trigger to make sure that only the row with the newest valid_at is the latest one.

CREATE TABLE vet.adoption_approval(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    person_id uuid not null references vet.person(id)
                on update restrict
                on delete restrict,
    status text not null references vet.adoption_approval_status(value)
                on update restrict
                on delete restrict,
    valid_at timestamptz not null,
    latest boolean default false
);

CREATE INDEX ON vet.adoption_approval(person_id, valid_at DESC);

-- Conditional unique index makes sure we only have one latest
CREATE UNIQUE INDEX ON vet.adoption_approval(person_id, latest)
WHERE latest = true;

-- Then a trigger to keep latest up to date
CREATE OR REPLACE FUNCTION vet.set_adoption_approval_latest()
 RETURNS trigger
 LANGUAGE plpgsql
AS $function$
BEGIN
    UPDATE vet.adoption_approval
    SET latest = false
    WHERE latest = true and person_id = NEW.person_id;

    UPDATE vet.adoption_approval
    SET latest = true
    WHERE id = (
        SELECT id 
        FROM vet.adoption_approval 
        WHERE person_id = NEW.person_id
        ORDER BY valid_at DESC 
        LIMIT 1
    );

    RETURN null;
END;
$function$;

CREATE TRIGGER adoption_approval_insert_trigger
    AFTER INSERT ON vet.adoption_approval
    FOR EACH ROW
    EXECUTE FUNCTION vet.set_adoption_approval_latest();

Mark special rows with a system_id

It's not uncommon to end up with "special rows." By this I mean rows in a table that the rest of your system will rely on the presence of to build up behavior.

All rows in an enum table are like this, but you will also end up with rows in tables of otherwise normal "generated during the course of normal use" rows. For these, give them a special system_id.

Unique indexes don't mind multiple rows with null values, so you can make a unique index on this system_id and look up your special rows later as you need to.

CREATE TABLE vet.contact_info(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    person_id uuid references vet.person(id)
                on update restrict
                on delete restrict,
    mailing_address text not null,
    system_id text
);

CREATE UNIQUE INDEX ON vet.contact_info(system_id);

-- Not hard to imagine wanting to build functionality that
-- automatically contacts the CDC for cases of rabies or similar,
-- but maybe every other bit of contact_info in the system is
-- for more "normal" purposes
INSERT INTO vet.contact_info(system_id, mailing_address)
VALUES ('cdc', '4770 Buford Highway, NE');

Use views sparingly

Views are amazing and terrible.

They are amazing in their ability to wrap up a relatively complex or error-prone query into something that looks basically like a table.

They are terrible in that removing obsolete columns requires a drop and recreation, which can become a nightmare when you build views on views. The query planner also seems to have trouble seeing through them in general.

So do use views, but only as many as you need and be very wary of building views on views.

CREATE TABLE vet.prescription(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    pet_id uuid not null references vet.pet(id)
             on update restrict
             on delete restrict,
    issued_at timestamptz not null,
    -- Instead of deleting a prescription,
    -- explicitly mark when it was revoked
    revoked_at timestamptz
);

CREATE INDEX ON vet.prescription(revoked_at);

-- There are pros and cons to having this view
CREATE VIEW vet.active_prescription AS
    SELECT
        vet.prescription.id,
        vet.prescription.created_at,
        vet.prescription.updated_at,
        vet.prescription.pet_id,
        vet.prescription.issued_at
    FROM
        vet.prescription
    WHERE 
        vet.prescription.revoked_at IS NULL;

JSON Queries

You might have heard that Postgres "supports JSON." This is true, but I had mostly heard it in the context of storing and querying JSON. If you want a table with some blob of info slap a jsonb column on one your tables.

That is neat, but I've gotten way more mileage out of using JSON as the result of a query. This has definite downsides like losing type information, needing to realize your results all at once, and the overhead of writing into json.

But the giant upside is that you can get all the information you want from the database in one trip, no cartesian product nightmares or N+1 problems in sight.

SELECT jsonb_build_object(
  'id', vet.person.id,
  'name', vet.person.name,
  'pets', array(
    SELECT jsonb_build_object(
      'id', vet.pet.id,
      'name', vet.pet.name,
      'prescriptions', array(
        SELECT jsonb_build_object(
          'issued_at', vet.prescription.issued_at
        )
        FROM vet.prescription
        WHERE vet.prescription.pet_id = vet.pet.id
      )
    )
    FROM vet.person_pet
    LEFT JOIN vet.pet 
      ON vet.pet.id = vet.person_pet.pet_id
    WHERE vet.person_pet.person_id = vet.person.id
  ),
  'contact_infos', array(
    SELECT jsonb_build_object(
      'mailing_address', vet.contact_info.mailing_address
    )
    FROM vet.contact_info
    WHERE vet.contact_info.person_id = vet.person.id
  )
) 
FROM vet.person
WHERE id = '29168a93-cd14-478f-8c70-a2b7a782c714';

Which can net you something like the following.

{
  "id": "29168a93-cd14-478f-8c70-a2b7a782c714",
  "name": "Jeff Computers",
  "pets": [
    {
      "id": "3e5557c0-c628-44ef-b4d1-86012c5f48bf",
      "name": "Rhodie",
      "prescriptions": [
        {
          "issued_at": "2025-03-11T23:46:18.345146+00:00"
        }
      ]
    },
    {
      "id": "ed63ca7d-3368-4353-9747-6b6b2fa6657a",
      "name": "Jenny",
      "prescriptions": []
    }
  ],
  "contact_infos": [
    {
      "mailing_address": "123 Sesame St."
    }
  ]
}

You can find all the setup you'd need to do for that query here. You can try it out on https://onecompiler.com/postgresql if setting up a local postgres is a bit much.

If there is something I missed or got wrong, tell me very loudly in person or here on the internet.

<- Index

The title is a ? -> ! of this recent thread on Reddit and really a continuation of this series of posts (1, 2, 3, 4).

So first I am going to go over a few of the Maven/Gradle alternatives listed in that Reddit thread and explain why they don't really scratch the itch I think we need scratched, give a small status update on what I've been working on, and end with something that you the reader (yes, you!) could help me with.

I am also going to be terse, biased, and perhaps a bit too harsh. Otherwise, this would drag on and not be an entertaining read.

What do I want?

I want there to be a smooth on-ramp from java src/Main.java to running that program with dependencies, packaging it up to share with other people, and making use of the tools that come with Java (jlink, jpackage, etc.) and available in the Java ecosystem (junit, mapstruct, etc.) Ideally there should be a way to split dependencies over the --class-path, --module-path, and all the other paths as well.

Importantly I don't care, and I think the people who most need this on-ramp don't care, about maximal efficiency. Whoopty doo basil, you can incrementally compile a 100 million line codebase. Fart noises.

Ant

Easy one out-of-the-way first, Ant. Ant is a cross-platform scripting language with targets. It's just but you write XML.

By itself it doesn't handle dependencies at all and outsources that to Ivy. This is a second XML file and, once you've filled it out, it downloads jars to a folder.

Even if you are an Ant-head there is a problem in that to use Ivy you are expected to be using Ant. Ant makes sense if you start by compiling code with javac, but that's no longer a thing you need to do. So the path from java src/Main.java isn't great.

One thing Ant has going for it is that it is clear how to use built-in tools. It loses points in my book though because the arguments you'd give to its tasks don't match up that closely to the arguments you would pass to the command line tools. For example, compare the javac task to the man page for javac itself.

Ivy also dumps jars into a single folder. This means it isn't exactly easy to put a few dependencies on the --class-path and others on the --module-path.

Scorecard

• 🔴 Clear path from java src/Main.java
• 🟡 Clear path to making use of other tools
• 🔴 Split dependencies across different paths

Mill

Mill is a Scala build tool. Scala is a programming language with a history of breaking changes and higher kinded types.

This is the example Mill program for a "simple Java program."

package build
import mill._, javalib._

object foo extends JavaModule {
  def ivyDeps = Agg(
    ivy"net.sourceforge.argparse4j:argparse4j:0.9.0",
    ivy"org.thymeleaf:thymeleaf:3.1.1.RELEASE"
  )

  object test extends JavaTests with TestModule.Junit4 {
    def ivyDeps = super.ivyDeps() ++ Agg(
      ivy"com.google.guava:guava:33.3.0-jre"
    )
  }
}

So very similarly to Ant, this jumps straight into building code. To understand what is happening here you need to understand Scala - an entirely separate programming language from Java. It uses a Task monad, which is like a burrito, to track what tasks depend on other tasks.

It is also very fast, a property I will reiterate I do not care about.

For built-in tools Mill bundles modules, like its JlinkModule, which implicitly give access to the functionality provided. This has a very similar problem to maven plugins in that the distance between "what command is actually run and when" and "what you actually specify" is relatively large.

Let's say you wanted to compile some .xsd files into Java classes with xjc. Perhaps a little niche nowadays, but how would you do it? Are you falling back to ProcessBuilder? Are you learning how the Task monad works?

As for splitting things over multiple paths, a quick look at that JlinkModule shows that its just reusing the --class-path for both the --class-path and --module-path.

val classPath = jars.map(_.toString).mkString(sys.props("path.separator"))
val args = {
  val baseArgs = Seq(
    Jvm.jdkTool("jmod", this.zincWorker().javaHome().map(_.path)),
    "create",
    "--class-path",
    classPath.toString,
    "--main-class",
    mainClass,
    "--module-path",
    classPath.toString,
    outputPath.toString
  )

  val versionArgs = jlinkModuleVersion().toSeq.flatMap { version =>
    Seq("--module-version", version)
  }

  baseArgs ++ versionArgs
}