null 분석 주석 패키지의 차이점은 무엇입니까?

Question

질문 Which @NotNull Java annotation should I use?은 구식이며 다소 의견을 기반으로합니다. 그 이후 Java 8이 출시되었습니다.

Java 8은 유형의 주석 을 JSR 308의 통합으로 허용하지만 어떤 것도 제공되지 않습니다. JSR 308 Explained: Java Type Annotations by Josh Juneau에서 :

JSR 308 자바 유형에 주석, 자바 SE의 일부로 통합되어 제
...
컴파일러 체커 컴파일러 경고를 발생함으로써 규칙을 시행, 주석 코드를 확인하기 위해 기록 될 수있다 코드가 특정 요구 사항을 충족시키지 못하는 경우 Java SE 8은 기본 유형 검사 프레임 워크를 제공하지 않지만 유형 검사를 위해 사용자 정의 주석과 프로세서를 작성할 수 있습니다. Java 컴파일러에 대한 플러그인으로 사용하여 주석이 첨부 된 유형을 확인하고 시행 할 수있는 여러 가지 유형 검사 프레임 워크도 다운로드 할 수 있습니다. 유형 검사 프레임 워크는 주석 처리를 위해 컴파일러와 함께 사용되는 유형 주석 정의 및 하나 이상의 플러그 가능한 모듈로 구성됩니다.

• Eclipse's JDT Null Analysis의 org.eclipse.jdt.annotation : @CanBeNull 및 @CannotBeNull 적어도 어떤 종류의를 제공하는 유일한 솔루션을 고려
  는

, 나는 다음 (틀릴 수도)에 대한 정보를 발견했습니다. 다른 IDE에는 각각의 패키지가 있습니다. JSR 308을 사용하며 Java-8 이전 주석을 계속 지원합니다.

FindBug의 javax.annotation. 휴면 JSR 305을 사용하면 Java 8의 유형 주석을 사용하지 않는 것처럼 보입니다. 오라클의 API에 통합되어 있지는 않지만 어떤 이유로 든 여전히 javax 도메인을 사용합니다. 이는 의미가 있음을 의미합니다.

Checker Framework 'org.checkerframework.checker.nullness. JSR 308 사용.

JavaEE의 javax.validation.constraints. 어떻게 사용하는지 모르지만, 어쨌든 @CanBeNull은 없습니다.

일부는 정적 코드 분석에 사용되며 일부는 런타임 유효성 검사에 사용됩니다.

위 옵션 간의 실제 차이점은 무엇입니까? 표준이 될 것입니까? 아니면 모든 사람들이 자체 분석 프레임 워크를 작성하도록되어 있습니까?

Answer 1

언급 한 것 외에 다른 nullness 분석도 있습니다. 예를 들어 IntelliJ에는 nullness analysis이 포함되어 있습니다.

여기 nullness 분석에 대해 질문 몇 가지 핵심 질문은 다음과 같습니다

• 는 컴파일 시간 또는 실행 시간에 사용할 수 있습니까? 컴파일 타임 분석은 프로그래머에게 잠재적 인 버그에 대한 사전 경고를 제공합니다. 런타임 분석을 사용하면 프로그램이 계속 충돌하지만 더 일찍 또는 더 유익한 오류 메시지로 충돌 할 수 있습니다.

• 검증 자 또는 버그 검색기입니까? 확인 프로그램이 정확성 보장을 제공합니다. 도구가 잠재적 오류를보고하지 않으면 런타임에 프로그램이 주어진 오류를 겪지 않습니다. 버그 탐지기가 몇 가지 문제를보고하지만 문제가보고되지 않으면 프로그램이 여전히 잘못되었을 수 있습니다. 검증 프로그램은 대개 프로그램에 주석을 달아주는 등 프로그래머에게 더 많은 작업을 요구합니다. 버그 탐지기는 주석 처리되지 않은 프로그램에서 실행될 수 있기 때문에 사용을 시작하기 위해 노력을 덜 기울일 수 있습니다 (이 경우 매우 좋은 결과를 얻을 수는 없지만).

• 분석의 정확도는 어느 정도입니까? 얼마나 자주 오류 알람이 발생하거나 프로그램이 실제로 올바르면 경고를 보냅니 까? 얼마나 자주 알람이 누락되거나 프로그램의 실제 버그에 대해 알려주지 않으십니까?

• 공구가 IDE에 내장되어 있습니까? 그렇다면 사용이 더 쉬울 수도 있습니다. 그렇지 않은 경우 특정 IDE를 사용하는 프로그래머가 아닌 모든 프로그래머가 사용할 수 있습니다.

위에서 언급 한 세 가지 도구는 모두 컴파일 타임에 작동합니다. FindBugs는 버그 파인더이며 나머지는 확인 프로그램입니다. Checker Framework는 정밀도가 뛰어나지 만 다른 두 가지 IDE 통합이 더 좋습니다. FindBugs는 Java 8 유형 주석 (JSR 308)에서 작동하지 않습니다. 둘 다 Java 8 및 Java-8 이전 주석을 모두 지원합니다. 이 모든 도구는 프로그래머의 도구 상자에 있습니다. 하나는 당신의 필요와 목표에 달려 있습니다.

는 다른 몇 가지 질문에 대답하려면 다음의 디자이너가 오라클은 자바 표준으로 FindBugs를 채택 할 것이라고 기대하기 때문에

FindBugs의 주석이 javax 도메인을 사용 (!). 그것은 결코 일어나지 않았다. javax을 사용하면 많은 사람들이 오라클이 오라클에 공식적으로 또는 호의적이라고 생각하도록 혼란 스럽습니다. 그렇지 않습니다.

표준이 있습니까, 아니면 누구나 자신의 분석 프레임 워크를 작성할 수 있습니까?

현재 오라클은 커뮤니티가 다양한 분석 프레임 워크의 작성 및 사용을 실험하고 싶어합니다. 그들은 표준을 만들기에 충분할만큼 다양한 접근법의 장단점을 아직 이해하지 못한다고 생각합니다. 그들은 결함있는 접근 방식을 모색하는 표준을 조기에 만들고 싶지 않습니다. 미래에 표준을 만들 수 있습니다.

Answer 2

당신이 꽤 많이 수집 이미 그것을 설명하는 정보 : 유형 약어 (JSR 308)을 기준으로

정적 분석이 실제로 훨씬 더 강력 이전 방법보다.

두 세트의 주석은 정적 분석 (고급 유형 검사로 간주 될 수도 있음)을 수행하기 위해 JSR 308을 사용합니다. 핵심에서 이러한 주석을 사용하는 두 가지 도구는 본질적으로 호환 가능하며 각 주석은 다른 주석을 사용합니다. 내가 아는 차이점은 주로 두 영역에 있습니다.

• IDE 통합.
• 주석이없는 유형의 해석.엄격한 세계에서는 모든 유형이 Null이거나 Null 가능하므로 주석이 누락 된 경우 기본적으로 Null이 아닌 것으로 해석 될 수 있습니다. 또는 기본 유형 시스템에서 "레거시 유형"이라는 개념을 사용하여 "확인되지 않은 변환"이 필요할 때 경고를 발생시킬 수 있습니다 (일반 유형과 원시 유형의 조합과 유사). 내가 알기로 Checkers Framework는 엄격한 접근 방식을 적용하는 반면, Eclipse에서는 @NonNullByDefault 전략 중에서 선택하고 "이전 유형의 경우"(마이그레이션을 위해) 허용합니다.

또한 내 지식으로는 아무도 현재 이러한 특수 효과의 표준화에 투자 할 계획이 없습니다.