FatJar
e-mail: gerecter at gmail.com | 처음 | 업데이트목록 | 가나다순목록 | 지도 | 검색 |

라이브러리를 포함한 Jar 파일을 export 하자

여러가지 라이브러리를 이용해서 이클립스에서 Java 프로그램을 만들었다고 합시다. 그러면, 이 프로그램을 다른 사람에게 건네주려면, 무슨무슨 라이브러리가 필요하다는 이야기와 함께 건네 준뒤, 그 사람이 그 라이브러리들을 다 모아서 같은 환경을 만든뒤에 돌리게 됩니다.

하지만, 이렇게 라이브러리를 모으는 과정은 무척 귀찮습니다. 더군다나, 프로그램을 만들때 모았던 라이브러리와 나중에 다른 사람이 모으는 라이브러리에 미묘한 차이가 있어서 뭔가 종잡을 수 없이 실행이 되지 않는 경우도 있습니다.

그런데, Fat Jar 라는 이클립스 플러그인들은 여러가지 라이브러리를 사용하면, 그 라이브러리에서 사용한 부분들을 뽑아서 프로그램 패키지 내부에 복사해서 넣어줍니다. 이렇게 되면, 이렇게 만들어진 뚱뚱한 jar 패키지만 남에게 복사해주면, 따로 그 사람이 라이브러리를 모을 필요없이 내부에 포함된 복제본 라이브러리로 바로 돌릴 수 있게 됩니다.


(Fat Jar 를 쓰는 모양)

문제

원초적인 문제는, 많은 라이브러리들이 저작권 상 이렇게 마음대로 남에게 복사해주거나 쪼개서 배포하는 것을 허용하지 않는 경우가 있다는 것입니다. 물론 통째로라도 재배포자체만 자유롭다면 Fat Jar 를 통째로 라이브러리를 가져와서 배포하는 기능도 있기는 합니다.

좀 더 큰 문제는, 이렇게 라이브러리를 포함시켜서 배포하게 되면, 애초에 라이브러리를 분리해 놓은 동적인 환경의 이점을 살리지 못한다는 것입니다. 예를 들면, 더 강화된 새 버전의 라이브러리가 나왔을 때, 그 라이브러리만 바꿔서 더 강력한 기능을 체험한다든가, 아니면 자신의 컴퓨터가 매우 특수해서 라이브러리 자체에 어떤 조건을 걸어야만 동작한다든가 하는 경우에, 일일히 패키지 내부의 복제본 라이브러리까지 손으로 고쳐 줘야 하는 문제가 있다는 것입니다.

또다른 가능성

그런데 쓰다보니, Fat Jar 에는 또다른 가능성이 있습니다. 여러가지 소프트웨어를 모아서 사용하거나 개량한다거나 급속하게 프로그램을 개발할 때, Fat Jar 가 소프트웨어를 패키징 하면서 모듈화하는 역할을 하게 되고 이것이, 프로그램 수정이나 디버깅에 용이하다는 것입니다.

예를 들면, 어떤 라이브러리를 개량하거나 수정하면서 프로그램을 만들고 있는데, 중간단계에서 호환성을 장담할 수 없을 때가 있습니다. 그런 와중에 그 개량이나 수정의 영향에 독립적으로 돌아가는 모듈을 돌릴 필요가 있을 때, 이렇게 라이브러리의 복제본을 포함하고 있는 Fat Jar는 유용합니다.

예를 들면, 은행 DB 라이브러리를 고객 정보 조사에 좋도록 고성능 바이너리로 교체하고 있는데, 그 와중에도 입출금 기능은 항상 정상적으로 작동 되어야만 하는 경우가 있습니다. 이럴 경웨, 입출금 모듈 등은 Fat Jar 형태로 돌게 해두고, 고객 정보 조사에 좋은 고성능 라이브러리를 완성한 뒤 호환성이 검증되었을 때, Fat Jar가 아닌 새로 만든 고성능 라이브러리를 사용하는 입출금 모듈이 되도록 하는 겁니다.

이래저래 유용한 Fat Jar 는 패키징하고 Closing 하는 프로그램임에도 불구하고, 결국 Eclipse의 OpenStrucutre* 때문에 쉽게 만들어질 수 있는 플러그인이었습니다. OpenSturcture* 가 가져오는 편리함의 한 예시이자, 캡슐화와 모듈화, 은닉화가 어떻게 재사용성을 높일 수 있는지에 대한 생각할 예시가 됩니다.



(마지막 변경 UNIX clock : 1169627678 / Common clock 2007.01.24, 5:34 pm )
다음글 RobotHumanism


gerecter의 다른 웹사이트들: 영화/책 - 도시전설 - 고전전산 - 평론기계