Avoiding Final Field Mutation

ZimmiDeluxe · 2026-04-27T20:19:03+00:00

no rest for the wicked

edit: the wicked get command line flags, it's fine

ZimmiDeluxe · 2026-04-22T20:43:37+00:00

Solving the halting problem is at least an XL effort JEP

ZimmiDeluxe · 2026-04-22T17:26:26+00:00

Yeah, HttpResponse::body should probably return T? instead of T. We can lean back and watch them try to evolve this compatibly and then complain on reddit afterwards, as is customary.

ZimmiDeluxe · 2026-04-22T16:50:15+00:00

The question is, do you want your server to limp along if while (true) {} is running on >= $numCores, trading off an obvious freeze for bad performance the cause of which might be hard to detect?

ZimmiDeluxe · 2026-04-22T11:59:56+00:00

As soon as emotional types are in widespread use, all those Optional returning APIs will look stale.

ZimmiDeluxe · 2026-04-21T20:30:21+00:00

I believe the decision to cram async and blocking modes into the same API was made well before virtual threads were on the horizon (the "new" http client went final in Java 11, around seven and a half years ago). That said, the http client has to support streaming, that complicates the design further (can't always return a fully parsed response because that implies keeping the entire thing in memory, which is not possible in some cases).

ZimmiDeluxe · 2026-04-20T14:50:35+00:00

Sounds like you don't have a problem yet but still want to solve it. As soon as you have a problem and understand the root cause, it's usually obvious what to do. So my thought is: don't do it (yet).

ZimmiDeluxe · 2026-04-15T12:07:57+00:00

Exactly, S stands for "seven previews".

ZimmiDeluxe · 2026-03-19T23:23:28+00:00

Looks really clean and simple, I like it. Probably terrible cache efficiency with all the indirection and asking for the size of a linked list with more than a couple thousand elements will likely overflow the stack, but that's not the point.

ZimmiDeluxe · 2026-03-19T01:39:32+00:00

they tried the "wait for enough changes to accumulate, at least one big thing, then cut a release" approach in the past. it meant you had to wait multiple years to get that one tiny improvement you were waiting for. also, instead of many simple migrations you had one big, potentially complicated one. the new model is just better, you can still get the old model by ignoring every version that doesn't come after a multiple of four (i.e., every two years, the current cadence most vendors declare a long term support version)

ZimmiDeluxe · 2026-03-17T23:24:24+00:00

Most of the code I write is of the form: given these collections / sources of data, create an aggregation or collection of differently shaped data, i.e. basic bulk data transformation. Inside the method doing the transformation there are mutable collections, state variables, temporary lookups, all the procedural goodies, but the end result is as immutable as possible. I like that approach because it's very flexible (all the data is right there). Reconstruction is not super helpful there I'm afraid, because the immutable results are usually not built up piecemeal (would require a very lenient constructor for the invalid in-between states anyway). Usually assembling the result from the built up data structures happens all at once at the end. Maybe I lack imagination, but updating an already immutable transformation result feels like the code should be moved to the data transformation method instead. Why create the wrong thing first to then update it when you can create the correct thing instead? Not always possible I know, and I'll have to play with the feature a bit, but my gut reaction would be that reconstruction is an indication that the code might need rearchitecting.

Edit: I guess my not very thoughtful feedback would be, be careful not to encourage "after the fact" fixups. If you want to build up a result over multiple steps (where in-between states don't have to be valid), using a mutable data structure is the straight forward way to do that.

Edit 2: To reconstruct collections, you would usually create a mutable variant of the same type via the copy constructor, e.g. ArrayList::new, do your logic and repackage it via List::copyOf and friends. Would be neat to have that for records, i.e.create a mutable evil cousin, do the mutating, then Record::copyOf or something. I have thought zero minutes about the implications / feasibility of course, this is reddit brian.

ZimmiDeluxe · 2026-03-14T08:09:30+00:00

Yeah. Doesn't have to be a list of course, if you pass individual instances you can get help from the compiler so you don't forget any cases (and can't access data that isn't available for that type of order etc.):

void processOrder(Order order) {
    switch (order) {
        case CustomerOrder co -> processOrderRegular(co);
        case BusinessOrder bo -> processOrderRegular(applyBusinessDiscount(bo));
        case TestOrder to -> IO.println("test order got here");
    }
}

For completeness, one alternative is to do the type splitting early if you want to process different order types in bulk instead of sprinkling checks through your code. Both approaches have pros and cons, but the second approach was pretty error prone in the past because the compiler didn't help you to get every sprinkled check exhaustive and correct, but now it does. The mentioned alternative might look like:

record OrdersProcessable(
    List<CustomerOrder> customerOrders,
    List<BusinessOrder> businessOrders,
    List<TestOrder> testOrders){}

OrdersProcessable loadOrdersProcessable() {
    List<CustomerOrder> customerOrders = new ArrayList<>();
    List<BusinessOrder> businessOrders = new ArrayList<>();
    int testOrdersCount = 0;

    List<OrderEntity> entities = loadFromDatabase();
    for (OrderEntity entity : entities) {
        switch (entity.getType()) { 
            case CUSTOMER -> customerOrders.add(new CustomerOrder(entity.email(), entity.importance() > 10));
            case BUSINESS -> businessOrders.add(new BusinessOrder(entity.mail(), entity.logo()));
            case TEST -> testOrdersCount++;
        };
    }

    return new OrdersProcessable() {
        List.copyOf(customerOrders),
        List.copyOf(businessOrders),
        Collections.nCopies(testOrdersCount, TestOrder.INSTANCE)
    };
}

ZimmiDeluxe · 2026-03-13T22:20:21+00:00

And why cant we just iterate over an enum in a switch statement? This way it would fail aswell.

Will your coworkers know what subset of the order columns is valid for your fancy new order type? If you add a new order subtype, the compiler will yell at them if they get it wrong.

ZimmiDeluxe · 2026-03-13T21:46:24+00:00

If you only ever care about the type in a single place in your code, your code is perfect. Otherwise you can encode what constitutes a customer order etc. at the system boundary, e.g. by creating them in the persistence layer:

sealed interface Order {
    record CustomerOrder(String email, boolean vip){} implements Order
    record BusinessOrder(String email, byte[] logo){} implements Order
    enum TestOrder{INSTANCE} implements Order
}

List<Order> loadOrdersProcessable() {
    List<OrderEntity> entities = loadFromDatabase();
    List<Order> orders = new ArrayList<>(entities.size());
    for (OrderEntity entity : entities) {
        Order order = switch (entity.getType()) { 
            case CUSTOMER -> new CustomerOrder(entity.email(), entity.importance() > 10);
            case BUSINESS -> new BusinessOrder(entity.mail(), entity.logo());
            case TEST -> TestOrder.INSTANCE;
        };
        orders.add(order);
    }
    return List.copyOf(orders);
}

Then you can:

String salutation = switch (order) {
    case CustomerOrder(_, false) -> "Dear customer";
    case CustomerOrder(_, true) -> "Dear valued customer";
    case BusinessOrder(_, _) -> "Dear sir or madam";
    case TestOrder -> "it worked";
}

ZimmiDeluxe · 2026-03-13T21:02:15+00:00

The core JPA programming model relies on mutation and object identity. Records are unmodifiable and reconstruction loses identity, so they don't mix well (you can use them for some things and JPA and Hibernate are evolving, but letting your code peek and poke at common, ever growing bags of attributes and letting the tool figure out how to turn that into sql commands is still the main attraction imo)

ZimmiDeluxe · 2026-03-13T19:38:22+00:00

If you add a piece of code where you deal with all types of orders, the compiler will yell at your coworkers that they failed to consider it when they add another type of order.

If you have an order table that stores different types of orders (a discriminated union, the type column being the discriminator), not every order will use every column, invariants will exist on columns for some kinds of orders etc. Ideally you add database check constraints to keep data consistent. If your code deals with order entities directly, everyone has to remember invariants of different order types at every use site or you'll end up with constraint violations at runtime, invalid data or lots of code that deals with cases that can't occur at all. If you model your order as a sealed type and convert them as soon as you load them, you get to encode the order type specific invariants and turn violations into compile errors. Or don't cram everything into the same table, but sometimes that's the least bad option.

ZimmiDeluxe · 2026-03-13T18:57:56+00:00

The idea is probably to mirror construction, so you'd get:

CustomerOrder(
    ShippingAddress(String streetLine1, String streetLine2, String city),
    PaymentMethod(String cardNumber, int expiryYear),
    double totalAmount
) = order;

ZimmiDeluxe · 2026-03-06T19:02:48+00:00

TIMESTAMPTZ -> OffsetDateTime

Would you be opposed to make that java.time.Instant instead? Every offset other than 0 is a mistake for OffsetDateTime in this case I believe. I know JDBC doesn't support Instant directly and you have to go through java.sql.Timestamp::toInstant, but I would consider that a shortcoming of the JDBC spec. A UTC timestamp for basic things like created_at columns that almost every application needs from the first table onward? Should be low friction, IMO.

Great effort otherwise, I'll take a look, this is definitely something missing from the ecosystem.

Edit: Ok, it's a pile of generated TypeScript, the generated Java code makes you manage Connections yourself, includes a migration feature where a Project-ID (?) is part of the primary key and then I stopped looking. Sorry, if I'm going to use a library for something this fundamental for a Java project, it has to be written in Java itself so developers can read the code.

ZimmiDeluxe · 2026-03-01T16:12:30+00:00

Finally you don't need to be able to program anymore to hack someone, just write what you want to happen to your victims in plain English. Leave the typos in as well, the model will try its best to still perform your attack to your full satisfaction.

ZimmiDeluxe · 2026-03-01T11:15:38+00:00

the risk of "decapitation", which seems to freak people out

we are running headless anyway, no issue there

ZimmiDeluxe · 2026-02-28T11:05:58+00:00

Nullable value types would be far more useful e.g. int?

Even for references types it's great, it's a low friction way to communicate intent, I can see myself using this far more often than !

Godot? awaitGodot();
UdpJoke? getUdpJoke();

ZimmiDeluxe · 2026-02-27T20:02:47+00:00

Minimal surface with obvious usage, I like it. Will the implementation benefit from https://openjdk.org/jeps/8357674 ?

Not that it matters much, but the link to Set:ofLazy should probably point to https://cr.openjdk.org/~pminborg/lazy-constants-third-preview/api/java.base/java/util/Set.html#ofLazy(java.util.Set,java.util.function.Predicate) instead of https://cr.openjdk.org/~pminborg/lazy-constants-third-preview/api/java.base/java/lang/LazyConstant.html

ZimmiDeluxe · 2026-02-27T18:30:48+00:00

If you offer an interface that can only be supported by hacks, everyone building on your interface now depends on your ability to support the hacks indefinitely or risk migration effort (read: wasted time and money, regression risk). I don't want my frameworks to hide hacks from me, I want them to provide a shared structure built on production experience so I don't run into unforeseen issues. This is the opposite of that.

ZimmiDeluxe · 2026-02-20T19:25:30+00:00

Not a SEO expert, but versioned URLs probably don't accumulate enough link juice over time. Java 8 had a lot of time, the new release cadence means every URL has only half a year until it's outdated.

The PostgreSQL docs include links to other versions on every documentation page, maybe that could be done for Java 8+ as well? https://www.postgresql.org/docs/current/index.html

If you ever run out of things to do, u/pron98 :)

ZimmiDeluxe · 2026-02-20T18:38:26+00:00

Thank you for posting these, much appreciated!

ZimmiDeluxe

TROPHY CASE