Hi all,
Prompted by the recent vote on Commons FileUpload 2.0.0-M3, I'd like
to share some thoughts on the evolving role of Commons FileUpload
within the current Java ecosystem.
As many of you know, Servlet 3.0—released in December 2009—introduced
a file upload API[1] that closely mirrors Commons FileUpload 1.x and
covers roughly 99% of its functionality. The resemblance between the
two APIs is so strong that several application servers forked Commons
FileUpload 1.x to implement the new standard.
Given the adoption of the Servlet API, Commons FileUpload 1.x now
mainly serves three roles:
1. Supporting legacy applications that have not yet migrated to
Servlet 3.0 or newer.
2. Enabling `multipart/form-data` handling in web apps that don't
rely on the Servlet API.
3. Offering advanced file upload handling to the small subset of
Servlet API users whose needs exceed what the spec provides.
The new Commons FileUpload 2 major version addresses these use cases
via separate artifacts:
- `commons-fileupload2-core` supports users who do not use the
Servlet API.
- `commons-fileupload2-javax` targets users of Servlet API 4.0 or
earlier (i.e., `javax.*` namespace).
- `commons-fileupload2-jakarta5` targets users of the Servlet 5.0 API.
- `commons-fileupload2-jakarta6` targets users of the Servlet 6.0 API.
While `commons-fileupload2-core` serves a distinct and valid purpose,
the _raison d'être_ of the other three artifacts is less clear.
## Purpose of `commons-fileupload2-javax`
With Commons FileUpload 2 being a major release, I see little value in
publishing the `commons-fileupload2-javax` artifact. Projects still on
Java EE 8 or older can migrate to Servlet 3.0+ or continue using
Commons FileUpload 1.x for now. For those who rely on advanced
features, we could extend support for version 1.x a bit longer rather
than maintaining `commons-fileupload2-javax` for another decade.
If any security issues arise in Commons FileUpload 1.x, I’m personally
willing to address them and issue security updates, at least for as
long as Tomcat 9.x—the last open-source Servlet 4.0 container still
under support—remains maintained.
## Purpose of `commons-fileupload2-jakarta5/6`
While I wouldn’t generally recommend `commons-fileupload2-jakarta5/6`
to most users—who would likely be better served by the built-in
Servlet file upload API—they may be valuable to more advanced users.
That said, I don’t see a strong reason to publish two separate
artifacts for Servlet 5.0 and 6.0. From the perspective of our Servlet
API usage, these versions are effectively identical, and code written
for Servlet 5.0 works seamlessly on a Servlet 6.0 server.
It seems unlikely that any user would maintain two separate versions
of the same application—one for Servlet 5.0 and another for 6.0. So,
why should we maintain two identical `commons-fileupload2-jakarta*`
modules?
There’s another issue with the current implementation of the
`commons-fileupload2-jakarta*` modules: all class names are prefixed
with `Jakarta`, deviating from the naming used in version 1.x. This
makes migration unnecessarily harder than moving between Servlet API
versions:
- Migrating from Servlet 4.0 to 5.0 only requires replacing `javax`
with `jakarta` in package names.
- Migrating from Commons FileUpload 1 to 2 requires users to change
`org.apache.commons.fileupload` to `org.apache.commons.fileupload2`,
*and* adapt to renamed classes.
This added friction could discourage adoption of version 2.
## Conclusions
In light of the issues above, I suggest we:
- Remove the `commons-fileupload2-javax` module.
- Merge the `commons-fileupload2-jakarta*` modules into one.
- Restore the original class names from FileUpload 1.x to ease
migration.
What do you think?
Piotr
[1]
https://jakarta.ee/specifications/servlet/5.0/jakarta-servlet-spec-5.0#file-upload
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
