While working on migrating our internal library to be based on the upcoming Spring Boot 4, I encountered issues with the following:

@ConditionalOnClass(ObservationRegistry.class)
@AutoConfiguration
public final class ExampleObservationAutoConfiguration {

    @Configuration(proxyBeanMethods = false)
    @AutoConfigureAfter(WebMvcObservationAutoConfiguration.class)
    @ConditionalOnClass(MeterRegistry.class)
    @ConditionalOnWebApplication(type = Type.SERVLET)
    static final class ExampleMetricsLoggingConfiguration {

    }

}

I understand the modules have moved around, so the import issue related to WebMvcObservationAutoConfiguration not being found is expected. But while looking at the changes for Spring Boot 4, specifically https://github.com/spring-projects/spring-boot/issues/32883, I can't help but wonder if the contract for @AutoConfigureAfter/@AutoConfigureBefore should be updated to accept a String by default rather than the class.

but users should reference only the names of these classes.

If that is the case, then presuming this means a String rather than Class, then the annotations should become:

@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.TYPE })
@Documented
public @interface AutoConfigureAfter {

    String[] value() default {};
}

Dropping references to Class entirely so then this is possible:

@AutoConfigureAfter("com.example.ExampleAutoConfiguation")

instead of:

@AutoConfigureAfter(name = "com.example.ExampleAutoConfiguation")

Comment From: ciscoo

This is presuming that the classes are eventually made package private as opposed to public as they are now. My understanding of https://github.com/spring-projects/spring-boot/issues/32883 is that all configurations should be private entirely, but that may be a bit much at the moment so only select changes were done at this time.

Comment From: wilkinsona

If that is the case, then presuming this means a String rather than Class,

It means that you should refer only to the class itself and not any of its methods or fields. I've updated the issue's description accordingly.

When you know the Class will always be on the classpath, a strongly typed reference using Class is preferred. name should be used when referencing a class in an optional dependency.

This is presuming that the classes are eventually made package private as opposed to public as they are now

That won't happen. The classes themselves will remain public so that they can be referenced as a Class.