Inline ...
Hi Joakim,
Thanks for the fast response. Given the drawbacks, what where the reasons for Jetty to bring back support for EE8?
Backward compat for legacy applications is a real thing.
There are many installations of Jetty that do not interface with modern browsers, or are used internally inside of various organizations where the server is not exposed to the public internet.
Those are completely legitimate reasons to stick with ee8, so we don't want to abandon it either.
As part of our analysis, we looked at all other dependencies in our
project. None of them depend on the servlet API. The only consumer of
the servlet API in our system is Jetty itself. To me, that takes away
much of the risk of us not being able to update other dependencies (if
their updated versions have migrated to Jakarta) to pull in security
updates, if we'd choose to stick with EE8.
This is a good analysis, but be aware that many dependencies are optional, not required, or provided by other factors (the environment).
So do be careful to take into account all of the scopes for each dependency, as you might have missed a need (even an optional need) against something in the ee8 space. (even things that ee8 depends on that used to be provided by the JVM but are now only available via extra dependencies that you need to use now just because you are on JDK 17)
Our usage is mostly based on a non-public administrative console that consists of JSPs generating flat HTML (which still uses tables for layout, to give you an idea). There are some public endpoints too, like the ones offering websocket connectivity to our chat solution, as well as some bundled web-applications that implement a chat client. I don't expect us to require cutting-edge browser features anywhere soon though, although I will also admit that I'm not quite in the loop exactly what changes we'd be missing out on. You've mentioned two (Same-Site on Set-Cookie and HTTP/2 push). Does there happen to exist a more or less finite list of 'modern browser thingies' not compatible with EE8?
It would be easier to just have you look at the changes from EE8 to EE11 on all of your EE usages and from there decided what features are important for you to keep up to date.
Note: while the previous statements were focused on the Servlet spec, that is not the only thing in the EE8 tree, so are JSP, EL, JSTL, etc. and those other EE8 specs can have their own changes to address issues from outside of the EE spec (like browser changes, or industry changes to TLS, etc)
Regarding websocket, if you have Safari clients, then you'll want to be aware that there have been recent webkit reported bugs with websocket compression on newer versions of OSX.
We don't have a fix for it, as it appears to be a webkit specific bug, and workarounds for that bug are not feasible.
- Joakim
