일부 Java 라이브러리 메서드가 거의 동일한 서명을 가진 네이티브 메서드에 위임하는 이유는 무엇입니까?

일부 Java 라이브러리 메서드가 거의 동일한 서명을 가진 네이티브 메서드에 위임하는 이유는 무엇입니까?

---

JRE 라이브러리의 소스 코드를 조사한 후 다음과 같은 이상하게 일반적인 코드 구조를 발견했습니다.

public int foo(double bar) {
    return foo0(bar);
}

private native int foo0(double bar);

이 코드 패턴의 목적은 무엇이며 기본 네이티브 메서드를 공개 메서드로 노출하는 대신 왜 사용됩니까?

---

네이티브 버전은 구현 세부 사항 일뿐입니다.

이 패턴은 실제 구현에서 메소드의 공용 인터페이스를 분리합니다.

이것이 유용한 이유는 최소한 5 가지입니다.

• 테스트 목적 (자바 메서드 호출을 모의 할 수 있음)
• 대체 구현 : 자바 라이브러리의 특정 버전은 네이티브 구현을 호출하지 않고 순수 자바 형식으로 해당 메서드를 구현할 수 있습니다 (스윙 코드에서 공통).
• 이전 버전과의 호환성 : 새 버전에서 메서드가 몇 가지 추가 매개 변수를 허용하는 경우 원래 자바 메서드 서명을 유지하고 네이티브 구현을 조정할 수 있습니다.
• 입력 / 출력 유효성 검사 : 대부분의 경우 네이티브 버전을 호출하기 전에 Java 코드는 입력 매개 변수를 확인하고 필요한 경우 예외를 발생시킵니다.
• 격리 : 네이티브 코드를 직접 사용하는 메서드의 수가 제한되어 내부 코드 구조를 더 많이 변경할 수 있습니다.

더 많은 이점을 찾을 수 있습니다.

---

private native int foo(double bar);

따라서 결국 이것은 구현을 위해 C ++ 함수를 호출해야합니다. 특히 다음과 같은 이름으로 함수를 호출하게됩니다.

Java_MyClass_foo

서명이 다른 네이티브 foo 메서드가 여러 개 있으면 어떻게 되나요? 합병증. 그렇게하면 Java는 찾는 메소드의 이름에 유형 정보를 추가합니다. 그러나 오버로드되지 않은 메서드를 고수하면 더 쉽습니다.

public int foo(double bar) {
    return foo0(bar);
}

private native int foo0(double bar);

foo0고유 한 이름이 지정 되었기 때문에 다른를 추가 할 이유가 없어야합니다 foo0. 이것은 C ++의 구현을 단순하게 유지하며, 이름이 엉망인 것을 다룰 필요가 없습니다. foo가 결국 오버로드를 얻는 경우에도 foo1대신에 호출 foo0되며 C ++ JNI 구현은 오버로딩의 추가 복잡성을 처리 할 필요가 없습니다.

참고 URL : https://stackoverflow.com/questions/38948090/why-do-some-java-library-methods-delegate-to-a-native-method-with-a-nearly-ident