При переносе одного из наших проектов на Java 9 (сборка 9 + 181) я столкнулся с особой проблемой, которая выглядит как некорректная реализация в какой-либо используемой библиотеке, связанной с вывод типа и java-module. Я использую конфигурации dropwizard-core(1.1.0)
и guice(4.1.0)
, как показано ниже:
public class CustomService extends io.dropwizard.Application<CustomServiceConfig> {
public static void main(String[] args) throws Exception {
new CustomService().run(args);
}
// other initializations
@Override
public void run(CustomServiceConfig config, io.dropwizard.setup.Environment environment) throws Exception {
com.google.inject.Injector injector = createInjector(config, environment);
environment.jersey().register(injector.getInstance(SomeResource.class)); //line 45
environment.healthChecks().register("DBHealth", injector.getInstance(HealthCheck.class));
environment.servlets().addFilter("Filter-Name", SomeFilter.class)
.addMappingForUrlPatterns(EnumSet.allOf(DispatcherType.class), true, "/*");
}
private com.google.inject.Injector createInjector(CustomServiceConfig config, Environment environment) {
return com.google.inject.Guice.createInjector(new CustomServiceModule(config, environment));
}
}
public class CustomServiceModule extends com.google.inject.AbstractModule {
private final CustomServiceConfig serviceConfig;
private final Environment environment;
public CustomServiceModule(CustomServiceConfig serviceConfig, Environment environment) {
this.serviceConfig = serviceConfig;
this.environment = environment;
}
@Override
protected void configure() {
bind(SomeInterface.class).to(SomeInterfaceImpl.class);
..
}
}
Конфигурация отлично работает для меня со следующей комбинацией:
- Java 8 + Maven 3 + Плагин компилятора 3.6.1 [Наша первоначальная настройка]
- Java 9 + Maven 3 + Плагин компилятора 3.7.0 (обновлены конфигурации командной строки и maven)
Но когда я переключаюсь на структуру модуля, а затем пытаюсь скомпилировать модуль maven, состоящий из этих классов, я получаю эти ошибки во время mvn clean install
:
[ERROR] ../service/service/CustomService.java:[45,29] incompatible types: inference variable T has incompatible bounds equality constraints: base.SomeResource upper bounds: java.lang.Class<?>,java.lang.Object [ERROR] ../service/service/CustomService.java:[56,31] no suitable method found for addFilter(java.lang.String,java.lang.Class< SomeFilter >) [ERROR] method io.dropwizard.jetty.setup.ServletEnvironment.addFilter(java.lang.String,javax.servlet.Filter) is not applicable [ERROR] (argument mismatch; java.lang.Class< SomeFilter > cannot be converted to javax.servlet.Filter)
Я не уверен, почему произошли эти ошибки, и если они могут быть связаны с используемой структурой модуля.
Q1. Есть ли какое-либо изменение, связанное с типом вывода, которое может повлиять на компиляцию maven с изменениями структуры модуля (если это возможно) с учетом используемых зависимостей?
Кроме того, во время миграции я в основном использовал имена автоматических модулей, предложенные IntelliJ для построения module-info
как:
module service {
// Internal modules which compile successfully
requires model;
requires util;
// Dependent library modules
requires httpcore;
requires guice;
requires guava;
requires dropwizard.core;
requires mongo.java.driver;
requires org.apache.commons.lang3;
requires javax.servlet.api;
}
Q2. Если это не проблема с регрессией во время миграции, почему это не сработало с нашей предыдущей настройкой? Означает ли это также изменение кода в нашей службе или мы будем ждать, пока библиотеки перейдут на модули, если это может помочь?
Примечание: попытались изучить использование версий зависимостей и реализации класса. Они одинаковы как в предыдущей, так и в текущей настройке.
Дайте мне знать для получения дополнительной информации, с которой я мог бы помочь.
Обновление: Я смог воспроизвести то же самое в примере микросервиса, созданном мной, чтобы изолировать его от остальной части моего проекта.