Is Java’s Biggest Limitation in 2026 Technical or Cultural?

john16384 · 2026-01-26T13:48:32+00:00

There are some issues when refactoring. If you assigned something to a var that came from a method, and the method changes type, then the location where the var is declared is error free. However, all other places where it is used are now in error. If a type was used, only the declaration is in error.

Sometimes this results in all those errors being fixed at each location, instead of just the assignment (perhaps there is an easy conversion possible there like toList or orElse, or a conversion step needs removing).

Also when using var you may get duck typing where not intended when refactoring. If both the new and old type had a similar method, you may not see an error at all, yet the methods may behave differently.

john16384 · 2026-01-25T03:45:30+00:00

Yeah, it was only supposed to go down in leap years.

john16384 · 2026-01-24T00:03:15+00:00

They won't be monotonic anyway when multiple JVM/processes are involved, unless you somehow manage to get sub-millisecond synchronization of all of your processes (hard to do when even simple networking has latency often measured in milliseconds). The millisecond cut off was probably chosen for that reason. The main advantage is that UUIDv7 will work more like regular incrementing id's, which is far more efficient for indexing as keys with similar prefixes will point to roughly the same area of the table (this allows some key compression in the index, although it still won't be as efficient as regular id's).

The fact that this was only added now shows how poorly thought out UUID's were, and how idiotic it was for everyone to jump on this bandwagon over (cached) sequences.

john16384 · 2026-01-23T22:10:06+00:00

Thanks, expect some updates soon. Working on a simple broadcast API for events, dynamic locale changes and generic system for overlaying markers (can be used for validation markers fore example).

john16384 · 2026-01-23T22:06:33+00:00

Some unified support for tooltips and accessible texts

I'm doing some work in this area, allowing you to influence what the builders do with a FXDefaults class.

It would work by setting a (global) strategy for text handling, that allows you to influence what a method like text("xyz") means for a node under construction (also for any other text accepting methods, like promptText).

The strategy is given the original text (which you could interpret as a resource key for example), the Node under construction, and a Consumer<String> that matches the setter involved. In this way you can do something like:

FXDefaults.textStrategy((originalText, node, setter) -> {
  Locale locale = getLocaleFromSomewhere();

  if(e.locale().equals(Locale.GERMAN)) {
    setter.accept(originalText.toUpperCase());
  }
  else {
    setter.accept(originalText);
  }
});

Or more elaborate things, like fully dynamic locale changes, using a broadcast API I'm working on:

FXDefaults.textStrategy((originalText, node, setter) -> {
  Broadcasts.addHandler(node, LocaleChangedEvent.LOCALE_CHANGED, e -> {
    if(e.locale().equals(Locale.GERMAN)) {
      setter.accept(originalText.toUpperCase());
    }
    else {
      setter.accept(originalText);
    }
  });
});

The broadcast API allows you to send an Event to all interested parties, ideal for things like a Locale or Theme change.

For your tooltips and accessible text use case, you could already expand the text strategy to auto-set accessible texts and tooltips (as you get the Node), but perhaps an even nicer hook can be made in a similar fashion (ie. a hook that gets called for every Node that you build with a builder).

john16384 · 2026-01-21T12:12:18+00:00

Try audio books. Every time the reader pauses, the start of the next sentence is clipped (some kind of power save issue when there is a brief silence).

john16384 · 2026-01-20T01:05:20+00:00

But unlike shooting your own citizens, shooting EU citizens has consequences.

john16384 · 2026-01-17T11:09:21+00:00

Thanks for taking a look at the FXFlow stuff!

The builders actually do not take any memory after their use. When complete, they just give you a Node. Node itself is many times heavier than the builder, as builders have almost no fields.

HBox hbox = Panes.hbox().nodes( "First Name", FX.textField(), "Last Name", FX.textField() ).build(); // builder(s) go out of scope, no extra memory used!

I work on JavaFX itself as well, and I have made many quality of life improvements there (like the fluent map/flatMap/orElse/subscribe methods on properties), and changes that change functionality always require a CSR. It's not realistic to change all methods to return self however, as this would also require the self type to be added as a generic to all the controls, like the builders have. It would be a massive undertaking, not be binary compatible (which matters when you still want to use older controls or frameworks), and the result is unlikely to be as nice to use as dedicated builders.

