Mimepull 1.10.0 dependency breaks compatibility with Java 8 for Spring Boot 2.7.0

[symphony-youri]

In Spring Boot 2.7.0, mimepull has been upgraded to 1.10.0 (#30725).
It seems this version has been built with Java 11 (eclipse-ee4j/metro-mimepull#61), making Spring Boot 2.7.0 incompatible with Java 8 if the library is loaded (unless you override the version of course).

For instance, here is the error during the startup of a Spring Boot application using Jersey:

java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.UnsupportedClassVersionError: org/jvnet/mimepull/MIMEConfig has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	at org.glassfish.hk2.utilities.cache.LRUHybridCache.compute(LRUHybridCache.java:292)
	at org.glassfish.hk2.utilities.reflection.internal.ClassReflectionHelperImpl.getAllMethods(ClassReflectionHelperImpl.java:85)
	at org.jvnet.hk2.internal.Utilities.findInitializerMethods(Utilities.java:1400)
	at org.jvnet.hk2.internal.DefaultClassAnalyzer.getInitializerMethods(DefaultClassAnalyzer.java:83)
	at org.glassfish.jersey.inject.hk2.JerseyClassAnalyzer.getInitializerMethods(JerseyClassAnalyzer.java:218)
	at org.jvnet.hk2.internal.Utilities.getInitMethods(Utilities.java:196)
	at org.jvnet.hk2.internal.ClazzCreator.initialize(ClazzCreator.java:121)
	at org.jvnet.hk2.internal.ClazzCreator.initialize(ClazzCreator.java:156)
	at org.jvnet.hk2.internal.SystemDescriptor.internalReify(SystemDescriptor.java:716)
....

[philwebb]

We have a similar situation with Jetty where we pin to v9 because v10+ requires Java 11. Ideally I think we should be consistent and do the same with mimepull, but unfortunately we've already cut the release. I'm now not sure if we should downgrade or not.

Flagging for team attention to see what others think.

[philwebb]

@symphony-youri in the meantime you can try setting the mimepull.version property in your build to downgrade to the previous version.

[wilkinsona]

We don't have any dependencies on mimepull which explains why the upgrade didn't break our Java 8 CI. I wonder if we can just remove dependency management for it.

We added the dependency management to fix a bug in the pom of saaj-impl 1.5.0: #14924.

[wilkinsona]

In Boot 2.7 we depend on saaj-impl 1.5.3 where mimepull's an optional dependency so the problem fixed in #14924 no longer exists. I think we should remove dependency management for mimepull entirely in 2.7.1.

[wilkinsona]

@symphony-youri Can you share details of your application's dependencies? I'd like to understand how mimepull ended up on the classpath so that I can double-check my analysis above.

[symphony-youri]

Sure @wilkinsona, here is an extract of the dependency:tree output:

[INFO] |  +- javax.servlet:javax.servlet-api:jar:4.0.1:compile
[INFO] |  +- org.glassfish.jersey.connectors:jersey-apache-connector:jar:2.35:compile
[INFO] |  |  \- jakarta.ws.rs:jakarta.ws.rs-api:jar:2.1.6:compile
[INFO] |  +- org.glassfish.jersey.media:jersey-media-multipart:jar:2.35:compile
[INFO] |  |  \- org.jvnet.mimepull:mimepull:jar:1.10.0:compile

Our application is using Jersey and one of its dependency is mimepull.

We use Spring Boot dependencies with:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-dependencies</artifactId>
    <version>${spring.boot.version}</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

so I guess because it is part of Spring Boot's BOM it comes with this version and overrides the one from Jersey (https://mvnrepository.com/artifact/org.glassfish.jersey.media/jersey-media-multipart/2.35).

Of course as noted by other comments, the version can be downgraded. But your proposal to drop the mimepull version sounds right to avoid surprises.

I've opened #31145 for that. However in term of compatibility, is it ok just to drop it like that? Existing projects might be relying on this version being declared in Spring Boot.

[wilkinsona]

I've opened #31145 for that.

Thank you.

However in term of compatibility, is it ok just to drop it like that? Existing projects might be relying on this version being declared in Spring Boot.

Ideally, we would have spotted this and made the change during the 2.7 milestones. Now that chance has gone, we need to try and strike a balance. Technically it is a breaking change, but it's one that is very easy for someone to overcome if they happen to have an unversioned direct dependency on mimepull. With that in mind, I think it's early enough in 2.7's life that we can remove the dependency management. IMO, its removal will inconvenience fewer people than if it we leave it in place.

[wilkinsona]

Closing in favor of #31145.