「Java는 OS에 의존하지 않는다」 제대로 설명할 수 있을까 나?
소개
Java에 관한 일은 타인에게 제대로 설명할 수 있는 「츠요츠요 Java 엔지니어」가 되기 위한 첫걸음의 기사
당연한 일이지만, 다시 OUTPUT하여 정리하기 쉽다.
우선 결론
OS에 의존하지 않는 이유는 「실행 환경(JVM)에서 바이트 코드를 OS에 맞춘 기계어로 변환한다」로부터
잘 보자.
프로그래밍 언어는 2종류로 나뉜다.
「컴파일러 방식」과 「인터프리터 방식」
인터프리터 방식은 소스 코드를 기계어로 변환하면서 실행한다.
컴파일러 방식은, 소스 코드를 사전에 기계어로 변환하고 나서, 단번에 실행한다.
차이는 “사전에 기계어로 변환할지 어떨지”다.
이 두 가지. 사전에 기계어로 변환할지 여부에 따라 ↓와 같은 차이가 생긴다.
인터프리터 방식의 Bad인 곳이 컴파일러 방식으로는 실현되고 있다.
컴파일러 방식의 Bad인 곳이 인터프리터 방식으로는 실현되고 있다.
·
·
·
이것은, 인터프리터 방식과 컴파일러 방식을 융합하면 좋다고 취할 수 있는 것은....!!
·
·
·
자바 「그리고, 내가 태어났다는 거야」
인터프리터 방식과 컴파일러 방식을 융합시킨 Java란?
이런 느낌.
↑와 같이, 컴파일러 방식의 좋은 곳과 인터프리터 방식의 좋은 곳만을 흡수할 수 있었다.
야야코시 포인트 1:Java는 2회 컴파일 하고 있다
기계어로 변환할 때도 「컴파일」이라고 하고, 바이트 코드로 변환할 때도 「컴파일」이라고 한다.
Java의 개발 현장에서 「컴파일」이라고 하면 9할 9분 「java 파일을 class 파일로의 변환」을 가리키고 대화하지만, 당연히 Java도 기계어로 변환되어 실행되므로 「Java는 2 회 컴파일되고 있다”라고 말할 수 있는 것이다.
야야코시 포인트 2:JVM내에는 「인터프리터」와 「컴파일러」의 2개가 있어, 양쪽 모두 사용된다.
①java파일 → ②class파일 → ③기계어
JVM 내에서는 ②에서 ③에 걸쳐 「인터프리터 방식」 「컴파일러 방식」의 양쪽에서 기계어로의 변환이 가능하다.
「정리해 기계어로 컴파일하고 나서 실행하는 것이 이 처리는 효율 좋지요」같은 것은 컴파일러 방식을 채용해, 그렇지 않은 경우는 인터프리터 방식으로 실행한다고 하는 상태다.
※자신용 MEMO
인터프리터의 무엇이 좋은지, "런타임"에 OS에 맞게 기계어로 변환하기 때문에 OS에 의존하지 않는 것. 그래서 "OS에 의존하고 싶지 않다면 인터프리터 1택인가!"라고 생각하고 있었지만, Java에서는 "런타임"에 (JVM 런타임 환경에서) 인터프리터와 컴파일러를 모두 사용할 수 있으므로, 이해의 방법으로서는 【Java JVM에서 실행될 때 기계어로 변환하기 때문에 OS에 의존하지 않는다.
포인트 정리
✔︎ 실행 전에 컴파일(class 파일로의 변환)을 하는 것으로, 에러 검지해 수정할 수 있다.
✔︎ 일반 컴파일(기계어로 변환)에서는 컴파일 시점에서 실행 환경이 되는 OS가 확정되어 버리는(OS에 의존해 버린다), Java에서는 컴파일의 아티팩트를 OS에 의존하지 않는 것(기계 단어가 아니라 class 파일)로 하고 있으므로 「실행전에 사전에 컴파일하고 있는데 OS에 의존하고 있지 않다!」가 된다.
✔︎ Java에서는 실행 환경에서 「바이트 코드→기계어」의 컴파일을 할 수 있다. JIT 컴파일러!
Reference
이 문제에 관하여(「Java는 OS에 의존하지 않는다」 제대로 설명할 수 있을까 나?), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/crml1206/items/950ae6ce6d8f20a84fb4
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
OS에 의존하지 않는 이유는 「실행 환경(JVM)에서 바이트 코드를 OS에 맞춘 기계어로 변환한다」로부터
잘 보자.
프로그래밍 언어는 2종류로 나뉜다.
「컴파일러 방식」과 「인터프리터 방식」
인터프리터 방식은 소스 코드를 기계어로 변환하면서 실행한다.
컴파일러 방식은, 소스 코드를 사전에 기계어로 변환하고 나서, 단번에 실행한다.
차이는 “사전에 기계어로 변환할지 어떨지”다.
이 두 가지. 사전에 기계어로 변환할지 여부에 따라 ↓와 같은 차이가 생긴다.
인터프리터 방식의 Bad인 곳이 컴파일러 방식으로는 실현되고 있다.
컴파일러 방식의 Bad인 곳이 인터프리터 방식으로는 실현되고 있다.
·
·
·
이것은, 인터프리터 방식과 컴파일러 방식을 융합하면 좋다고 취할 수 있는 것은....!!
·
·
·
자바 「그리고, 내가 태어났다는 거야」
인터프리터 방식과 컴파일러 방식을 융합시킨 Java란?
이런 느낌.
↑와 같이, 컴파일러 방식의 좋은 곳과 인터프리터 방식의 좋은 곳만을 흡수할 수 있었다.
야야코시 포인트 1:Java는 2회 컴파일 하고 있다
기계어로 변환할 때도 「컴파일」이라고 하고, 바이트 코드로 변환할 때도 「컴파일」이라고 한다.
Java의 개발 현장에서 「컴파일」이라고 하면 9할 9분 「java 파일을 class 파일로의 변환」을 가리키고 대화하지만, 당연히 Java도 기계어로 변환되어 실행되므로 「Java는 2 회 컴파일되고 있다”라고 말할 수 있는 것이다.
야야코시 포인트 2:JVM내에는 「인터프리터」와 「컴파일러」의 2개가 있어, 양쪽 모두 사용된다.
①java파일 → ②class파일 → ③기계어
JVM 내에서는 ②에서 ③에 걸쳐 「인터프리터 방식」 「컴파일러 방식」의 양쪽에서 기계어로의 변환이 가능하다.
「정리해 기계어로 컴파일하고 나서 실행하는 것이 이 처리는 효율 좋지요」같은 것은 컴파일러 방식을 채용해, 그렇지 않은 경우는 인터프리터 방식으로 실행한다고 하는 상태다.
※자신용 MEMO
인터프리터의 무엇이 좋은지, "런타임"에 OS에 맞게 기계어로 변환하기 때문에 OS에 의존하지 않는 것. 그래서 "OS에 의존하고 싶지 않다면 인터프리터 1택인가!"라고 생각하고 있었지만, Java에서는 "런타임"에 (JVM 런타임 환경에서) 인터프리터와 컴파일러를 모두 사용할 수 있으므로, 이해의 방법으로서는 【Java JVM에서 실행될 때 기계어로 변환하기 때문에 OS에 의존하지 않는다.
포인트 정리
✔︎ 실행 전에 컴파일(class 파일로의 변환)을 하는 것으로, 에러 검지해 수정할 수 있다.
✔︎ 일반 컴파일(기계어로 변환)에서는 컴파일 시점에서 실행 환경이 되는 OS가 확정되어 버리는(OS에 의존해 버린다), Java에서는 컴파일의 아티팩트를 OS에 의존하지 않는 것(기계 단어가 아니라 class 파일)로 하고 있으므로 「실행전에 사전에 컴파일하고 있는데 OS에 의존하고 있지 않다!」가 된다.
✔︎ Java에서는 실행 환경에서 「바이트 코드→기계어」의 컴파일을 할 수 있다. JIT 컴파일러!
Reference
이 문제에 관하여(「Java는 OS에 의존하지 않는다」 제대로 설명할 수 있을까 나?), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/crml1206/items/950ae6ce6d8f20a84fb4
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
✔︎ 실행 전에 컴파일(class 파일로의 변환)을 하는 것으로, 에러 검지해 수정할 수 있다.
✔︎ 일반 컴파일(기계어로 변환)에서는 컴파일 시점에서 실행 환경이 되는 OS가 확정되어 버리는(OS에 의존해 버린다), Java에서는 컴파일의 아티팩트를 OS에 의존하지 않는 것(기계 단어가 아니라 class 파일)로 하고 있으므로 「실행전에 사전에 컴파일하고 있는데 OS에 의존하고 있지 않다!」가 된다.
✔︎ Java에서는 실행 환경에서 「바이트 코드→기계어」의 컴파일을 할 수 있다. JIT 컴파일러!
Reference
이 문제에 관하여(「Java는 OS에 의존하지 않는다」 제대로 설명할 수 있을까 나?), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/crml1206/items/950ae6ce6d8f20a84fb4텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)