springboot Build project with -Werror

We'd like to try building with -Werror

Comment From: wilkinsona

I've done a bit of exploration. It's not too bad thus far when compiling with -Werror -Xlint:depreaction -Xlint:unchecked.

Deprecated imports

You can't suppress a deprecation warning on an import statement so you have to avoid using the import instead. This leads to changes like this:

@@ -19,18 +19,20 @@ package org.springframework.boot.actuate.endpoint.web.servlet;
 import javax.servlet.http.HttpServletRequest;
 import javax.servlet.http.HttpServletResponse;

-import org.springframework.web.accept.PathExtensionContentNegotiationStrategy;
 import org.springframework.web.servlet.handler.HandlerInterceptorAdapter;

 /**
  * {@link HandlerInterceptorAdapter} to ensure that
- * {@link PathExtensionContentNegotiationStrategy} is skipped for web endpoints.
+ * {@link org.springframework.web.accept.PathExtensionContentNegotiationStrategy} is
+ * skipped for web endpoints.
  *
  * @author Phillip Webb
  */
 final class SkipPathExtensionContentNegotiation extends HandlerInterceptorAdapter {

-       private static final String SKIP_ATTRIBUTE = PathExtensionContentNegotiationStrategy.class.getName() + ".SKIP";
+       @SuppressWarnings("deprecation")
+       private static final String SKIP_ATTRIBUTE = org.springframework.web.accept.PathExtensionContentNegotiationStrategy.class
+                       .getName() + ".SKIP";

        @Override
        public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)

Unknown enum constants caused by optional dependencies

@MockBean in spring-boot-test has an attribute, answer, that references the enum org.mockito.Answers. When a project that depends on spring-boot-test but does not depend on Mockito is compiled this leads to a warning about an unknown enum constant. This warning cannot be suppressed so you have to add a dependency on Mockito to avoid it. This affects spring-boot-test-autoconfigure.

Interestingly, this will also affect any of our users who use spring-boot-test without Mockito, making it impossible for them to compile with -Werror without also adding a Mockito dependency.

Overriding deprecated methods

javac is more strict about deprecation warnings than Eclipse is. For example, if an overridden method is @Deprecated, javac will report a deprecation warning if the overriding method is not also @Deprecated.

Comment From: philwebb

We might get away with introducing our own Answers enum for MockBean. It will break binary compatibility, but since it's used in test code that might not be such an issue in practice.

Comment From: wilkinsona

Using Framework's @Nullable causes a similar failure to @MockBean. I've opened https://github.com/spring-projects/spring-framework/issues/25095.

Comment From: wilkinsona

The Framework team have indicated that we'll have to live with the problem with @Nullable. We can do so with a compileOnly dependency on com.google.code.findbugs:jsr305:3.0.2 in the few places that we have code that uses @Nullable.

Comment From: wilkinsona

When a project that depends on spring-boot-test but does not depend on Mockito is compiled this leads to a warning about an unknown enum constant. This warning cannot be suppressed so you have to add a dependency on Mockito to avoid it. This affects spring-boot-test-autoconfigure.

This isn't as bad as I had thought. spring-boot-test-autoconfigure is only affected because it has a couple of import statements for @MockBean as it's linked to from the javadoc for @WebFluxTest and @WebMvcTest. Removing the import statements and fully-qualifying the classname in the @links avoids the problem.

Comment From: wilkinsona

I've prepared a branch with 5 commits that compile with -Werror and then enable various -Xlint:<name> options.

Comment From: wilkinsona

It looks like we'll only be able to enable -Werror when building with Java 8. There are changes in later JDKs that generate warnings but, short of relying on reflection, we can't avoid the warning while remaining Java 8 compatible. One example is the deprecation of getPackage(String) on ClassLoader and the introduction of getDefinedPackage(String) as a replacement. Both changes were made in Java 9. We can't switch to getDefinedPackage(String) and compile with Java 8. We also can't suppress the deprecation warning and compile with Java 8 as it will be flagged as redundant.