chore(implementation): use Jetty-12.1 core without servlets

[lachlan-roberts]

This is based on the work from #235.

Port the invoker to upgrade to Eclipse Jetty-12 version 12. Specifically using the new core APIs of Eclipse Jetty-12 that allow the overhead of a Servlet container to be avoided.

BREAKING CHANGE: use Java 17 or above, as required by Eclipse Jetty-12.

Replaces

• Port to use Jetty-12 core without servlets #235
• chore(implementation): Use Jetty handlers rather than Servlets #241
• chore(deps): Upgrade to Jetty-10 #244

[ludoch]

Thanks!
We need to remove jdk11 constraints in builds. I guess only a Googler can understand and change the kokoro files to jdk17

Also all references with maven.compiler.source>11</maven.compiler.source> need to change to 17

[ludoch]

For ex, remove https://github.com/GoogleCloudPlatform/functions-framework-java/blob/cd6caeda00262b2558815ae22cfc726c0638122a/.github/workflows/buildpack-integration-test.yml#L17https://github.com/GoogleCloudPlatform/functions-framework-java/blob/cd6caeda00262b2558815ae22cfc726c0638122a/.github/workflows/buildpack-integration-test.yml#L17

Maybe add java21 or 25

[ludoch]

@akerekes please help on google internal kokoro workflows.
The entire new code now has to only work with java17,21 and 25, so drop 11 and add new configs.

[akerekes]

Hi @lachlan-roberts , thank you for the PR! I'll work on the Google internal side. One note on the timeline is that Cloud Function deprecates java11 at the end of the month: https://cloud.google.com/functions/docs/runtime-support#java so my preference is to have this PR ready to merge, but wait until the end of the month with the merge, then do it in early November and release a new version of the FF-java library.

[akerekes]

Thank you @lachlan-roberts for the PR! I did the first round of review.

Please rebase the PR to HEAD one more time, I'm not planning to merge any other PRs until this one is done to avoid further rebasing and merge conflicts.

[maemayve]

Can you add the action item to this TODO? what needs to be done to address this race condition?

[lachlan-roberts]

The race condition is intrinsic to this approach, and was also present using the original TimeoutFilter. And there were also various other problems with the original TimeoutFilter.

I have pushed another commit to improve this.

• Before the timeout was per call to doFilter, it was not measuring the total time for the handling of the request/response to complete.
• It used to create a new Timer for every call to doFilter() (possibly multiple times per request), now it reuses the Scheduler of the server and only once per request.

[akerekes]

@lachlan-roberts Thank you for the follow-up. Can you reformat the code to make the linter check pass?

The PR looks good to me, I'm waiting on @maemayve 's comments to be resolved and happy to approve it then.

[akerekes]

Looks like the timeout behavior change breaks the test, @lachlan-roberts can you take a look?

[lachlan-roberts]

@akerekes yep thanks, the TimeoutHandler was sending a 500 response on timeout not 408 which is required by the test.

Should be passing tests now after latest commit (it passed locally).

[akerekes]

Looks like there's a flakiness in the tests: https://github.com/GoogleCloudPlatform/functions-framework-java/actions/runs/19053493656/job/54419863348?pr=333 which passed on re-run (I'm not sure if the changes in this PR have any effect on it, wdyt @lachlan-roberts ?)

And there are some formatting issues with the code: https://github.com/GoogleCloudPlatform/functions-framework-java/actions/runs/19053493578/job/54419854427?pr=333

[lachlan-roberts]

Looks like there's a flakiness in the tests: https://github.com/GoogleCloudPlatform/functions-framework-java/actions/runs/19053493656/job/54419863348?pr=333 which passed on re-run (I'm not sure if the changes in this PR have any effect on it, wdyt @lachlan-roberts ?)

To me this looks like a race condition in the test.

The main thread is sending a request to the server, waiting for the response, then checking the server logs to see if the required output is there.

But those server logs are made available in a StringBuilder by a different thread which is continually reading from the server process InputStream.

So just because the response is received doesn't mean the log lines are in the StringBuilder yet.