Search code examples
javahelidonvirtual-threadsnima

Helidon 4 and Http API

in Helidon 3 and earlier versions there a io.helidon.common.http package https://helidon.io/docs/v3/apidocs/io.helidon.common.http/io/helidon/common/http/package-summary.html

But in Helidon 4 there is a io.helidon.http package instead https://helidon.io/docs/v4/apidocs/io.helidon.http/io/helidon/http/package-summary.html

  1. Is this new http package a replacement for the common.http package and should all use of io.helidon.common.http be migrated to io.helidon.http if we are going to uptake Helidon 4?

  2. Is this new package the result of Helidon use of virtual threads (i.e. Níma )?

Solution

  • Is this new http package a replacement for the common.http package

    It looks like yes, it is. If you look at Níma Maven artefact

    <groupId>io.helidon.nima.webserver</groupId>
<artifactId>helidon-nima-webserver</artifactId>
<version>4.0.0-M1</version>

    then you'll find there helidon-common-http-4.0.0-M1.jar with io.helidon.common.http package in it which is almost (sic!) a full copy of io.helidon.http in helidon-http-4.0.4.jar.

    But not a drop-in replacement! Looks like Helidon authors couldn't care less of such trifles as portability. Although few classes like Forwarded were moved from io.helidon.common.http to io.helidon.http "as-is", some other were reshuffled: for example, Http.Status was moved a separate Status.

    Is this new package the result of Helidon use of virtual threads (i.e. Níma )

    Only indirectly so. If, as the Helidon manual says, the major jump from 3 to 4 is a replacement of asynchronous ("reactive") calls with blocking ones:

    Helidon 3

    request.content().as(JsonObject.class)
        .thenAccept(jo -> doSomething(jo, response));

    Helidon 4

    doSomething(request.content().as(JsonObject.class), response);

    it is indeed a gigantic jump, but it does not warrant, to my understanding, such reshuffling of quite innocent, utility-like package as io.helidon.common.http. Rather, a result of cowboy approach to portability and versions compatibility.

    A word of warning: If you are going to migrate to virtual threads on your production, please be aware of some virtual threads-related deadlock/hanging issues, discussed in Stack Overflow, most reproducible of them is Java Virtual threads and ConcurrentHashMap and especially a case discussed in this answer.