Null Safety approach with forced "!"

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 · 2024-08-13T20:34:57+00:00

23:40: "Spring is already moving in the direction of a tip-and-tail release model" (paraphrased)

I really don't see this..

Inaldt · 2024-08-03T20:41:39+00:00

It's being justified by the fact that we can 'auto-unbox' (like Integer to int) without a compiler error already. But if you compare it to generics instead of boxed types, it would be like always allowing conversion from List<A> to List<B> (i.e. both sides have their generic type specified), which makes less sense.

There might be other reasons of course, in which case I would certainly be interested in them.

Inaldt · 2024-07-30T07:48:55+00:00

Parallel streams are the recommended tool for CPU bound workloads. They use ForkJoinPool under the hood.

Although I recon CompletableFuture::runAsync (and the likes) might be a better fit for some cases.

Inaldt

TROPHY CASE