[JAVA] 라이브러리와 모듈

dev_swanim·2023년 4월 17일

JAVA 문법

목록 보기
8/10
post-thumbnail

1. 라이브러리

  • 라이브러리 : 프로그램 개발 시 활용할 수 있는 클래스와 인터페이스를 모아놓은 것
  • JAR(Java ARchive) 압축파일(~.jar) 형태로 존재
    • 클래스, 인터페이스의 바이트코드 파일(~.class)들이 압축됨
  • 특정 클래스와 인터페이스가 여러 응용 프로그램 개발 시, 공통으로 자주 사용되면 JAR 파일로 압축해 라이브러리로 관리하는 게 좋음



인텔리제이에서 jar 파일 만들기

상단의 file → project structure


Artifacts → JAR → From modules with dependencies


Main Class에서 선택 → OK 누르고 진행

Apply → OK 누르고 나와서

상단에 있는 Build → Build Artifacts 선택


Action에서 Build 선택


out 폴더 - artifacts → jar 파일 생성된 것 확인할 수 있다.


터미널 창에서 jar 파일이 제대로 실행되는지 확인해보자. 별다른 에러 없이 실행 잘 된다면 성공한 것이다.







2. 모듈

  • 모듈 : 패키지 관리 기능까지 포함하는 라이브러리 → 모듈은 작은 프로젝트이다!
    • 일부 패키지를 은닉하여 접근할 수 없게 한다. (일반 라이브러리는 내부에 포함된 모든 패키지에 외부 프로그램에서의 접근이 가능)
  • 의존 모듈을 모듈 기술자(module-info.java)에 기술할 수 있기 때문에 모듈 간의 의존관계를 쉽게 파악 가능)
    • (a모듈은 B모듈이 있어야 실행가능, B모듈은 C모듈이 있어야 실행 가능)
  • JAR 파일 형태로 배포 가능
  • 모듈별로 개발하고 조립 → 재사용성 및 유지보수에 유리


• 모두 Gradle 프로젝트로 생성


settings.gradle(루트 프로젝트의 gradle)에 core, study 모듈이 정상적으로 들어간 것을 확인할 수 있다.








3. 모듈 배포용 JAR 파일

  • 바이트코드 파일(.class)로 구성된 배포용 JAR 파일 생성
    ➕ A라는 모듈을 배포하기 위해 모듈 기술자(module-info.java) 를 작성한다. exports 키워드를 이용해 모듈이 가지고 있는 패키지를 외부에서 사용할 수 있도록 노출시킨다.
package pack1;

public class A{
	//메소드 선언
	public void method(){
		System.out.println("A-method 실행");
	}
}
 module my_module_a{
	exports pack1;
	exports pack2;
}

배포한 JAR 파일 적용하기

모듈 내용 사용해 코드 짜기

package app;

import pack1.A;
import pack2.B;
import pack3.C;

public class Main {
	public static void main(String[] args) {
		//my_module_a 패키지에 포함된 A 클래스 이용
		A a = new A();
		a.method();

		//my_module_a 패키지에 포함된 B 클래스 이용
		B b = new B();
		b.method();

		//my_module_b 패키지에 포함된 C 클래스 이용
		C c = new C();
		c.method();
	}
}







4. 패키지 은닉

  • 모듈은 모듈 기술자(module-infro.java)에서 exports 키워드를 사용해 내부 패키지 중 외부에서 사용할 패키지를 지정. exports 되지 않은 패키지는 자동으로 은닉


모듈이 일부 패키지를 은닉하는 이유

  1. 모듈 사용방법 통일
    • 모듈 외부에서 패키지2와 3을 사용하지 못하도록 막고, 패키지1로 사용방법 통일
  2. 쉬운 수정
    • 모듈 성능 향상을 위해 패키지 2와 3을 수정하더라도 모듈 사용방법(패키지1)이 달라지지 않으므로 외부에 영향 주지x






5. 전이 의존

  • my_application
    • my_module_a
    • my_module_b

구조였던 의존관계를

my_application → my_module_a → my_module_b

구조로 변경한다고 생각해보자.

module my_module_a{
	exports pack1;
	requires transitive my_module_b; //my_module_b 모듈 의존 설정
}
module my_application{
	requires my_module_a;
	//requires my_module_b; b에 대한 의존성 해제
}







6. 집합 모듈

  • 여러 모듈을 모아놓은 모듈
  • 자주 사용되는 모듈들을 하나하나 다 requires 하는 번거로움을 피하기 위해 사용
  • 집합 모듈은 자체적인 패키지를 가지지 않고 모듈 기술자에 전이 의존 설정만 한다
module my_module{
	requires transitive my_module_a
	requires transitive my_module_b
}







7. 리플렉션 허용

  • 리플렉션(reflection) : 실행 도중에 타입(클래스, 인터페이스 등)을 검사하고 구성 멤버를 조사하는 것
  • 은닉된 패키지는 기본적으로 다른 모듈에 의해 리플렉션을 허용하지 않는다
  • 경우에 따라 은닉된 패키지도 리플렉션을 허용해야 하는 경우가 있다.
    • 모듈은 모듈 기술자를 통해 모듈 전체 또는 지정된 패키지에 대한 리플렉션을 허용
    • 특정 외부 모듈에서만 리플렉션을 허용할 수도

모듈 전체를 리플렉션 허용

open module 모듈명{
} 

지정된 패키지에 대해 리플렉션 허용

module 모듈명{
	opens 패키지1;
	opens 패키지2;
}

지정된 패키지에 대해 특정 외부 모듈에서만 리플렉션 허용

module 모듈명{
	opens 패키지1 to 외부모듈명, 외부모듈명, ...;
	opens 패키지2 to 외부모듈명;
}







8. 자바 표준 모듈

  • java.base는 모든 모듈이 의존하는 기본 모듈
    • requires하지 않아도 사용할 수 있지만, 다른 모듈들은 모듈 기술자에 requires를 명시해야함





📚참고 문헌

이것이 자바다(신용권, 임경균 지음)

profile
데이터와 백엔드를 공부하고 있습니다😌

0개의 댓글