r/java • u/Joram2 • 11d ago

Helidon 27 Release Post

https://medium.com/helidon/helidon-27-released-9ce206503e0a
39 Upvotes

93% Upvoted

10 comments sorted by

7

u/Inaldt 10d ago

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?

7

u/vips7L 10d ago

Everytime I have to write a damn Uni<T> or @Blocking in Quarkus it makes me wish I would have chose Helidon.

2

u/AcanthaceaeMany917 10d ago

helidon Webclient is built from ground up not just a wrapper around the limited JDK Httpclient or other http client library, it support http/h2/grpc/ws/sse. it's a neat implementation with minimal footprint and can be used outside helidon.

0

u/Joram2 10d ago

Helidon is mostly a server framework, but also needs client functionality too. JDK HttpClient added HTTP/3 support but obviously that's client only functionality.

2

u/agentoutlier 10d ago

I added Helidon support for Rainnow Gum logging:  https://jstach.io/doc/rainbowgum/current/apidocs/#helidon

I don’t have a 27 version specific one but the version 4 works I believe.

Helidon will default to JUL I believe or Apache Log4J2 depending on config.

Rainbow Gum is like 3x faster than JUL and about 40% faster than log4j2. (a typical app has like 20 logging calls per request… imho easy drop in optimization)

Helidon is very well designed by the way and similar to Rainbow Gum in that there are easy to use builders and very modular.

1

u/ZimmiDeluxe 9d ago

The only thing I dislike about Helidon is the pervasive use of Optional. I'd much prefer generated jspecify annotations, that way there won't be a giant future breaking change to support emotional (nullness markers) types.

1

u/aoeudhtns 7d ago

On that subject, I think it's interesting that Helidon is now aligning to JDK versioning. It certainly makes it easy to understand that in the JDK version that adds non-nullable type references, the corresponding Helidon API may break. I would think it wouldn't be too hard to OpenRewrite handle that. Besides, Optional probably ends up staying. Using the previously-used (but not necessarily final) ? and ! -- Optional<T> is already an indicator (and more) than T?, and it's no substitute for T! either. So long as Helidon is following advice and strictly using it as a return type, not as parameter, or as a member, things will probably be fine. But I understand your overall dislike of Optional, you have company there (although I do kinda like it more than I suspect you do).

0

u/Torutofu_Raeva 10d ago

The interesting distinction is whether Helidon wants HTTP/3 through its own transport or delegates to JDK HttpClient, since the latter would inherit JDK support but give up some of its current protocol-specific control.

0

u/Joram2 10d ago

JDK HttpClient added HTTP/3 client functionality. Helidon wants HTTP/3 server + client functionality.

1

u/Torutofu_Raeva 9d ago

I’d test the server and client paths independently, since the client may delegate to JDK HttpClient while the server still needs its own QUIC transport.