검색결과 리스트
글
Java는 웹 관련 프레임워크들이 너무 다양하고, Ruby나 Python 같은 경우에는 RubyOnRails나 Djanog 처럼 하나의 프레임워크 안에 기능별 프레임워크들도 모두 다 All in one 형태로 들어 있어서 혼란을 주지 않는 반면, Java는 각 영역별로 프레임워크가 모두 다르고, 또한 각 영역별로 존재하는 프레임워크들의 종류도 많아서 초보 개발자들에게 극심한 혼란을 주고 있다.
그래서 나름대로 Java Web 개발자들을 위한 학습 로드맵을 정리해 보았다.
1. Java 그 자체
많은 웹 개발자들이 마치 JSP 코드를 짤 줄 알면 그걸로 Java 웹 개발을 할 줄아는 것이라 생각하고 Java 그 자체를 소홀히 하는 것을 본다.
말도 안되는 소리이다. Java를 모르고서 Java 웹 개발을 제대로 한다는 것은 어불 성설이다. Java 그 자체를 먼저 공부하라.
특히 Java 5 문법을 숙지하길 권한다. 이제 우리나라도 점차 Java 5가 대세가 되어 가고 있다. 대부분의 프레임워크들과 WAS(JSP와 서블릿을 구동하는 서버)도 모두 Java 5를 기준으로 바뀌었으며, JVM 자체도 버전이 높을 수록 성능이 더 좋다.
2. JSP와 Servlet 그리고 Model 1
모델 1은, JSP 하나에 DB에 접속해서 쿼리를 날리는 등의 모든 업무적인 기능(Business Logic)을 넣고, 그 아래에 HTML 코드를 박아 넣는 식으로 개발하는 것을 의미한다.
아직도 많은 개발자들이 여기에 길들여져 있는데, 일단 JSP 자체에 대한 기본기를 익힌 뒤로는 재빨리 버려야 할 습관이다.
그리고 많은 개발자들이 Servlet을 무시하고 JSP만 하는 것을 보곤 하는데, Servlet에 대한 학습이 제대로 이뤄지지 않으면 더 나은 웹 개발이 곤란하다. Servlet에 대한 기초 개념을 확실히 잡길 권한다.
3. Model 2 - 프레임워크의 등장
JSP로 열심히 개발을 하다보니 프로젝트 규모도 커지기 시작하고, JSP 파일 크기도 수천줄에 달하는등 엄청나게 커진다.
그런데 이 JSP에다 두서없이 모든 기능을 다 때려 넣다보니 JSP마다 똑같은 기능들이 Copy&Paste로 들어가고, JSP 안에 들어 있는 Java 코드들에서 에러가 발생하면 찾아내서 디버깅 하는 일이 지옥같이 느껴지기 시작한다.
여기서 Model 2가 구원자로 등장한다.
Model 2는 말만 멋드러졌지 실제로는 간단한 개념이다.
JSP에서 수행하던 DB 쿼리 등의 작업을 Servlet에게 넘겨주고 JSP에서는 오로지 화면 출력만 담당하는 것이다.
Servlet에서 DB 쿼리등 화면 출력과는 상관없는 비지니스 로직을 일단 먼저 모두 수행하고, 그 결과를 request.setAttribute("key",결과객체);로 담은 다음 JSP 페이지로 포워딩(forward)을 하면 JSP에서는 request.getAttribute("key")로 그 객체를 받아서 화면에 뿌려주기만 한다.
이런 업무 수행단/화면 출력단의 철저한 역할 분리가 Model 2이다.
여기서 이러한 각 역할을 "MVC - Model View Controller" 라고 한다. 그래서 Model 2는 MVC와 동일한 의미로 사용하기 도 한다. MVC의 의미는 공부하면서 찾아보라.
이게 뭐가 좋냐고? 개발 기간이 좀 길어지고 프로젝트 규모가 쬐끔 커지고, 기존 프로젝트를 유지보수를 해보면 얼마나 좋은지 몸소 뼈져리게 느끼게 된다.
Model 2의 기능을 정형화해서 쉽게 구현하게 해주는 것이 MVC Framework들의 역할이다.
가장 유명한 Model 2 웹 프레임워크들은 다음과 같은 것들이 있다.
* 스트럿츠 1 - Struts 1
* 스트럿츠 2 - Struts 2
* 스프링 MVC - Spring MVC
* 기타 덜 유명한 Wicket, Stripes, JSF, Tapestry 등.
Struts 1은 MVC의 효시라고 할 수 있다. 우리에게 MVC라는 축복을 주기는하였으나, 나온지 오래된 만큼 낡은 개념들이 많이 녹아있고 쓸데 없이 복잡하고 배우기도 어려운 편이다.
오히려 Struts 2와 Spring MVC가 더 배우기 쉬울 것이며, 개발도 더 쉽다. 현재 추세는 Struts 2와 Spring MVC이다. 대형 포탈이나 SI 업체들도 Spring/Struts 2를 주로 채택하는 추세로 가고 있는 것으로 알고 있다.
둘 중 하나의 개념만 확실히 이해해도 다른 것을 배우는데 어려움이 별로 없으므로 그냥 둘중에 골라서 배우길 권한다. 나는 Spring을 선호한다.
그리고 MVC 프레임워크를 사용하기 시작하면서 View를 만드는 JSP에 대해서도 재조명이 시작된다. 기존에 Java 코드를 JSP에 직접 넣던 관행을 버리고 JSTL과 태그 라이브러리를 사용하거나 아예 JSP를 버리고 다른 템플릿 엔진으로 만들기도 한다. 이에 관해서는 맨 마지막에.
4. 퍼시스턴스 프레임워크 : JDBC 반복 작업에 짜증이 나기 시작하다.
현대 웹 개발에서 가장 큰 역할을 차지하는 것은 뭐니뭐니해도 단연 Database 작업이다.
지금까지는 아마도 JDBC에서 DB 커넥션을 맺고, 쿼리를 날리고 그 결과 ResultSet을 JSP로 넘겨주어서 출력하는 식으로 했을 것이다.
이미 다들 알고 있겠지만 JDBC를 사용하면 똑같은 코드가 굉장히 많이 반복해서 나온다. 한마디로 "삽질"의 전형이 JDBC 작업이다.
이것을 깨달은 많은 개발자들이 조금 어정짱하게 반복작업을 해결해주는 Util 클래스들을 프로젝트별로 만들어서 사용하곤 한다.
하지만, 물론 이에 대해 정형화하고 깔끔하고 훨씬 더 사용하기 쉬게 만들려는 노력이 이미 수년에 걸쳐 이루어졌다.
이렇게 DB관련된 작업을 정형화한 것들을 Persistence Framework 라고 한다.
* 아이바티스 - iBATIS : SQL Mapper - JDBC보다 더 쉽게 배우고, 더 편하게 사용한다.
* 하이버네이트 - Hibernate : 객체지향을 객체지향답게, 개발 기간을 엄청나게 단축시켜주다.
퍼시스턴스 프레임워크의 양대 산맥은 iBATIS와 Hibernate이다. 이 둘 모두 우리나라에 책이 나와 있다.
iBATIS는 SQL Mapper의 한 종류이고, Hibernate는 ORM의 한 종류이다.
이 둘의 차이는 iBATIS는 개발자가 SQL 쿼리를 직접 작성한 것을 객체에 매핑시켜주는 것이고, ORM은 DB 스키마와 객체간의 관계를 설정파일로 만들면 자동으로 쿼리를 만들어주는 것이다.
자, 이 둘을 보면 미국에서는 Hibernate가 인기가 좋고, 우리나라에서는 iBATIS가 사실상 SI 업계를 평정했다.
그러니까, 일단은 우리나라에서는 iBATIS를 공부하면 된다고 보면 된다.
이렇게 말하니까 마치 이 둘이 경쟁자 같은데, 사실 이 둘은 경쟁 상대라기 보다는 보완해주는 역할을 한다. SI에서 처럼 DB 테이블이 정규화 되어 있지 않은 경우에는 Hibernate같은 ORM을 사용하면 프로젝트를 말아먹을 수 있다.
iBATIS는 테이블 정규화에 무관하게, 개발자가 작성한 SQL을 객체로 매핑하기 때문에 DB 스키마가 마구 꼬여 있는 상황에서도 유연하게 작동하고, 개발자가 직접 SQL 튜닝을 할 수 있다는 장점이다.
그리고 Hibernate는 배우기가 굉장히 어려운 프레임워크이고 튜닝이 매우 어렵다. Hibernate책을 보면 캐싱을 통해 성능을 향상시키라고 하지만 캐싱은 iBATIS도 못지않게 잘 지원한다. 하지만 일단 배우면, 그로인한 코딩 생산성이 iBATIS가 감히 넘볼 수 없을 정도록 급격히 향상된다.
Hibernate는 DB 정규화가 잘되어 있는 웹 포탈 업체나 패키지 소프트웨어 제작시에 강력히 권장할만 하다.
5. IoC와 DI - 객체의 생성주기와 의존성을 관리하고 싶어지다
사실 내가 경험한 SI를 보면 4단계 까지만 가도 막장은 아닌 프로젝트라고 본다. 아직도 신규 프로젝트를 하면서도 Model 1에 JDBC로 코딩하는 것을 많이 보았기 때문이다.
앞서, MVC라는 형태로 웹 애플리케이션의 역할을 철저하게 분할해서 처리하라고 했었다.
이제 여기서 좀 더 역할을 분할하기 시작한다.
Database를 관장하는 코드(DAO)와 Database 처리 결과를 가지고 그외 비지니스 로직을 추가로 수행하는 코드(Service), 그리고 웹으로 들어온 요청을 받아서 비지니스 로직을 호출하고, 그 결과를 다시 웹(HTML 등)으로 내보내는 코드(Controller)로 분할을 하면 유지보수가 더 쉽고, DB가 Oracle에서 DB2 로 변경되는 식의 중대 변화가 있을 때도 DAO만 바꾸면 되는 식으로 변화에 대한 대처가 유연해 진다는 것을 깨닫기 시작한다.
이제는 각 역할별로 클래스를 분할하고 컨트롤러 객체는 서비스 객체에 서비스 객체는 DAO 객체에 의존해서 작동하도록 코드를 바꾸기 시작한다. 그리고 객체의 생성과 파괴 주기도 관리해야만 하게 된다. 객체를 하나만 생성하면 되는데 불필요하게 매번 new를 할 필요는 없으니까.
이렇게 객체의 생성/파괴 주기를 관리하고 객체간의 의존성을 관리해주는 프레임워크를 IoC 컨테이너라고 부른다.
1. Spring Framework
2. EJB 3.0
사실상 대세는 Spring Framework로 굳어졌다. EJB 3.0은 내가 안써봐서 뭐라 말은 못하겠다.
Spring MVC는 이 Spring Framework의 일부분이다.
Spring은 또한 AOP도 지원한다.
AOP 의 개념이 상당히 어려운 편이라서 개념 자체를 확실히 한마디로는 표현하지 못하겠다. 어쨌든 개발자들에게 가장 쉽게 다가오는 표현으로 하자면, AOP는 동일한 패턴으로 반복적으로 해야하는 일을 설정을 통해 자동으로 해주는 것이다.
이에 관한 가장 보편적인 예가 바로 트랜잭션이다.
지금까지는 아마도 비지니스 로직이 시작될 때 트랜잭션이 시작되고, 비지니스 로직이 끝날 때 트랜잭션을 종료하는 코드를 매번 작성해서 넣었을 것이다.
AOP를 사용하면, 비지니스 로직의 역할을 하는 메소드가 무엇인지 설정파일에 넣어주기만 하면 자동으로 메소드가 시작될 때 트랜잭션을 시작시키고, 메소드가 끝날 때 트랜잭션을 종료시켜준다. 물론 예외가 발생하면 트랜잭션을 rollback도 해준다. 따라서 Spring을 사용한 프로젝트에서는 트랜잭션 관련 코드를 볼 수 없을 것이다.
Spring 프레임워크는 기본적으로 IoC 컨테이너 역할을 하는 것이 핵심이다. 따라서 Spring을 사용한다고 해서 꼭 Spring MVC를 사용할 필요는 없다. Struts 2 + Spring + iBATIS 나 SpringMVC + Spring + Hibernate 등... 어떠한 조합이라도 가능하다.
6. 그 외
◈ Template Engine : JSP 보다 더 간결하면서 강력한게 필요해!
* JSP + JSTL : Sun이 지정한 산업표준이다. JSTL은 당연히 쓰고 있으리라 믿는다.
* Freemarker : 가장 권장할 만하다.
* Velocity : 굉장히 배우기 쉽다. JSTL보다 더 빨리 배워서 쓸 수 있다. 가독성도 좋다. 그러나 Freemarker 만큼 편하고 강력하지는 못하다.
많은 사람들이 Java 웹 개발을 그냥 "JSP 개발"이라고도 부르는데, MVC가 도입되고, Freemarker 같은 다른 템플릿 엔진을 사용하게 되면 더이상 JSP는 코빼기도 안보이게 된다. 그러므로.. JSP 개발이라는 말은 쓰지 않았으면 좋겠다.
◈ Layout Engine
* Sitemesh : 헤더 푸터 처럼 동일 패턴이 반복되는 레이아웃을 관리해준다.
◈ XML 도우미 : W3C DOM은 너무 어렵고 난잡하다. 좀 더 편한 XML관련 개발을 원한다면..
* JDOM : Java 표준으로 지정됐다고 한다.
* DOM4J
둘 다 비슷하게 편한거 같다. 예전엔 JDOM을 썼었는데, 나 같은 경우 현재 프로젝트에서는 DOM4J를 사용한다. Hibernate가 DOM4J를 사용하기 때문에, 별도의 라이브러리 더 넣는게 귀찮아서.
◈ 단위 테스트
* jUnit : 코드를 철저하게 테스트하자.
◈ 소스코드 버전관리
* CVS
* Subversion : 현재 대세는 Subversion
내가 최고 막장으로 꼽는 프로젝트는 아직도 FTP로 소스 관리하는 프로젝트이다. 이런 프로젝트에는 절대로 참여하지 않을 것이라고 굳게 맹세하고 또 맹세했다. --;
소스 코드 버전관리는 여러 개발자들이 동시에 개발할 때 소스코드를 저장하고 충돌을 관리해주며, 소스 변경 내역을 계속해서 추적해서 과거 소스로 언제든지 돌아갈 수 있도록 도와준다.
현재 대세는 Subversion이지만 CVS로도 버전관리의 이점을 충분히 만끽할 수 있다. 그리고.. 사실 CVS가 사용법을 익히기는 더 쉽다.
◈ 자동 빌드
* Ant : Ant 면 만사 Ok!
* Maven
아직도 javac 로 컴파일하고 있고, FTP로 파일 올려서 복사하고 있다면.. 이 모든일을 자동으로 명령 한방에 처리하도록 해야 실수도 적고, 퇴근도 일찍한다.
Ant로 빌드와 배포를 자동화 하자.
결론
내가 권하는 조합은
* SI 업체에서 일하는 경우 : Struts 2 혹은 SpringMVC + iBATIS + JSP/JSTL + 가능하다면 Spring Framework
* 웹 포털등과 같은 업계, 패키지 소프트웨어 제작 업체 : Struts 2 혹은 Spring MVC + Hibernate + Spring Framework + Freemarker + Sitemesh
출처 : http://kwon37xi.egloos.com/ 까먹지말자!
설정
트랙백
댓글
글
자바 네이티브 인터페이스(JNI)는 기본 언어 프로그램과 자바 가상 시스템(JVM) 사이의 통신 설정에 사용할 수 있는 메커니즘입니다. JVM과 C/C++ 코드 간의 상호 작용에 대해서는 JNI 관련 설명서나 JNI에 관한 기술 문서에서 자세히 다룹니다. 또 자바 SDK는 자바 코드를 사용한 C/C++ 프로그램 호출을 용이하게 하는 헤더 파일 생성 유틸리티도 제공합니다.
그러나 자바와 어셈블리 언어 코드의 연동에 대해 다룬 문서는 찾아보기가 어렵습니다. 저는 이전 기사를 통해 자바 애플리케이션에서 어셈블리 언어 프로그램을 호출하는 방법을 설명한 바 있습니다. 이번에는 어셈블리 언어 코드로 자바 메소드를 호출하는 데모 애플리케이션을 통해 ASM 프로세스에서 자바 프로그램을 호출하는 방법에 대해 소개하겠습니다. 이 자바 메소드는 Swing JDialog를 띄워서 실제로 실행되었음을 보여 줍니다.
ASM 기능의 자바를 선택하는 이유
자바를 구현하려면 JNI가 꼭 필요합니다. JVM의 일부 기능은 기본 플랫폼과의 상호 작용을 통해서만 구현되기 때문입니다. 그러나 이것 말고도 자바 클래스는 흔히 다른 언어로 작성된 애플리케이션을 보완하는 데 유용합니다. 자바는 고급 기능을 아주 간단하게 구현할 수 있도록 하는 광범위한 API를 제공하기 때문입니다.
얼마 전에 저는 몇 가지 소스에서 실시간 데이터를 수집하고 수집된 데이터를 순환 버퍼에 저장하여 버퍼가 가득 차면 새 데이터로 예전 데이터를 덮어쓰게 하는 애플리케이션 작업에 참여한 적이 있습니다. 지정된 트리거 이벤트가 디지털 입력에서 감지되면 정해진 수의 데이터 샘플을 버퍼에 저장하여 트리거 이전과 이후의 데이터 스냅샷을 볼 수 있도록 했습니다. 이때 원본 애플리케이션은 어셈블리 언어로 작성했습니다.
이 애플리케이션을 몇 달 사용해 본 결과, 트리거 이벤트가 발생할 때마다 애플리케이션이 권한 있는 감독자에게 스냅샷을 메일로 보내도록 하면 정말 편리하겠다는 생각이 들었습니다. 물론 그런 확장 기능을 어셈블리로 작성할 수도 있었지만, 팀원들은 이런 경우에는 자바로 확장 기능을 만든 다음, ASM 프로그램으로 기능을 연결하는 것이 더 쉽다는 의견이었습니다. 저는 ASM 지향의 JNI로 작업해 본 경험이 있었기 때문에 그것이 가능하다는 것을 알았고, 실제로 그 프로젝트는 금새 구현되어 성공을 거두었습니다.
이러한 애드온을 활용할 수 있는 어셈블리로 작성된 레거시 애플리케이션이 많은 것으로 알고 있습니다. 그러나 JNI를 유용하게 쓸 수 있는 것은 레거시 애플리케이션의 개조만이 아닙니다. 믿지 않는 분들도 많으시겠지만, 아직도 신규 프로그램의 특정 부분을 어셈블리 언어로 작성하는 경우가 있습니다.
얼마 전 발표된 어떤 기사에서 저자는 "핫 코드 경로를 최대한 효율적으로 만들기 위해 아직도 제품에 어셈블리 언어를 사용하는 썬 파트너들이 많다는 사실을 발견했다. 최신 컴파일러는 종전보다 훨씬 효율적인 코드를 만들어내지만, 컴파일러로 작성한 코드는 각각의 마이크로프로세서 명령에서 최대한 성능을 짜내는 방법을 알고 있는 엔지니어가 수작업으로 작성한 어셈블리에 비해 성능이 떨어진다. 프로그래머의 재량이 발휘될 여지가 많은 어셈블리 언어는 여전히 강력한 최적화 도구로 남아 있으며 현명하게 사용하면 성능을 높일 수 있다"고 주장했습니다. 이러한 "혼합 언어" 애플리케이션에서 ASM 기능의 자바를 사용할 수 있다는 것은 분명히 이익이 됩니다.
여기서 제시하는 방법은 ASM이 아닌 언어의 자바 코드를 호출할 때도 사용할 수 있습니다. JInvoke를 .dll로 다시 작성하는 경우, 예를 들어 FORTRAN 언어로 작성한 코드를 여기에 링크하여 자바 메소드를 호출할 수 있습니다.
저는 레거시 ASM 코드의 JNI를 다음 두 가지에 사용했습니다.
- 기능 향상: 앞서 언급했듯이 기존 ASM 애플리케이션에 메일링 기능을 추가했습니다.
- 인터페이스 향상: 쌍방향 사용자 인터페이스를 추가했습니다(대부분 AWT이지만 일부 Swing도 포함).
이렇게 향상된 애플리케이션을 Windows 2000 및 XP에서 실행해 보았습니다. 사용한 자바 버전은 1.3, 1.4, 1.6입니다. 그 결과, 모든 애플리케이션이 원활하게 작동되었습니다.
권장 다운로드
제가 데모 코드에 사용한 어셈블리 언어의 버전은 MASM32입니다. 전체 MASM32 번들을 무료로 다운로드할 수 있으며, 자바-ASM의 상호 작용을 시험하려면 이 번들을 컴퓨터에 설치해야 합니다. Iczelion의 사이트에는 MASM 프로그래밍에 대한 매우 유용한 튜토리얼 세트가 있습니다. JNI에 관한 문서 중 최고는 Sheng Liang의 책 The Java Native Interface: Programmer's Guide and Specification입니다.
이 책도 무료로 다운로드할 수 있습니다. 이 기사에 수록된 자바 코드 샘플(AsmToJava)을 실행하려면 SDK(최소한 JRE)가 필요합니다. 데모에서 어셈블리 언어를 사용한 JInvoke 부분은 .exe 파일로 컴파일했으며 MASM 번들 없이도 실행됩니다. 소스 코드를 수정하여 다시 컴파일하려는 경우에만 어셈블러/링커가 필요합니다.
기본 원리
JNI는 종합적인 JVM 인터페이스입니다. 이 인터페이스는 주로 풍부한 함수로 알아볼 수 있습니다. 기본 코드는 이러한 함수를 호출하여 구현된 JVM과 상호 작용합니다. 자세한 함수 설명은 Sheng Liang의 책을 참조하십시오. 이러한 함수는 대부분 JVM을 만들어야만 액세스가 가능하지만 JNI에서 몇 가지 기본 함수를 직접 내보낼 수도 있습니다. 나중에 자세히 다루겠지만, 두 번째 유형의 함수로 JVM을 인스턴스화하여 다른 JNI 함수를 호출할 수도 있습니다.
일단 JVM이 작성되면 JVM 인스턴스가 있어야만 구현 가능한 JNI 함수에 어셈블리 언어 프로그램이 액세스할 수 있게 됩니다. 이러한 모든 JNI 함수에 대한 포인터는 함수 테이블이라는 테이블에 저장됩니다. JVM을 로드하는 ASM 코드는 사실상 포인터인 JNIEnv라는 변수를 수신합니다. 그리고 JNIEnv는 함수 테이블에 대한 실제 포인터가 들어 있는 메모리의 특정 위치를 가리킵니다. 그림 1은 이러한 액세스 체인을 보여 줍니다.
보시다시피 JNI 함수에 대한 각 포인터는 길이가 4바이트입니다. 따라서 함수 테이블의 시작 주소에 해당 함수 색인의 4배를 더하여 정의된 위치에서 원하는 함수의 포인터를 찾을 수 있습니다. 함수 색인은 0을 기준으로 합니다. 즉, 첫 번째 함수의 포인터는 색인 0, 두 번째 함수의 포인터는 색인 1과 같이 이어집니다. Sheng Liang의 책에는 모든 JNI 함수의 색인 값이 나열되어 있습니다.
ASM 코드로 자바 프로그램을 호출하려면 다음 단계를 실행해야 합니다.
- JVM 인스턴스화
- 클래스 찾기
- 메소드 ID 확인
- 메소드 호출
각 단계를 자세히 살펴보기 전에, 이 프로그램 및 유사 프로그램을 손쉽게 작성하기 위해 include 파일을 사용하는 방법부터 알아보겠습니다. 자바와 기본 코드 사이의 상호 작용은 JNI로 노출된 함수를 통해 이루어지므로 기본 프로세스에서 이러한 함수를 반복적으로 호출할 필요가 있습니다. 따라서 이 활동을 처리하기 위해 매크로를 사용하겠습니다. 그러면 길이가 상당히 길고 비슷한 코드를 반복해서 작성할 필요가 적어지며 오타로 인해 프로그램에 버그가 생길 위험도 줄일 수 있습니다.
매크로
ASM 코드에서 함수를 호출할 때는 함수 테이블에서 해당 함수의 포인터를 찾은 뒤 그 포인터를 사용하여 원하는 함수를 호출해야 합니다. 앞서 설명했듯이, 포인터를 찾으려면 JNIEnv 포인터 체인을 따라 함수 테이블의 시작 주소를 확인한 다음, 해당 함수의 색인을 사용하여 함수 포인터를 검색해야 합니다. 함수 테이블의 시작 주소를 확인하는 첫 번째 작업에는 항상 동일한 코드를 사용하며 다음과 같은 매크로로 처리할 수 있습니다.
;This macro returns the pointer to
;Function Table in fnTblPtr
GetFnTblPtr MACRO envPtr, fnTblPtr
mov ebx, envPtr
mov eax, [ebx]
mov fnTblPtr, eax
ENDM
위의 코드로 정의되는 매크로는 매개변수 두 개를 취합니다. 첫 번째는 JNIEnv 포인터이고, 두 번째는 이 매크로가 해당 포인터를 반환하게 될 함수 테이블의 위치를 가리킵니다. 매크로는 함수 테이블 포인터를 eax로 로드한 다음, 이를 fnTblPtr에 저장합니다. 프로그램 자체에 이 매크로를 정의하여 사용할 수도 있습니다. 아니면 여기서 선택한 방법처럼 이러한 매크로를 모두 include 파일에 정의한 다음, include 문을 통해 ASM 프로그램과 함께 이 파일을 사용해도 됩니다. 여기서 사용한 include 파일은 jav_asm.inc입니다. 이 파일은 GetFnTblPtr 매크로뿐 아니라 이 예제에 필요한 다른 매크로도 모두 정의합니다. 또한 jav_asm.inc는 매크로 외에도 JVM을 작성하는 함수의 원형은 물론 해당 함수의 매개변수로 사용할 구조도 정의합니다. 끝으로, java_asm.inc는 사용하기 편리하도록 모든 JNI 함수에 기호 이름을 지정해 줍니다.
함수 테이블에 대한 포인터가 확인되었으면 원하는 함수의 포인터를 검색해야 합니다. 여기 사용되는 코드도 색인 부분을 제외하면 항상 동일합니다. 이 작업은 다음 매크로로 처리합니다.
;This macro returns the pointer
;to a function in fnPtr.
GetFnPtr MACRO fnTblPtr, index, fnPtr
mov eax, index
mov ebx, 4
mul ebx
mov ebx, fnTblPtr
add ebx, eax
mov eax, [ebx]
mov fnPtr, eax
ENDM
이 매크로는 index 값에 4를 곱하고 그 결과를 함수 테이블의 시작 주소(fnTblPtr 참조)에 더하여 액세스할 함수의 포인터를 확인합니다. 그런 다음, 이 포인터를 fnPtr에 저장합니다.
나머지 세 매크로도 처리하는 매개변수의 수만 제외하면 거의 동일합니다.
;The next 3 macros push parameters as per
;stdcall and call the function through fnPtr
CallFunction2 MACRO param1, param2, fnPtr
push param2
push param1
call [fnPtr]
ENDM
CallFunction3 MACRO param1, param2, param3, fnPtr
push param3
push param2
push param1
call [fnPtr]
ENDM
CallFunction4 MACRO param1, param2, param3, param4, fnPtr
push param4
push param3
push param2
push param1
call [fnPtr]
ENDM
보시다시피 이들 매크로는 fnPtr을 제외하고 stdcall을 위해 매개변수를 역순으로 푸시(push)한 다음, fnPtr을 포인터로 사용하여 해당 함수를 호출합니다.
이로써 기본적인 빌딩블록이 완성되었습니다. 이제 데모 애플리케이션의 4단계 시퀀스를 살펴보겠습니다.
JVM 인스턴스 작성
JInvoke는 명령줄에서 자바 애플리케이션을 실행할 때 java 명령이 하는 것과 거의 비슷한 방식으로 JVM 인스턴스를 작성합니다. 구현된 자바 가상 시스템(JVM)은 기본 애플리케이션이 가상 시스템을 로드할 수 있도록 하는 호출 인터페이스라는 메커니즘을 제공합니다. java 명령은 이 호출 인터페이스를 사용하는 C 프로그램을 호출하여 자바 애플리케이션을 실행하고, JInvoke도 바로 이 인터페이스를 사용합니다. JVM을 로드하는 코드는 다음과 같습니다.
.
.
.
va vm_args <>
jvmo JavaVMOption <>
.
.
.
mov jvmo.optionString, offset opzero
mov va.options, offset jvmo
mov va.version, 00010002h
mov va.nOptions,1
mov va.ignoreUnrecognized, TRUE
invoke JNI_CreateJavaVM, offset JavaVM, offset JNIEnv,
offset va
여기서는 우선 구조 두 개를 선언하겠습니다. 이미 설명했듯이 이 구조는 jav_asm.inc에 정의되어 있습니다. JVM을 작성하려면 몇 가지 매개변수를 지정해야 합니다. 지정된 매개변수는 이 구조를 통해 JNI_CreateJavaVM 함수로 전달됩니다.
이 예제에서는 AsmToJava 클래스의 main 메소드를 호출하겠습니다. 제 컴퓨터의 C:\j2sdk1.4.2_05\testjni 폴더에 클래스 파일이 들어 있습니다. JNI 사양에 설명된 방법에 따라 opzero 문자열로 이 경로를 정의합니다. opzero가 jvmo 구조로 로드되고, 그 다음에 jvmo에 대한 오프셋이 va 구조로 로드됩니다. JNI_CreateJavaVM 함수로 전달되는 마지막 매개변수는 va입니다. 따라서 로드된 JVM은 우리가 원하는 클래스를 어디서 찾아야 하는지 알게 됩니다.
JNI_CreateJavaVM은 반환과 동시에 성공한 경우에는 eax에 0을, 실패한 경우에는 eax에 음수값을 반환합니다. 함수로 JVM 인스턴스를 작성하는 데 성공한 경우에는 JVM 인터페이스에 대한 포인터와 해당하는 JNIEnv 포인터를 각각 JavaVM 및 JNIEnv에서 사용할 수 있습니다.
JNI_CreateJavaVM 함수로 반환된 JInvoke는 즉시 eax의 내용을 확인합니다. 값이 0이 아니면 JVM이 로드되지 않은 것입니다. 사용자에게 이를 알리는 메시지가 표시되고 프로세스는 종료됩니다.
.if eax == 0
.
.
.
.else
invoke MessageBox, 0, addr Fail1Text,
addr Caption, 16; failed to create JVM
.endif
한편, eax의 내용이 0이라면 해당하는 메시지를 담은 메시지 상자(그림 2)가 표시되고 다음 단계가 실행됩니다.
.if eax == 0
invoke MessageBox, 0, addr VmText,
addr Caption, 64; indicate success
단, JInvoke는 개념 제시를 위한 수단에 불과하므로 여기서는 가장 간단한 방법으로 JVM 인스턴스를 작성했음을 말씀드립니다. Sheng Liang이 책에서 설명했듯이 이 밖에도 다양한 매개변수를 지정할 수 있습니다.
클래스 찾기
JVM을 로드한 뒤, JInvoke는 원하는 자바 애플리케이션의 시작 지점이 될 클래스를 찾아야 합니다. 아래 코드는 이를 위해 FindClass 함수를 호출합니다.
GetFnTblPtr JNIEnv, fntblptr
GetFnPtr fntblptr, FI_FC, fnptr ; ptr to FindClass
CallFunction2 JNIEnv, offset ProcName,
fnptr ; call FindClass
.if eax != 0
mov classid, eax
invoke MessageBox, 0, addr FcText,
addr Caption, 64; class found
이 클래스 경로는 앞서 jvmo 구조에 로드되었으며(mov jvmo.optionString, offset opzero) 이미 JVM에 알려져 있습니다. FindClass 함수는 클래스를 찾을 수 있는 경우에는 eax에 해당 ID를 반환하고, 그렇지 않으면 0을 반환합니다. 클래스가 발견되면 해당 ID를 저장한 다음, 메시지 상자(그림 3)를 표시하여 사용자에게 알립니다.
클래스를 찾을 수 없는 경우에는 해당하는 메시지와 함께 프로세스가 종료됩니다. 그림 4는 호출한 함수가 성공하지 못했을 때 표시되는 메시지의 예입니다.
메소드 ID 확인
메소드를 호출하려면 해당 ID를 확인해야 합니다. 정적 메소드의 ID를 반환하는 함수는 GetStaticMethodID입니다. 여기서는 AsmToJava 클래스의 main 메소드를 호출하기 위해 이 함수를 사용하겠습니다. 이 함수에는 JNIEnv 외에 다음과 같은 매개변수를 사용할 수 있습니다.
- 해당 메소드가 속한 클래스의 ID. 이전 단계에서 참조한
classid변수입니다. - 메소드 이름.
methodname문자열입니다. - 메소드의 매개변수와 반환 유형을 지정하는 메소드 설명자. 여기서 사용할 메소드의 설명자는
methodsig문자열입니다. 이 경우에 매개변수는String array이고 반환 유형은void입니다. JNI 사양에 관한 Sheng Liang의 책에는 메소드 및 변수의 설명자를 작성하는 방법이 나와 있습니다.
GetStaticMethodID 호출은 지금까지 살펴본 다른 함수 호출과 매우 유사합니다.
GetFnPtr fntblptr, FI_GSMID, fnptr ; ptr to GetStaticMethodID
CallFunction4 JNIEnv, classid, offset methodname,
offset methodsig, fnptr ; GetStaticMethodID
.if eax != NULL
mov methid, eax
invoke MessageBox, 0, addr GsmiText, addr Caption, 64
GetStaticMethodID는 eax에 ID를 반환합니다. 메소드 ID를 확인하는 데 실패한 경우에는 대신 NULL이 반환됩니다. 그리고 JInvoke는 eax의 내용을 확인하여 다음 단계(그림 5)로 진행할지 아니면 프로세스를 종료할지를 결정합니다.
대상 메소드 호출
반환 유형 void로 정적 메소드(여기서는 main 메소드 호출)를 호출하는 JNI 함수는 CallStaticVoidMethod입니다. 다음은 이 함수의 포인터를 확인한 후 필요한 매개변수로 호출하는 코드입니다.
GetFnPtr fntblptr, FI_CSVM, fnptr ; get CallStVM ptr
CallFunction3 JNIEnv, classid, methid, fnptr; call CallStVM
자바 애플리케이션이 성공적으로 실행되었음을 알리는 대화 상자가 나타납니다.
호출한 자바 메소드가 반환되면 JInvoke는 종료됩니다.
ExitProcess 함수를 호출하면 해당 프로세스의 모든 스레드가 정지되며 해당 프로세스에서 작성된 자바 스레드도 정지됩니다. 그러므로 이 방식으로 자바 프로그램을 실행할 때는 필요한 활동이 모두 완료된 뒤에 호출한 자바 메소드가 반환되도록 하는 것이 중요합니다. 실제로 호출 프로세스의 종료 및 JVM에 관한 문제에는 세심한 주의를 기울여야 합니다. 자세한 내용은 Windows API 설명서와 최신 JNI 사양을 참조하십시오.
결론
여기서는 어셈블리 언어 코드로 자바 애플리케이션을 실행하는 데 사용할 수 있는 기본적인 방법을 소개했습니다. 자바 환경에서 안전하게 작업하려면 기본 프로그램에 적절한 오류 확인 기능을 통합해야 합니다. Sheng Liang은 기본 코드의 예외 처리를 비롯하여 다양한 확인 예제를 다루고 있습니다. JNI와 연동되는 ASM 프로그램에는 가급적 이러한 오류 확인 메소드를 사용해야 합니다.
jav_asm.inc 파일을 사용하면 JNI 함수 색인을 손쉽게 지정할 수 있습니다. 번호 대신 기호 이름을 사용하여 색인을 지정하면 오류가 발생할 가능성이 적어집니다. 매크로를 사용하는 것도 오류 감소에 도움이 됩니다. 여러분의 코드에 자유롭게 이 파일을 사용하시고, 필요에 따라 수정하셔도 좋습니다. 그러나 면책 조항 없이 이 파일을 재배포하는 일은 없도록 주의해 주십시오.
JInvoke를 실행할 때 jvm.dll을 찾을 수 없다는 오류 메시지가 나타날 수 있습니다. 이 경우에는 jvm.dll이 포함된 디렉토리 경로를 PATH 환경 변수에 추가해야 할 수 있습니다. 이 DLL은 대개 자바 SDK 루트 폴더의 jre\bin\client 디렉토리에 들어 있습니다. 예를 들어, 제 컴퓨터에서 자바 1.4 릴리스의 해당 경로는 C:\j2sdk1.4.2_05\jre\bin\client입니다. 그러나 자바 1.3을 사용한다면 jre\bin\classic 폴더를 추가해야 합니다. 올바른 경로를 선택하도록 주의하십시오.
끝으로, JInvoke의 include 문에 명명된 파일 경로는 사용자 컴퓨터의 디렉토리 구조에 따라 결정된다는 점을 지적하고 싶습니다. JInvoke에 지정되어 있는 경로는 내 컴퓨터에 해당되는 경로입니다. JInvoke.exe의 경우에는 사용자 시스템에 MASM 구성요소(특히 .inc 또는 .lib 파일)가 로드되지 않아도 실행이 가능합니다. 코드를 수정하여 재컴파일하고 싶으면 해당 디렉토리를 설정한 방식에 맞게 경로 정보를 수정해야 합니다. 그리고 AsmToJava 클래스 파일을 opzero에 정의된 디렉토리에 로드해야 합니다. 아니면 이 클래스의 경로를 적용하여 opzero를 변경해도 됩니다. 그 경우에는 JInvoke의 소스 파일을 재컴파일해야 합니다. 이때 다른 경로 이름도 위의 설명과 같이 수정해야 한다는 점을 잊지 마십시오.
참고 자료
- src.zip: JInvoke 및 AsmToJava의 소스 코드 JInvoke.exe, AsmToJava 클래스 파일과 jav_asm.inc 파일.
- "자바 애플리케이션에서 어셈블리 언어 프로그램 호출." 이 기사에는 보충 정보와 유용한 추가 설명이 수록되어 있습니다.
- The Java Native Interface Programmer's Guide and Specification(자바 네이티브 인터페이스 프로그래머 안내서 및 사양), 저자 Sheng Liang.
- Iczelion의 홈 페이지
Biswajit Sarkar는 프로그램 방식의 산업 자동화를 전문으로 하는 전기공학 엔지니어입니다.
이 글의 영문 원본은
Launch Java Applications from Assembly Language Programs
에서 보실 수 있습니다.
출처 : http://sdnkorea.com
RECENT COMMENT