u/Inaldt

Good to hear that it works well that way.

I thought there might be interesting learnings here. Like do you get these excellent results by just handing over the jfr file and asking it to analyze it, or do results get much better by using specific models, skills, sandboxes etc.

we get spectacular results when we let AI analyze JFR files

Do you have any tips for how to use/instruct the AI for this use case? I've been doing the analysis by hand so far and I'm certainly interested to see if AI can do better

You're totally right of course, but I also think we have to cut them some slack. Maven is backed only by Apache, unlike the other big build tool, which usually means maintainers either need to do the work for free or for quite a limited compensation. So the people working on Maven - and I think there's only about a handful - probably have 'real' jobs next to it.

It's actually a bit (sort of) like the cliche that half the internet leans on a piece of software maintained by one guy is his spare time.

Either way. It seems they underestimated the amount of work. It's unfortunate but it's what happens in software. Until it goes GA, Maven 3 works just fine.

Everytime I read a Helidon post I get more sad we don't use it.

Some interesting things in this release, notably the blocking messaging API (presumably powered by virtual threads?)

About the work on HTTP/3: since the JDK HttpClient recently got support for it, will Helidon benefit in any way from the work done there?

Absolutely. In fact I wonder why they chose to to start with ZGC, since I'd expect G1 to have many more users.

Consider an option that would enable giving up some performance, or accepting larger AOT cache files, or both, in order to gain portability across processors of the same architecture but with different feature sets.

This would be really nice. With this, I could at least do the training run in my build pipeline.

Yes. Including build systems. Would be way cool if maven started using this.

C# gives you a very lovely syntax with native Async/await

Do you prefer this over goroutines?

Virtual threads are intended for short tasks. So I think that wouldn't be idiomatic. I believe the Helidon web server does it in a similar way, i.e. one (or maybe a few) thread for listening and then handing off the actual work to a virtual thread.

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.

"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..

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.

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?

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.

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

``` 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)

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.

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.

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.

The beatings will continue until morale improves

Lol excellent

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.

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

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

Seems JLink should work.

I'm guessing JPackage doesn't though.

Awesome, thanks.

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?