패키지는 비슷한 목적으로 생성된 클래스 파일들을 한곳에 모아둔 폴더를 의미한다. 프로그램을 작 ㅂ성하다 보면 각각의 목적에 따라 여러 개의 클래스 파일(네트워크 처리를 위한 클래스 10개, GUI 처리를 위한 클래스 8개 등)들이 생긴다. 이렇게 동일한 목적으로 만들어진 클래스들을 1개의 공간(폴더)에 묶어 관리하기 위해 사용하는 것이 바로 '패키지'다. 1개의 프로젝트에 1개의 패키지를 생성할 수도 있고 여러 개의 패키지를 생성할 수도 있다. 패키지를 아예 생성하지 않아도 문법적으로는 전혀 문제가 없다. 패키지를 아예 생성하지 않아도 문법적으로는 전혀 문제가 없다. 생성된 패키지를 폴더의 구조상으로 보면 src 폴더의 하위 폴더에 위치한다. 컴파일이 수행되면 바ㅣ트 코드가 저장되는 bin 폴더에도 동일한 하위 폴더가 생성된다.
예를 들어 다음과 같이 소스 코드를 생성하는 과정에서 패키지를 지정하지 않고 소스 파일을 생성할 때와 mypack.text라는 이름의 패키지를 생성하고 이 패키지 아래에 소스 파일(PackageTest2.java)을 생성할 때를 고려해 보자.
패키지를 지정하지 않으면 src 폴더 아래에 소스 파일이 바로 위치한다. 아래 그림에서 (default package)는 하위 폴더가 없음을 의미한다. 반면 패키지를 지정하면 지정된 패키지 폴더가 src 폴더 아래에 생성되며, 그 아래에 소스 파일이 위치한다. 다음은 위 두 예의 폴더 구조를 나타낸다.
패키지의 폴더 구조를 살펴봤으니 이번에는 패키지의 생성 유무에 따른 소스 코드의 차이를 알아보자. 패키지를 생성하지 않았을 때 클래스의 외부 요소인 package 구문은 포함되지 않았으며 패키지가 있을 때는 소스 코드의 첫 번째 줄에 반드시 'package 패키지명'이 명시돼 있어야 한다.
🐘패키지를 생성하지 않았을 때
// package 구문 미포함
public class PackageTest1 {
}🐘패키지를 생성했을 때
package mypack.test // package 구문 포함
public class PacakgeTest2 {
}패키지 사용으로 얻을 수 있는 또 1개의 장점은 바로 패키지의 영향으로 클래스가 저장되는 공간이 분리돼 클래스명의 충돌을 방지할 수 있다는 것이다. 만일 다음과 같이 A,B회사가 협업해 프로젝트를 진행한다고 가정해 보자.
A,B 회사에서 만든 클래스명이 둘다 Connect라면 이름이 중복돼 이후 클래스들을 통합할 때 문제가 발생할 수 있다. 이때 A회사는 abc.bcd 패키지, B 회사는 bcd.cde 패키지를 사용한다면 A 회사의 Connect 클래스 경로는 abc.bcd.Connect이고 B회사는 bcd.cde.Connect다. 여기서 abc.bcd.Connect는 프로젝트의 src 폴더를 기준으로 abc 폴더 안에 있는 bcd 폴더 안에 Connect.java가 있다는 뜻이다. 이렇게 서로 다른 패키지를 사용하면 그 안에 있는 클래스명이 같더라도 경로가 다르므로 충돌 문제가 발생하지 않는다. 그런데 두 회사가 패키지명까지 동일하게 사용하면 어떻게 될까? 당연히 패키지 명과 클래스명이 모두 같다면 두 클래스를 통합할 수 없을 것이다. 따라서 일반적으로 패키지명에는 회사의 URL 주소를 사용한다. 회사의 URL은 이미 유일한 값이라는 것을 보장받은 상황이므로 이를 패키지명으로 사용하면 두 회사가 클래스명을 아무리 똑같이 만들어도 통합에 전혀 문제가 없을 것이다.
