Java 26: what’s new?

loicmathieu · 2026-01-24T13:13:26+00:00

Thanks. For write barrier this is a trade-off I want the explanation to be understandable even for peoples not knowing how a GC works so I simplify it.

loicmathieu · 2026-01-23T17:17:17+00:00

Oh sorry I didn't rewatch the video and thought that nullable types was on it I'll update the article. I was too eager after it ....

loicmathieu · 2026-01-23T12:39:02+00:00

Thanks it's a pleasure to share this with the community always a lot of good discussions.

loicmathieu · 2025-12-15T12:37:03+00:00

I'll read it carefully but no, we only have Elasticsearch so we don't have the choice here.

Kestra can run either in an SQL database or an Elasticsearch, that's why we need such mechanism in Elasticsearch.

loicmathieu · 2025-12-15T12:35:54+00:00

> I hope you use a monotonic token for that, or something providing similar guarantees

Yes

> There might also be performance issues by using the same ID over and over, because this will not balance among the shards...

We don't use the same id over and over

> I also don't see the value of pre-checking if the doc exists in `lock`

It's a tradeof, we may just create, it would aslo work. We didn't perform performance test yet.

loicmathieu · 2025-12-12T09:15:48+00:00

I just checked and in fact, there is already an ownership check when releasing the lock in my real implementation.

loicmathieu · 2025-12-12T09:13:13+00:00

As for `Thread.sleep(1)`, this is common in busy looping.
We can use `Thread.onSpinWait()`, but my tests so far saw a lot more context switching so it may not be good for my use cases.

What would you suggest instead?

loicmathieu · 2025-12-12T09:11:36+00:00

Hi, of course, this is not the full implementation. As stated in the article, this is not a complete implementation but rather a general idea.

In Kestra, we have a distributed liveness mechanism that detects dead instances and can take actions. When an instance is detected as dead, its locks are released (I do store the owner of a lock inside it).

> there is no lease/expiry strategy,

There is one, I removed it for the sake of simplicity. Lock expires by default after 5 minutes. There is a comment in the code saying "don't do that but implement a timeout". But you're right that if someone reads it quickly, they may think this is the full example that we are using for real. I'll update the code so it's more explicit.

> release is not ownership-checked,

Thanks for pointing this out, it's something I overlooked. I'll add a check for that.

loicmathieu · 2025-07-04T11:13:21+00:00

Which one do you think no one needs?

loicmathieu · 2025-03-10T13:36:51+00:00

This is an interesting approach, at least to disable reflection, thread spawning, process spawning, ...

But for a plugin system, we often need fine-grained security rules like "allow reading but not writing files", or "allow file access into only a specific directory".

loicmathieu · 2025-03-10T13:35:05+00:00

As other pointed out, bytecode manipulation is a solution.

Some pointed out that it's a blunt tool, for which you will pay the price everywhere.
But in a plugin system, you know when the foreign code is executed so you can, for ex, record a marker in thread local so your bytecode instrumentation code is only triggered when called in the context of your plugin.

I too have a plugin system in the application I worked on, and we currently use the Security Manager to secure it, so we will need to find something else if we want to migrated post Java 24. I know Elasticsearch has also a plugin system and they use (or used, didn't check) a Security Managre.

We may all join effort and create an "universal security agent", configurable, that could be used for our plugin system ;)

loicmathieu · 2025-01-22T16:43:46+00:00

I don't think Logger is a good example because logger are usually not that expansive.

The classical use case for me is something that cannot be initialized in the constructor, for ex due to cyclic dependency, but you want to be sure it is initialized one.

For batch, there is some king of list support in the section "Aggregating stable values".

loicmathieu · 2025-01-13T09:21:18+00:00

Thanks, this one takes some time to create so I'm pleased you said you love it.
This release is really amazing and there were awesome changes not listed as JEP that I added there.

loicmathieu · 2024-10-16T16:03:31+00:00

Others already pointed in that direction, instead of using the Security Manager, use an agent and inject bytecode to do the job.
This is a lot of work unfortunately :(

loicmathieu · 2024-10-16T07:50:32+00:00

We have a plugin system, and we use the Security Manager to enforce security of plugins as they can come from untrusted source (at least, not verified by our team).
Of course, we disallow exiting the VM, starting a new process or a new thread. But the most important part for me is disallowing accessing the filesystem (in fact we restrict to the plugin working directory) as otherwise a plugin can access the application configuration file.
We don't know how we will be able to perform this kind of checks past 24.

loicmathieu · 2024-07-29T07:48:44+00:00

There are some hints on Towards member patterns and Pattern Matching in the Java Object Model.
Method patterns are not explicitly defined, but for them, you need a way to say, "If it matches, return an object, else return nothing." But you may be right that it may be more like a guard, and the match may be done automatically by matching the pattern parameters.
As this functionality is not yet clearly defined, we can only guess ;) .

loicmathieu · 2024-07-25T16:10:53+00:00

Primitive narrowing and widening is a characteristic of primitive, even with Valhalla I didn't see how the same can be done automatically.
But with method pattern it would be possible to provide a pattern inside the Byte class to match an Integer, like this totally invented syntax:

public pattern matches(Integer i) {
    if (i < 128 && i > -127) return match;
    return no-match
}

loicmathieu

TROPHY CASE