반응형
Chapter 1
JNI는 VM과 device간의 상호 운용을 통하여 VM하단을 구현할 수 없던 제약을 해결해준다.
하나의 native application/library 버젼으로 모든 java VM에서 구동한다.
Java Native Interface Overview
java 뿐만 아니라 다른 언어로도 구현할 수 있다는 내용
- platform dependent feature
- 다른 언어로 쓰여진 library를 이미 가지고 있을 때 사용하면 유용
- 작은 부분의 time-criticla coe를 작성할 수 있다. (assembly 같은)
갖가지 장점들을 나열 하고 있지만... 단점도 많다.
내 생각에는 하드웨어 dependency가 아니라면 궂이 안 쓰는게 좋을 것 같다.
Historical Background
기존에 다른 VM은 native method interfaces를 지원하였으나, 각각 다른 버젼으로 짜야 하기 때문에 재사용성이 떨어졌다.
ex) JDK 1.0 Native Method interface, Netscape's Java Runtime Interface, Micosoft's Rwa native Interface and Java/COM interface
JDK 1.0 Native Method Interface
1.0은 2가지 이유 때문에 다른 VM에 적용할 수 없었다.
1. native code는 C structuers처럼 java field에 접근 하였으, java spec.은 memory에 펼쳐지게 정의되지 않았다.
2. native method interface gabage collector 에 의지하였다. 엄격하지 않게 unhand Macro를 사용하였다. 보수적으로 native stack을 검색해야 한다.?
Java Runtime Interface
Netscape에서 각 분야에 일반적인 interface를 제공하자고 제안을 하였다.
JRI는 이식성을 염두해 두고 설계되었다. native method, debugging, reflection, embedding.. 등의 이슈가 있었다.
Raw Native Interface and JAVA/COM Interface
1. microsoft는 2개의 native method를 지원하였다.
효율적인 Raw Native Interfae low level 지원
conservative garbage collection 대신에 RNI 함수를 사용해야 하는 이슈가 있다.
2. java/com interface 는 higher level, 언어 독립적인 standard binary interface to the java VM
Com class 와같이 java class또한 노출된다
Objectives(목적)
표준화를 위하여 얻는 장점
1. 각 vendor는 large body native code를 제공한다.
2. tool builder는 다른 종류의 native method interface를 유지보수할 필요가 없다.
3. application programmer는 하나의 버젼으로 개발하여 다른 곳에서 사용할 수 있다.
의논 결과 다음과 같은 3가지의 요구사항을 만족해야한다.
1. 바이너리 호환
2. Efficiency (효율)
3. Functionality (기능)
Java Native Interface Approach
많은 종류의 다른 인터페이스를 구현해야 하는 프로그래머에게 그 비용을 줄여주기 위하여 우리는 존재하는 표준화된 interface를 채용하려고 한다.
그러나 불행하게도 우리가 원하는 그러한 솔루션은 존재하지 않고 있다.
Netscape's JRI 가 가장 비슷하여, JRI를 기점으로 설계하였다.
API naming convetion, method, field IDS logcal, global references 등등
우리의 최선의 노력에도 불구하고, JRI는 JNI 바이너리 호환성을 제공할 수 없다.
MicroSoft RNI는 noneomservative garbage colleor 문제가 존재하는 JDK1.0의 향상본이다.
그러나 RNI 는 VM-독립에 적합하지 않다.
JDK, RNI native methods는 java object를 C 구조체 처럼 접근하여 다음과 같은 2개의 문제를 야기한다.
1. RNI는 JAVA object의 layout을 native code에 노출했다
2. C 구조체와 같은 java object 직접접근은 grabage collection algorithms이 필수 적인 효율적인 "write barriers" 통합을 불가능 하게 했다.
바이너리 표준 같은 경우는, COM 은 다중 VM 간에 완벽한 바이너리 호환을 보장한다.
COM 오버해드가 있는 간접 호출 method를 호출한다. 추가로 COM objects는 dynamic-link library가 향상되었다.
COM을 java native method 표준으로 하려고 했으나. 몇 가지 요소가 문제가 되었다.
1. private filed와 exception 발생을 처리할 함수가 부족하였다.
2. 세심한 case에 대한 matching mthoad interface를 다룰 수가 없다.
3. 독립적인 low-level functions 대신에 COM은 software components를 따르게 설계되어있다.
4. UNIX platform을 지원하지 않는 결점
비록 native code가 COM object처럼 java native에 노출되어있진 않지만, JNI interface 스스로 COM을 통하여 바이너리 호환이 된다.
JNI 는 COM 같은 jump table structure와 calling 대표를 사용한다.
Programming to the JNI
Changes