👍 looks like a good start but the PR feels incomplete.

my idea about supporting jakarta/javax.servlet at the same time would have been converging towards moving all .rb bits that script the javax.servlet API into .java and than potentially use some kind of a weaving approach or the "migration" tool than Tomcat has to release 2 artifacts from the same build... 🤷

Exciting! This will obviously need to be rebased on master due to recent updates there, but I'm glad you've attempted this work.

This would be a breaking change probably requiring a 1.3 or 2.0 release.

use some kind of a weaving approach or the "migration" tool than Tomcat has

I would tend to lean toward a hard version move as a 2.0 release myself.

The old javax.servlet users have to be dwindling pretty fast these days. If we continued to maintain a 1.x line for a while that supports javax.servlet and provided 2.x for jakarta, we'd avoid any complex build situation and everyone would still be able to keep working with what they have. We might start dropping some deprecation warnings into the 1.x line at some point.

@kares Are you opposed to this clean break, branching off 1.2.x and releasing a 2.x that uses only jakarta packages going forward?

@kares Are you opposed to this clean break, branching off 1.2.x and releasing a 2.x that uses only jakarta packages going forward?

Not at all, just shared my personal opinions, think some folks might still be stuck with older versions here and there due "legacy" (enterprise) reasons. Thus was thinking about ways to support both wout having extra work (such as backports).

I am very happy to see any effort such as this one (a full API rewrite) to keep the jruby-rack project going.

Regarding this PR my only concern is that some methods feel like stubs and should be revisited implementation wise according to the servlet specification.

Another option would be a new named gem that is jakarta-rack or something, but there may be transitive dependency issues getting RubyGems/Bundler to pick that up.

Thanks for all the comments. The branch is now synced with the latest master code.

Regarding this PR my only concern is that some methods feel like stubs and should be revisited implementation wise according to the servlet specification.

I'm not an expert in java, so I don't know what the implementation should be. In most places I've just updated javax with jakarta and added those stubs as per the errors I've encountered. Anyone wanting to update those methods is welcome.

We're still some way away from being able to merge/release something like this given we haven't yet released 1.3.x and this would be another breaking change, however I have merged from master and fixed some quick win test problems with the PR.

Right now the remaining (unit) test failures are missing class name jakarta.servlet.http.HttpUtils which is due to reliance on a deprecated utility from the old Servlet APIs which has finally been removed in 5.x onwards. After that I suspect there may be some other issues to resolve with the functional tests with Rails.

Temporarily propagated the removed javax.servlet.HttpUtils#parseQueryString into jruby-rack's code and at least the tests are all passing now.

To get this over the line, we probably mainly need to

• be somewhat comfortable 1.2.4 is stable in various folks' setups so we don't have to actively maintain 3 branches.
• get 1.3.0 out (pretty close I think)
• decide what 2.0.0 looks like, other than this change

Ideally we'd also have some stronger Rails regression tests reinstated to bring more confidence in these bigger releases, but that's probably a nice-to-have.