2015-01-24 2 views
3

런타임시 주석 처리 된 클래스 검색 속도를 높이기 위해 주석 프로세서와 컴파일 할 때 특정 주석 유형으로 주석 처리 된 클래스의 인덱스 (심지어 파일에 저장된 간단한 목록조차도)를 작성하려고합니다.Java, 컴파일시 색인 주석 처리 된 클래스가 주석 처리기와 함께 사용됩니까?

그럼, 좋은 습관입니까? 어떤 결점이 있습니까? 그것이 나에게 좋은 것처럼 보인다면, 쉬운 방법으로 이것을 수행 할 많은 도서관이 아직없는 이유는 무엇입니까? (내가 발견 한 유일한 라이브러리는 Class Index입니다.) 대신 런타임 처리를 위해 너무 많은가?

+1

[조숙 한 최적화] (http://c2.com/cgi/wiki?PrematureOptimization)와 같이 들립니다. 벤치 마크를 수행 했습니까? –

+0

ClassIndex는 몇 가지 흥미로운 벤치 마크를 수행했습니다. 조숙 한 최적화가 될 수 있지만 문제는 남아 있습니다. 내 생각에 내가 생각하는 도서관에서 중요한 디자인 관심사이기도하다. –

+0

링크에서 인용하면 * Java ** 응용 프로그램 부트 스트랩 **이 상당히 많이 증가합니다 * 한 번 실행하는 동안 일반적으로 (또는 사용자의) 응용 프로그램이 몇 번 부트 스트랩한다고합니까? 마지막으로, "Reflections Maven plugin"은 거의 동일한 성능을 발휘하는 것으로 보인다. (단 하나의 공개 된 벤치 마크에서) ... –

답변

1

저는 단점은 그것이 더 복잡하다는 것입니다. 주석 처리는 많은 개발자가 익숙하지 않은 완전히 새로운 API 및 개념입니다. Reflection API는 더 쉽고 잘 알려져 있습니다. 일반적으로 런타임에 동일한 작업을 수행 할 수 있습니다.

더 나은 시작 성능이 중요한 경우 (드물게 그렇다면)에 추가 된 복잡성이 필요할 수도 있습니다.

나는 벤치 마크를 신뢰하지 않을 것이다. 그들은 "classpath size가 121MB로 설정되어있다"라고 말하면서 하드 코딩이나 컴파일 시간 처리와의 비교를 전혀 쓸모 없게 만드는 임의의 값입니다. 어쨌든 전체 수업 경로를 왜 스캔 하시겠습니까? 대부분의 경우 개발자 클래스 만 검색하는 것이 더 합리적입니다.

많은 프레임 워크는 구성 파일을 사용하거나 스캔해야 할 클래스 나 패키지를 제한하는 API를 가지고 있습니다. 이렇게하면 시작 시간이 크게 늘어납니다.

이유가이

많은 OSGi 프레임 툴/프레임 워크는이 작업을 수행 할 수있는 많은 도서관이 아니다. 주석을 컴파일 할 때 스캔하고 메타 데이터를 jar 매니페스트 파일에 기록하거나보다 정교한 메타 데이터 파일을 작성합니다. 이 주된 이유는 bnd 및 주석 또는 주석 처리 전에 OSGi 구성 요소의 시간 분석을 빌드하고 컴파일하는 데 사용 된 유사한 도구와의 호환성을 유지하는 것이 더 많은 인기를 얻고 있다고 생각됩니다. 또한 OSGi 구성 요소는 고유 한 라이프 사이클을 가지며 언제든지오고 갈 수 있습니다. 따라서 응용 프로그램 시작시 한 번만 검사 할 수는 없으므로 시작 시간이 조금 더 중요합니다. 구성 요소 (다시)가 시작될 때마다 주석을 스캔해야합니다.

나는 그것이 좋거나 나쁘다고 말하지 않을 것입니다. 요구 사항에 맞는이 기술을 사용하십시오. 나는 몇 밀리 초의 시작 시간을 위해 많은 복잡성을 추가하는 것을 피할 것이다.

+0

눈에 띄는 답변을 주셔서 감사합니다. 더 넓은 시야를 확보하는 데 정말로 도움이됩니다. 그것에 대해 생각해 보면 실제로 컴파일 시간 인덱싱의 단점을 발견했습니다. 이는 추상 팩토리 및 SPI의 구현과 같은 플러그 형 라이브러리에 대한 적용 가능성이 부족하다는 것입니다. 나는 내 질문에 대한 대답에 이것을 넣어야하는지 확신하지 못한다. –

1

ClassIndex 라이브러리의 저자는 주석 색인 작성을 위해 특수 효과 처리를 사용함에 따른 몇 가지 장점을 나열 할 수 있지만 널리 채택되지는 못한다는 단점이 있습니다.

장점 :

  • 인덱싱 사용하여 주석 처리 클래스 패스 스캐닝은 자바 내부에 의존하는 반면에 공식 JSR 269를 기반으로합니다. ClassLoader에는 주석이 달린 클래스 목록을 검색하는 API가 없다는 것은 일반적인 지식입니다. 그러나 더 놀라운 것은 일반적인 ClassLoader가 폴더를로드하려고하는 폴더와 JAR 파일을 나열하는 것을 허용하지 않는다는 것입니다. Classpath 스캐너는 클래스를로드하는 데 사용되는 클래스 로더가 getURLs() method을 사용하여 검색 할 소스 URL을 검색 할 수있는 URLClassLoader라고 가정합니다.
  • 일반 클래스 패스 스캐너 do not work이 있는데, Dalvik 실행 파일 형식이 사용되는 Android의 경우입니다.
  • 런타임 런타임의 복잡성은 컴파일 타임 인덱싱을 매우 빠르게 만듭니다.
  • Project Jigsaw는 annotation detection to Java을 가져올 계획입니다. 현재의 요구 사항은 컴파일 타임 인덱싱을 실행 가능한 구현으로 제안합니다. ClassIndex 라이브러리에서 @IndexAnnotated과 같은 목적으로 @Indexed 메타 주석을 도입하기까지합니다.

단점 :

  • JSR 269은 제대로 자바 컴파일러와 툴에서 지원된다. 이전 버전의 javac에는 몇 가지 버그가있었습니다. Eclipse의 사용자 정의 JDT 컴파일러는 더 많은 버그가 있으며 주석 프로세서의 자동 검색을 지원하지 않습니다. ClassIndex에는 이러한 문제에 대한 해결 방법이 포함되어 있습니다.
  • 클래스 경로 검색은 사실 표준이며 매우 잘 지원됩니다.
  • 응용 프로그램 부팅 시간이 거의 걱정할 병목 현상이 아닙니다.
1

JBoss WildFly의 하위 프로젝트 인 Jandex이 흥미로울 수 있습니다.

빌드 시간에 주석 색인을 만들고 (색인 파일을 JAR에 추가 할 수 있음) 런타임 (주석을 리플렉션이 아닌 클래스 파일을 검토하여 주석을 검색 함)을 작성하므로 주석 검색의 성능이 크게 향상됩니다. 실제로 클래스를로드합니다.

Jandex는 내가 좋아하는 것과 거의 비슷하게 들립니다.