Make HTTPResponse's primary response code non-final

[akumaburn]

In many complex request handlers there may be many points where the underlying response is being written to at different points in the server logic, the current methodology forces these writes to be to a separate buffer instead of to the response object itself.

Currently the primary status code of the HttpResponse class is final (see https://raw.githubusercontent.com/activej/activej/master/core-http/src/main/java/io/activej/http/HttpResponse.java ), this prevents the primary response code from being modified after object creation, the issue at hand is that it may be that certain responses take precedence over others in the request processing chain, the current model seems to force the response object and all its attached variables such as headers/cookies/body to be completely rebuilt just to change this response code.

Is there a particular reason to keep this final?

[eduard-vasinskyi]

Hi @akumaburn

Here are some ideas behind HTTP messages design:

• HTTP message is a hybrid of a builder pattern and an effectively immutable class
• For the purposes of performance and simplicity, we decided not to make a separate builder class, nevertheless, it is worth working with it as a builder that builds the resulting immutable objects
• Adding headers, cookies is an add-only operation, we can't mutate those already added, and it's impossible because under the hood we use optimized data structures
• It also has an ‘ownership’ concept similar to the Rust one, and you can't just make getters in some cases (body streams for example) and the framework manages the ownership of nested objects
• As for DSL syntax, static factory methods like ok200() don't involve creating a response with "empty" code. and making ok200().withCode(500) is somehow not very nice

However, there seems to be no particular reason to make the code field immutable, since it is not used in high-performance loops, etc. Adding a withCode() method is not necessary, as with… methods should only be used when creating instances and there is a static factory HttpResponse.ofCode(code) for that.

If you don't mind, I will close your PR on this issue and make this change myself, since there are some additional prerequisites that must be met for such a setter, like checking the recycling status of the request. By the way, we are planning extensive changes to HttpRequest/HttpResponse in subsequent versions of ActiveJ, so these API changes will become irrelevant.

[akumaburn]

@eduard-vasinskyi I see. That's fine to close the PR.

May I have some idea of the changes planned for HttpRequest/HttpResponse . I'm currently in the process of evaluating the feasibility of migrating a large amount of payara servlet code over to ActiveJ and it would help not to have to re-write everything when the changes are made.

At the very least if we could have some kind of deprecation plan it would be very helpful.

[eduard-vasinskyi]

@akumaburn

We have mostly finished changing the HTTP API in the master branch. You can familiarize yourself with the changes by looking at the last commits in the branch.

[akumaburn]

Edit: I think creating an Instance of the Builder and only building at the moment it is used will solve my issue, so this can be closed.