Skip to content

Replace unmaintained com.sun.activation:jakarta.activation with jakarta.activation-api + Angus Activation (or eliminate the dependency) #2190

Description

@lhotari

Description

async-http-client currently depends on com.sun.activation:jakarta.activation:2.0.1 (compile scope, declared in the root pom.xml).

This artifact is no longer maintained. As part of decoupling the Jakarta Activation API from its implementation, development of the implementation moved to the Eclipse Angus project: https://eclipse-ee4j.github.io/angus-activation/. The old combined API+implementation artifact com.sun.activation:jakarta.activation saw its last release (2.0.1) in 2021 and will not receive further updates.

Current usage

The dependency is used in exactly one place: org.asynchttpclient.request.body.multipart.FileLikePart uses jakarta.activation.MimetypesFileTypeMap to resolve a content type from a file name, backed by the bundled ahc-mime.types resource.

Option A — migrate to the maintained artifacts

Replace the single dependency with the split API + implementation:

<dependency>
    <groupId>jakarta.activation</groupId>
    <artifactId>jakarta.activation-api</artifactId>
    <version>2.1.3</version>
</dependency>
<dependency>
    <groupId>org.eclipse.angus</groupId>
    <artifactId>angus-activation</artifactId>
    <version>2.0.2</version>
    <scope>runtime</scope>
</dependency>

No source changes are needed: MimetypesFileTypeMap keeps the jakarta.activation package. The runtime implementation is required because in Jakarta Activation 2.1+ the mime-type registry parsing is provided via ServiceLoader by the implementation.

Option B — eliminate the dependency entirely (preferred?)

Since the usage is limited to a simple "file extension → content type" lookup over AHC's own ahc-mime.types file, the dependency could be removed by replacing MimetypesFileTypeMap with a small internal parser/map. This would remove a compile-scope dependency from the classpath of all downstream consumers and avoid Jakarta Activation version conflicts in applications that also use Jakarta Mail/EE.

Related: #1589 previously raised the desire to avoid this dependency.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions