애플리케이션 서비스가 static final 필드/불변 프로퍼티에 대입되는 것을 보고합니다.

static final 필드(Java) 또는 백킹 필드가 있는 static 불변 프로퍼티(Kotlin)

주의: 여기에서 Kotlin의 static이란 익명 객체나 최상위 선언의 멤버를 의미합니다.

이러한 서비스의 대입은 전역 상태에 영향을 미치며 애플리케이션을 제거하고 다른 애플리케이션을 설정할 수 없게 만듭니다. 따라서 같은 프로세스 내에서 반복되는 테스트가 실패할 수 있습니다. 유일한 예외는 더미/디폴트 인스턴스를 저장하기 위한 명시적 생성자 호출입니다.

서비스 저장을 피하기 위해 권장되는 방법은 서비스를 로컬로 받는 것입니다. 또는 java.util.function.Supplier으로 래핑(Java, Kotlin)하거나 프로퍼티를 함수로 변환(Kotlin)할 수도 있습니다.

예(Java):


// 좋지 않은 방법:
  private static final ManagingFS ourInstance = ApplicationManager.getApplication().getService(ManagingFS.class);

// 좋은 방법:
private static final Supplier<ManagingFS> ourInstance = CachedSingletonsRegistry.lazy(() -> {
  return ApplicationManager.getApplication().getService(ManagingFS.class);
});

// 예외:
private static final UniqueVFilePathBuilder DUMMY_BUILDER = new UniqueVFilePathBuilder()

static 불변 프로퍼티를 통해 서비스 인스턴스 가져오기(Kotlin)

백킹 필드 없이 프로퍼티에 서비스를 대입해도 앞서 언급된 문제가 발생하지는 않지만, 명시적인 getInstance() 메서드를 사용하여 서비스를 가져오는 것이 프로퍼티를 사용하는 것보다 좋습니다.

도구의 성능을 개선하려면 항상 명시적인 메서드 반환 타입을 유지하는 게 좋습니다.

예:


@Service
class MyApplicationService {
  companion object {
    @JvmStatic
    val instance: MyApplicationService // 나쁨
       get() = service()
  }
}

@Service
class MyApplicationService {
  companion object {
    @JvmStatic
    fun getInstance(): MyApplicationService = service() // 좋음
  }
}

2023.3의 새로운 기능