NoSuchMethodError can be thrown from Session.getCookie() due to binary incompatibilty

[candrews]

Spring Boot 3.2.0 breaks binary compatibility with previous versions of Spring Boot (ex, 3.1.6).

Given a class that invokes org.springframework.boot.web.servlet.server.Session.getCookie(), if that class is compiled against Spring Boot 3.1.6 then run with Spring Boot 3.2.0, an exception occurs.

Example code:

import org.springframework.boot.autoconfigure.web.ServerProperties;

public class ExampleService {
	public  ExampleService(ServerProperties serverProperties) throws Exception {
		// get the session cookie name from configuration
		final String sessionCookieName = Optional.ofNullable(serverProperties.getServlet().getSession().getCookie().getName()).orElse("SESSION");
	}
}

When compiled and run against the same version of Spring Boot, it works fine. Compile against Spring Boot 3.1.6 then run against Spring Boot 3.2.0, this exception occurs:

Caused by: java.lang.NoSuchMethodError: 'org.springframework.boot.web.servlet.server.Session$Cookie org.springframework.boot.web.servlet.server.Session.getCookie()'

[philwebb]

The class was removed here. I'm not sure how we can fix this without introducing a new method for getCookie() with a different name.

[philwebb]

Perhaps we can reintroduce the inner class but keep it empty.

[wilkinsona]

We document that the property accessors aren't public API:

The properties that map to @ConfigurationProperties classes available in Spring Boot, which are configured through properties files, YAML files, environment variables, and other mechanisms, are public API but the accessors (getters/setters) of the class itself are not meant to be used directly.

Given this, I'm not sure that we should do anything here. It would depend a lot on how disruptive/awkward it would be to restore compatibility.

[philwebb]

Session is a bit special because it's used in ConfigurableServletWebServerFactory. Ideally we'd have a better split between the code in org.springframework.boot.web.servlet.server and the properties classes we ultimately expose under the server.* properties but that's not the case right now. I've regretted that design decision for a while now.

[candrews]

Do you have any further thoughts on this issue?

I'm trying to decide what I can do to support the users using the library I support that's impacted by this issue.

Thank you again!

[philwebb]

We talked about this today and we're going to put the class back in 3.2.x and look at reorganizing things in 4.x