Well, it is more effort than you think it is. We only have 3 of us who regularly contribute to this project and all of us have families and full-time jobs. There are 41 different Java source files under 'src/main/java' that would need to be ported. And while we could that initial split easily enough, we almost certainly would need more or less duplicate everything. It's not the initial work that is our concern, but rather then ongoing maintenance. Now instead of fixing something in one place, there are 2 places to deal with it so maintenance becomes almost twice the amount of work even if the change has nothing to do with the Servlet API at all.

However, the bigger drawback that I see is there is at least one direct dependency that I'm aware of (Apache Commons FileUpload) that has a dependency on the Servlet API and I don't think that they've done a drop-in replacement for a version that uses the latest Jakarta Servlet API changed its package namespace from javax.servlet to jakarta.servlet. (I think other packages were changed as well, but none that I aware of.) As an example, ESAPI's DefaultHTTPUtilities.getFileUploads methods (the class that implements the HTTPUtilities interface) calls org.apache.commons.fileupload.servlet.ServletFileUpload which uses javax.servlet.http.HttpServletRequest. AFAIK, there's no replacement for it, and if it is, it probably drags in additional dependencies.

So, no, we've decided that the ESAPI development team is not going to do this. This whole thing by the Jakarta team run by the Eclipse foundation has not given library developers the heads up they need. (For example, we originally had a 2 year deprecation policy before we would actually remove an old interface. We felt that we needed to give our ESAPI clients adequate time to develop alternate versions or workarounds, etc.) But this whole thing has taken us by surprise. And not just us, but many other application developers. I've spoken to 4 or 5 other Java developer team leads where I work and not a single one of them knew this was a problem. I was the first person at our company to become aware of it (or at least, bothered to mention it to upper management.)

That still leaves you with an option though. You could do what you are asking us to do, which essentially would be to fork ESAPI/esapi-java-legacy and spin it off into a Jakarta version. ESAPI is released under a BSD license which is a very liberal FOSS license, so you technically you wouldn't even have to make your changes back to the larger community. Or, if someone wants to come up with some funding to pay 1 or 2 developers to do that, we may be able to find some people (not the 3 of us though). I wouldn't mind providing occasional guidance, but we just can't afford to do this. The 3 of us keep on wanting to dive in and start working on ESAPI 3 (ESAPI/esapi-java) full time, but because of constant bug-fixing and patching, we don't even get a chance to do that. If we take on what you are proposing, I don't think we will ever get to ESAPI 3. (FYI: For ESAPI 3, since it is a change in the major release #, there will be a lot of other breaking changes so we are almost certainly only going to support the Jakarta Servlet API.)