JDK 업데이트 이후 Eclipse의 Java 실행 환경을 정리하던 중, Java 7을 사용하는 HOME 서버에서 새로운 오류가 발생했다.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
확인 결과, Java 7로 실행하는 서버 설정에 지원되지 않는 --add-opens 옵션이 포함되어 있었다.
해당 옵션을 Java 7에 직접 전달했을 때 동일한 오류가 재현되어 원인을 좁힐 수 있었다.
1. 개발 환경
하나의 Eclipse 워크스페이스에서 프로젝트별로 다른 Java 버전을 사용하고 있었다.
| 워크스페이스 | D:\Project |
| HOME | Java 7 — jdk1.7.0_80 |
| HOME 서버 | Apache Tomcat 8.0.32 |
| KNUMIS | Java 8 — jdk1.8.0_503 |
앞서 게시글 프로젝트에서는 기존 JDK 경로를 찾지 못하는 오류가 발생했고, 새 JDK 등록과 서버 런타임 변경으로 해결했다.
하지만 이번 프로젝트에서 발생한 오류는 원인이 달랐다.
이번에는 Java 실행 파일은 존재했지만, JVM이 시작 단계에서 종료되고 있었다.
2. 오류 메시지만으로 원인을 단정하지 않기
Could not create the Java Virtual Machine은 JVM을 생성하지 못했다는 결과를 알려주는 메시지다.
이 문구만으로 JDK 손상이나 메모리 부족이라고 단정할 수는 없다.
따라서 다음 두 가지를 나누어 확인했다.
- 설치된 Java 7 자체가 실행되는가?
- Eclipse가 Java 7에 어떤 실행 옵션을 전달하는가?
3. Java 7 자체는 정상 실행
PowerShell에서 Java 7의 실행 파일을 직접 지정해 버전을 확인했다.
& 'C:\Program Files\Java\jdk1.7.0_80\bin\java.exe' -version
결과는 다음과 같았다.
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
최소한 Java 7의 기본 실행은 정상적으로 동작했다.
다음으로 Eclipse의 HOME 실행 설정을 확인했다.
4. 원인: Java 7이 지원하지 않는 실행 옵션
문제 프로젝트의 컴파일 설정과 서버 실행 JDK는 모두 Java 7로 지정되어 있었다.
그런데 Run Configurations → 프로젝트명 → Arguments → VM arguments에는 다음 옵션이 포함되어 있었다.
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.base/java.util.concurrent=ALL-UNNAMED
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
Java 7은 이 옵션을 인식하지 못한다.
이를 확인하기 위해 서버를 실행하지 않고, 첫 번째 옵션과 -version만 전달했다.
& 'C:\Program Files\Java\jdk1.7.0_80\bin\java.exe' `
'--add-opens=java.base/java.lang=ALL-UNNAMED' `
-version
동일한 오류가 재현되었다.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Unrecognized option: --add-opens=java.base/java.lang=ALL-UNNAMED
핵심은 마지막 메시지였다.
Unrecognized option: --add-opens=java.base/java.lang=ALL-UNNAMED
JVM이 지원하지 않는 옵션을 전달받아 종료되었고,
Tomcat이나 애플리케이션 코드가 실행되는 단계까지 도달하지 못한 것이다.
5. 해결 방법: 프로젝트의 VM arguments 수정
Eclipse에서 다음 메뉴로 이동한다.
Run → Run Configurations → 프로젝트명 → Arguments
VM arguments에서 --add-opens=... 옵션 5개를 삭제한다.
이때 전체 내용을 지우지 않고, 기존 Tomcat 경로 관련 옵션은 유지한다.
이번 환경에서는 아래 항목들이 남도록 정리하면 된다.
-Dcatalina.base="D:\Project\.metadata\.plugins\org.eclipse.wst.server.core\tmp4"
-Dcatalina.home="D:\apache-tomcat-8.0.32"
-Dwtp.deploy="D:\Project\.metadata\.plugins\org.eclipse.wst.server.core\tmp4\wtpwebapps"
-Djava.endorsed.dirs="D:\apache-tomcat-8.0.32\endorsed"
위 경로는 이번 워크스페이스 기준이다.
다른 환경에서는 기존에 설정된 경로를 유지해야 한다.
설정을 변경한 뒤 Apply → Run으로 서버를 다시 실행한다.
프로젝트가 Java 7을 사용해야 하므로,
옵션 오류를 피하기 위해 서버 JDK를 무작정 다른 버전으로 변경하지는 않는다.
6. 수정 후 확인할 사항
원인 재현 테스트로 Java 7과 --add-opens의 조합이 JVM 생성 오류를 일으킨다는 점은 확인했다.
실제 Eclipse 설정 수정 후에는 다음 항목으로 해결 여부를 검증한다.
- Unrecognized option: --add-opens... 메시지가 사라졌는가?
- JVM 생성 오류 대신 Tomcat 시작 로그가 출력되는가?
- 서버가 시작되고 HOME 애플리케이션에 정상 접속되는가?
JVM 생성 문제가 해결되어도 이후 Tomcat이나 애플리케이션에서 별도 오류가 발생할 수 있다.
그 경우에는 새로 출력된 로그를 기준으로 다음 원인을 분석한다.
7. 추가로 발견한 Classpath 혼재
실행 설정을 확인하는 과정에서 HOME의 Classpath에 다음 두 버전의 Tomcat 라이브러리가 함께 등록되어 있었다.
D:\apache-tomcat-8.0.32\bin\...
D:\apache-tomcat-7.0.109\bin\...
이 구성은 이번 --add-opens 오류와 구분해서 다뤄야 한다.
JVM 생성 오류는 Java 7에 해당 옵션을 전달하는 것만으로 재현되었기 때문이다.
옵션을 수정한 뒤에도 서버 시작이나 클래스 로딩 문제가 남는다면,
문제 프로젝트가 사용하는 Tomcat 8.0.32 런타임을 기준으로 Classpath를 점검해야 한다.
사용자 지정 라이브러리가 있을 수 있으므로 기존 설정을 기록한 뒤 정리하는 것이 좋다.
8. 이번 사례에서 얻은 점
하나의 Eclipse에서 프로젝트마다 다른 Java 버전을 사용하는 것 자체는 문제가 아니다.
중요한 것은 각 서버에 지정된 Java 버전과 VM 실행 옵션이 서로 호환되는지다.
또한 프로젝트의 컴파일 수준이 1.7로 설정되어 있다고 해서 실행 옵션까지 Java 7에 맞게 검증되는 것은 아니다.
문제가 발생하면 프로젝트 설정뿐 아니라 서버 런타임과 개별 실행 설정도 함께 확인해야 한다.
이번 사례에서 확인된 직접 원인은 Java 7 서버 실행 설정에 포함된 미지원 옵션이다.
JDK 업데이트 이후 문제를 발견했지만,
해당 옵션이 언제 어떤 과정으로 추가됐는지까지는 확인하지 못했다.
따라서 업데이트가 옵션을 추가했다고 단정하지 않고, 재현으로 확인한 원인을 중심으로 기록했다.