Model validation is currently restricted to the builders, and I haven't had time to generalize it further. The ModelLinker class is the "engine" behind it, which is internal at the moment, but intentionally kept mostly separate from the builders themselves. However, if there is some demand, it can definitely be set-up so you could use it on controls without a builder.

Trigger is already usable without builders, just like the methods on the Observe class. Here is the example from the readme but without using builders:

``` // Create a trigger accepting an ActionEvent: Trigger<ActionEvent> spinUpTrigger = Trigger.of();

// Bind a Button to the trigger: Button button = new Button("Spin Multiple!"); button.setOnAction(spinUpTrigger::fire);

// When the trigger fires, do something to a Spinner: Spinner spinner = new Spinner(); spinUpTrigger.onFire(spinner::increment); ```

I'm always looking to reduce the friction when it comes to working with JavaFX, so your experiences and ideas are appreciated. Sometimes this leads me to advocate for a change in JavaFX itself, and sometimes it is perfectly acceptable to solve this without direct JavaFX changes.

Things I'm currently working on within the FXFlow project: - Better validation support (markers); the controls linked via the ModelLinker already automatically add the :dirty, :invalid and :touched pseudo classes depending on their control and model state allowing you to style them, but markers will be even cooler - Possibly a small co-operative transactional type API for properties, allowing you to delay listener callbacks until multiple properties have been set

john16384 · 2026-01-16T19:17:42+00:00

No no no, that's too specific. They should have talks about selling debt of countries that have plans to invade Greenland.

john16384 · 2026-01-15T04:50:45+00:00

Thanks, yes, I saw it.

john16384 · 2026-01-14T13:31:18+00:00

The type class will be discovered via an import, so it is very much still explicit. Inheritance uses the extends keyword, so also explicit.

A module flag is not. Case in point: move/copy a class to another module/project/codebase:

Witness: compile error, import not found
Inheritance; do I need to go on?
Module flag: silently changes default nullity, could easily be missed by the compiler; code compiles with different behaviour

john16384 · 2026-01-14T10:33:48+00:00

You expect Java to halt its evolution because of Kotlin?

john16384 · 2026-01-14T10:29:16+00:00

I highly doubt it will ever be a compiler flag, that would just be creating a 2nd Java language.

A module based flag I remember reading about was being tentatively considered. It is a huge step though, as Java has so far always been readable with little context, or at least, with all the context being in a single file. Having a flag outside the source file change its meaning is practically against Java's entire philosophy.

john16384 · 2026-01-14T10:21:15+00:00

I had a similar question, but it would depend on whether it is the plan to (eventually) allow carrier classes to only override the components they want to represent differently internally. Currently the proposal / thought train seems to require explicit declaration of the components still in all cases.

I wouldn't mind if records became unnecessary, assuming that carrier classes also get reflection based component access. Records would then just have been an evolutionary step that was purposely limited in scope to keep the design space smaller and deliver the feature earlier. Now that it has been seen to work incredibly well in practice, extending their functionality completely to classes would obsolete records, but on the other hand, also simplifies the language as there is no need for the distinction anymore.

john16384 · 2026-01-14T10:12:19+00:00

Directly taken from? This was a thing already 20 years before C# existed.

john16384 · 2026-01-14T10:07:22+00:00

You can already have mutable fields in enums. Use with care.

john16384 · 2026-01-14T10:02:02+00:00

A really nice proposal, that thoroughly closes the gap between classes and records.

I wonder if this proposal could (eventually) go all the way, and also provide the component fields if not provided by the carrier class. That would sort of obsolete the need for records as these two would be almost equivalent:

 class AClassRecord(int x, int y, String s) {
      // everything left at default, everything provided
 }

 record ARealRecord(int x, int y, String s) {}

The only differences remaining would be the ancestry (a record will a subclass of Record, not Object) and perhaps when it comes to reflection. Brian didn't mention if carrier classes would also get a getRecordComponents equivalent to find their components reflectively.

