jakartaee / jakartaee/mail-api
Slow performance of MimeUtility
@jmehrens is already working on this.
Since Aug 24, 2026.
- Dominant language
- Java
- Stars
- 285
- Forks
- 109
- Avg merge
- 15h 19m
- Merged PRs (30d)
- 1
Description
Per https://github.com/jakartaee/mail-api/issues/699#issuecomment-3210494290
>This is a problem beyond Multipart. StreamProvider.provider() is littered all over MimeUtility. I see StreamProvider is being reworked in 2.2, so hopefully that rework will remove any classloading-on-each-instantiation from the codebase. With 2.1.3, this causes enormous performance problems parsing encoded headers (among other things).
One implementation I believe will work without pinning a classloader is to:
1. Create StreamProvider delegate.
2. Use java.lang.reflect.Proxy to create a proxy class type in the given classloader for the StreamProvider type. This will have to use current rules for fallback classloading.
3. Create a java.lang.ClassValue which uses the proxy key and computes value by using the existing finder.
4. StreamProvider delegate will only delegate through ClassValue.
Using these things should build a classloader local cache of the stream provider. Just need to prototype and test it.
This would be the preferred implementation used for default session. This could be safety shared to MimeUtility.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.