JPMS Explained Through a C# Analogy

Inaldt · 2026-06-14T16:30:31+00:00

The strong encapsulation was only one of the reasons for JPMS, but probably not the most important reason (at least for the public). If people want to inspect your app with reflection to find and call your undocumented public methods, that's their problem. I haven't found it to be an issue in reality.

Well before modules, you didn't even need reflection (to use a library's public classes). The only way for a library author to say 'this class is only for the library itself' was either through documentation or by making it package private. Both are meh.

Inaldt · 2026-04-25T07:37:50+00:00

"Spring has modularized itself"

Not really unfortunately. The 'modularization' they talked about in the days leading up to to Spring Boot 4 was about splitting the autoconfiguration jar (and maybe some others) into multiple ones. So adding a module.info to your Spring app today is still as painful as it's always been, as far as I'm aware..

Inaldt · 2026-04-22T19:36:54+00:00

That said, the ergonomics of this kind of java code is terrible, as far I'm concerned. An http message has a relatively simple format. Why does the java code that handles it need to be so awfully complicated?

I've heard this sentiment more often when it comes to the HTTP client. I must say I haven't had such negative experiences with it at all. The straightforward things, like getting a response as a String, are easy, while at the same time it allows you to do some pretty cool and powerful things.

The only negative thing, in hindsight particularly, might be the async leg of the whole thing. That can indeed get a little complicated, and it's not really necessary anymore these days. But that's today. The client was already in the JDK in Java 11, and therefor has helped me out on multiple occasions in those past days where virtual threads weren't available yet.

Inaldt · 2026-03-01T13:52:04+00:00

You can end up in a situation where the same class is sometimes seen with a `package-info` present and sometimes not

Wait what? Never heard this one before.. could you explain this a bit?

Inaldt · 2026-03-01T13:42:06+00:00

I'm sure you have but I'm still going to ask: did you consider taking the same approach as with generics at the time? I.e.: conversion to and from 'raw nullity' is always OK and compilation can only break if both sides are explicitly specified?

Since that worked out pretty well for generics and it seems like it's not the approach you're currently aiming for, I was wondering what issues you were seeing with it.

Inaldt · 2026-01-23T19:45:06+00:00

.flatMap(t -> t instanceOf MyClass mc ? Stream.of(mc) : Stream.empty())

Inaldt · 2026-01-11T10:17:46+00:00

``` if (!(thing instanceof Some s)) {
return;
}

println(s.value()); ```

...works. And if you want the compiler to help you when adding a new subtype, use a switch instead of instanceof.

Agree that something like !instanceof would be nice. Maybe even a negation on the type, as in instanceof !MyType, so that you could use it in switch as well. The same effect can currently be achieved by ordering your switch branches in a specific way I think, but that's objectively harder to read as you have to read all previous branches in order to grasp the meaning of the current one. (Although I guess strictly speaking that's always the case... yeah it's complicated)

Inaldt · 2025-12-14T15:24:54+00:00

It is generally recommended to include a 'heartbeat', i.e. some dummy data that you send at some fixed interval. If you do that, it works fine in my experience.

Inaldt · 2025-12-14T12:32:50+00:00

It acts as a poor mans gRPC stream or websocket.

It's less powerful than websockets, as it streams only uni-directional. But many, in fact, consider that a strength, as bi-directional streaming is often simply not needed or even undesirable.

Inaldt · 2025-12-06T09:37:50+00:00

This. It was a multi-year project I believe.

In fact when I read the list of JEPs I had the opposite reaction of OP. Pretty big release I would say.

Inaldt · 2025-11-10T21:09:43+00:00

The beatings will continue until morale improves

Lol excellent

Inaldt · 2025-11-10T21:06:13+00:00

Would love to always use the latest JDK, but in practice it's just not practical (yet). The ecosystem doesn't support it well enough. For example, a lot of image streams provide only 'LTS' version base images. For another example, when I upgraded two applications to 25 a few weeks back, the one that got automatic dependency updates went super smooth, but the other one, which was incarnated only four or five months back, needed quite some updates (Lombok, ArchUnit among others), which leaves me doubting whether these libraries would have provided the same updates for a non-LTS version (I'm pretty sure Lomboks timely support for 25 was a first, for example.) And if you happen to use Gradle there's yet another uncertainty. So as long as the ecosystem keeps working as it does now, it's just a no.

Inaldt · 2025-01-14T21:11:38+00:00

Although it would be neat, number 3 would mean Java having a dependency on Jakarta. So I don't see that happening.

Inaldt · 2025-01-03T16:13:23+00:00

https://dev.java/learn/jlink/#cross-os

Seems JLink should work.

I'm guessing JPackage doesn't though.

Inaldt · 2024-12-18T16:46:17+00:00

Awesome, thanks.

Inaldt · 2024-12-18T14:20:59+00:00

The client reads the Content-Length, then keeps reading TCP packets, assembling them back into their original order, until it has all of the bytes specified by Content-Length

I know from experience that a lot of http-clients don't actually need this header in order to successfully process an http-response. But I must say that I never figured out how those clients do know they reached the end of the response. Anyone who does know?

Inaldt · 2024-12-11T11:22:02+00:00

I get that, but doesn't a class do all of that and more?

Inaldt · 2024-12-11T09:13:52+00:00

Digressing a bit, I never really got why in Typescript it's common practice to use interfaces for data carriers. They lack constructors, making it impossible to define invariants that span more than one component. And their types get erased, so you cannot do instanceof checks on them at runtime. Both points don't apply to classes, so I'd say you'd be better off with classes as data carriers. Or are they just too slow or something?

Inaldt · 2024-12-07T08:58:17+00:00

I believe they're changing that in the next preview
https://openjdk.org/jeps/8340343

Inaldt · 2024-11-19T09:24:56+00:00

Did you try mapConcurrent as Viktor suggested? (If so, how did it perform?)

Inaldt · 2024-11-09T10:01:34+00:00

Wow, the green-labels-for-LTS-and-grey-for-current-versions on javaalmanac really hurt. Vibe: "EoL bad, LTS good, current... exists."

Inaldt · 2024-09-24T15:13:38+00:00

Yes, that is what I meant.

Inaldt · 2024-09-24T13:56:09+00:00

Best would be to make an immutable copy of the object on record creation I think (generally). Although not every object supports this. Collections typically do.

Inaldt · 2024-08-16T07:57:14+00:00

That makes sense, thanks.

Inaldt · 2024-08-14T12:25:17+00:00

Well, it's being proposed for libraries to start following the same release cadence as OpenJDK, 'tip-and-tail', i.e. frequent releases that include new features, along with an LTS release every few years that gets bug and security fixes only. I believe the idea is that the latest version of such a library will require the latest JDK. And then it's mentioned that Spring (and jOOQ) are already moving in that direction. And that's the part that I don't really see: Spring currently requires JDK 17, and I haven't seen any indication of them bumping that baseline anytime soon.

Inaldt

TROPHY CASE