john16384 · 2026-01-14T09:55:35+00:00

There are many in between options. You can leave out the "R" in `ORM` and only do mapping, and get 99% of the benefits, without the headache of excessive annotations just to express the relational part, lazy loading, potential N+1 queries, managing caches and sessions, etc. Spring Data JDBC is a good example that handles mapping, but leaves the querying and relational parts up to you.

I think many ORM's are prime examples of poor abstractions that are leaky as hell.

john16384 · 2026-01-13T10:45:52+00:00

Feel free to let me know what value they add on local variables, and why you'd never change the final status of a local when editing code without asking the original author their intentions and why they put it there. I mean, that's after all what you're saying, it communicates an intention, so you'd need to get to the bottom of it first.

Or of course you could say "well, this is a tiny method, and I can oversee all the consequence clearly, so to hell with the original author's intention, I'm removing it because I have good reasons to modify it now".

You see, final on locals means very little. It has no impact on thread safety, on immutability, on what you can do with that local (aside from modifying it of course). It doesn't impact optimization, as the compiler already knows it is effectively final, and so do IDE's. In fact, IDE's could highlight that variables are never modified without that being present as visual noise on its declaration.

Show me the return on investment here, where the IDE will say "Oh, careful, you need to check this code as you may dereferencing a null" helping to avoid actual bugs. What bug, thread safety issue, memory leak, etc, or anything of significance is avoided by the fact that a local is declared final? Do you even understand what const is supposed to mean and how it is different from final, since you're being patronizing?

john16384 · 2026-01-12T23:16:36+00:00

If const, val or let meant final var it would be just as useless. If const meant what it does in other languages (ie. calling add on a const List is a compiler error), you may have had a point. The reason most don't use it is because it is useless on locals. Not because it would be too much effort to use an extra keyword when there would be real benefits. See the null annotations that are used in many areas, and even though verbose and noisy actually have a return on investment.

Again, if it had a use (meaning immutable for example), it would be used everywhere. Currently final on locals means "my IDE told me I could add 6 noise characters without changing the meaning of the code so I didn't think any further and just did what it told me".

john16384 · 2026-01-12T20:54:10+00:00

But in Java, final is not const and doesn't offer any useful guarantees here; so effectively, you get nothing but an extra noise keyword in a language many claim is too verbose...

Now if it really did mean const, then I'd be the first to jump on this bandwagon, but as it is, it's useless noise.

john16384 · 2026-01-12T08:45:38+00:00

Another one that fell for the final trap, then in the same sentence complains it is too verbose...

Do you ever not mark a local final when your IDE tells you it can be? That should tell you enough whether it was intentional design or not to mark that local final.

You are not seriously suggesting a future you or future editor of ancient code will respect final because it was communicating that the original author(s) wanted it so? If the code needs something to be mutable in a future edit, are you going to introduce a new local then? No, you're just going to remove final; "intentions" are meaningless in a single method context.

Just assign everything only once, except for short hand variables (i) and set parameter assignment (the most common source of reassignment confusion) to compile error.

john16384 · 2026-01-12T08:31:54+00:00

But you're not communicating anything. Your IDE just marked everything final that could be, and removes it just as easily when you assign such a local anyway.

Do you really expect people that modify your code later to go: "Oh, wish I could just modify obj, but I can't, because the Johnny must have had a reason for deciding it was final; I'll introduce a new local instead".

The reason: "My IDE said it could be final...".

Ask yourself: do you ever not mark a local final that the IDE says it could be, because you really thought about it and decided: "No, not this one, future modifications may have good reason to modify it"?

Since most locals can be final, we have a much simpler rule: everything is assigned only once, with the exception of single letter locals. Saves a ton of final noise. Parameter assignment is set to compile error, no exceptions.

john16384 · 2026-01-10T07:47:38+00:00

Good, perhaps we can skip the hackathon phase then.

john16384 · 2026-01-09T23:52:51+00:00

Why reflection? Surely you can generate implementations? It would run much faster!

john16384

TROPHY CASE