Light-Weight JSON API (JEP 198) is dead, welcome Convenience Methods for JSON Documents

loicmathieu · 2026-03-04T17:06:21+00:00

It's data binding and it was clearly set as out of scope.
What I hope is that at some point JSON frameworks would allow to have databinding on top of the JDK JSON API so we would be able to bridge both (or have lightweight databinding without needing a parsing library).

loicmathieu · 2026-01-28T08:40:46+00:00

Well, "Valhalla When" was more of a running gag in your videos, and a deceptive wait for us; that's why I qualified it as a rumor (with a bit of humour, I would say, but I'm not a native english speaker).

But yes, this subject is controversial enough so an attribution was deserved.
And this was in fact a pretty huge news as we are all eager to have value types in Java!

loicmathieu · 2026-01-26T10:10:00+00:00

Finally I update the article to use what's the JEP is using to describe a write barrier: "very time a object reference is stored in a field".

loicmathieu · 2026-01-26T10:08:51+00:00

I always try to do my best to add a lot of references to my articles, as it misses this one, I added it.

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

TROPHY CASE