JVM을 실행해야 할 때 Java 플랫폼에 어떻게 독립적입니까?
방금 Java를 배우기 시작했고 플랫폼 독립성에 대해 혼란 스럽습니다.
"독립적"이라는 것은 Java 코드가 모든 시스템에서 실행되어야하며 특별한 소프트웨어를 설치할 필요가 없다는 것을 의미하지 않습니까? 그러나 JVM이 시스템에 있어야합니다.
예를 들어, C / C ++ 소스 코드를 컴파일하고 실행하려면 Turbo C 컴파일러가 필요합니다. 기계에는 C 컴파일러가 있어야합니다.
누군가 Java가 "플랫폼 독립적"으로 설명 될 때 의미하는 바를 기쁘게 생각할 수 있습니까?
일반적으로 컴파일 된 코드는 CPU가 프로그램을 "실행"하는 데 필요한 정확한 명령 집합입니다. Java에서 컴파일 된 코드는 모든 물리적 시스템에서 동일하게 작동하는 데 필요한 "가상 CPU"에 대한 정확한 명령 집합입니다.
그래서 어떤 의미에서 자바 언어의 설계자들은 언어와 컴파일 된 코드가 플랫폼 독립적이 될 것이라고 결정했지만 결국 코드는 물리적 플랫폼에서 실행되어야하므로 모든 플랫폼 종속 코드를 JVM.
JVM에 대한이 요구 사항은 Turbo C 예제와 대조됩니다. Turbo C를 사용하면 컴파일러가 플랫폼 종속 코드를 생성하고 컴파일 된 Turbo C 프로그램이 CPU에 의해 직접 실행될 수 있기 때문에 JVM과 유사하게 작동 할 필요가 없습니다.
Java를 사용하면 CPU가 플랫폼에 따라 JVM을 실행합니다. 이 실행중인 JVM은 실행에 사용할 수있는 JVM이있는 경우 플랫폼 독립적 인 Java 바이트 코드를 실행합니다. Java 코드를 작성하고 실제 머신에서 실행할 코드를 프로그래밍하지 않고 Java 가상 머신에서 실행할 코드를 작성한다고 말할 수 있습니다.
이 모든 Java 바이트 코드가 모든 Java 가상 머신에서 작동하는 유일한 방법은 Java 가상 머신의 작동 방식에 대해 다소 엄격한 표준이 작성되었다는 것입니다. 즉, 어떤 물리적 플랫폼을 사용하든 Java 바이트 코드가 JVM과 인터페이스하는 부분은 단방향으로 만 작동합니다. 모든 JVM이 정확히 동일하게 작동하기 때문에 동일한 코드가 다시 컴파일하지 않고도 모든 곳에서 동일하게 작동합니다. 동일한 지 확인하기위한 테스트를 통과 할 수없는 경우 가상 머신을 "Java 가상 머신"이라고 부를 수 없습니다.
물론 자바 프로그램의 이식성을 깨는 방법이 있습니다. 하나의 운영 체제에서만 찾을 수있는 파일을 찾는 프로그램을 작성할 수 있습니다 (예 : cmd.exe). JNI를 사용하면 컴파일 된 C 또는 C ++ 코드를 클래스에 효과적으로 넣을 수 있습니다. 특정 운영 체제에서만 작동하는 규칙을 사용할 수 있습니다 (예 : ":"가 디렉토리를 구분한다고 가정). 그러나 JNI와 같은 특별한 작업을 수행하지 않는 한 다른 시스템에 대해 프로그램을 다시 컴파일 할 필요가 없습니다.
Technical Article on How java is platform indepedent?
세부 사항으로 들어가기 전에 먼저 플랫폼의 의미를 이해해야합니까? 플랫폼은 컴퓨터 하드웨어 (주로 마이크로 프로세서 아키텍처)와 OS로 구성됩니다. 플랫폼 = 하드웨어 + 운영 체제
플랫폼에 독립적 인 것은 모든 운영 체제 및 하드웨어에서 실행될 수 있습니다.
Java는 플랫폼에 독립적이므로 Java는 모든 운영 체제 및 하드웨어에서 실행할 수 있습니다. 이제 질문은 어떻게 플랫폼 독립적입니까?
이는 OS에 무관 한 Byte Code의 마법 때문입니다. 자바 컴파일러가 코드를 컴파일 할 때 C 컴파일러와 달리 머신 네이티브 코드가 아닌 바이트 코드를 생성합니다. 이제이 바이트 코드는 기계에서 실행하기 위해 인터프리터가 필요합니다. 이 인터프리터는 JVM입니다. 그래서 JVM은 그 바이트 코드를 읽고 (즉, 기계 독립적) 그것을 실행합니다. 다른 JVM은 다른 OS를 위해 설계되었으며 바이트 코드는 다른 OS에서 실행될 수 있습니다.
C 또는 C ++ (플랫폼 독립적이 아닌 언어) 컴파일러의 경우 OS 종속적 인 .exe 파일을 생성하므로 다른 OS에서이 .exe 파일을 실행할 때이 파일이 OS 종속적이기 때문에 실행되지 않습니다. 다른 OS.
마지막으로 중간 OS 독립 바이트 코드는 자바 플랫폼을 독립적으로 만듭니다.
이는 Java 프로그래머가 (이론적으로) 기계 또는 OS 세부 사항을 알 필요가 없음을 의미합니다. 이러한 세부 정보가 존재하며 JVM 및 클래스 라이브러리가이를 처리합니다. 또한 C와는 대조적으로 Java 바이너리 (바이트 코드)는 수정이나 재 컴파일없이 완전히 다른 시스템으로 이동할 수 있습니다.
아니, 그 반대입니다. Java 프로그램이 독립적 인 가상 머신을 사용하기 때문입니다.
가상 머신은 독립적이지 않으므로 시스템 유형에 맞게 특별히 제작 된 가상 머신을 설치해야합니다. 가상 머신은 운영 체제 위에 독립적 인 플랫폼을 생성합니다.
JVM은 다른 시스템에 설치할 수있는 "시뮬레이션 된 기계"입니다. 이러한 방식으로 동일한 Java 코드가 운영 체제 자체가 아닌 JVM에 의존하기 때문에 다른 시스템에서 실행할 수 있습니다.
즉, 프로그래머가 특정 머신 및 OS 기능 대신 가상 시스템 (JVM)과 통신하고 해당 기능을 활용할 수 있습니다. Java는 JVM에만 의존하므로 플랫폼에 독립적입니다 (플랫폼에 JVM이 설치된 경우).
요컨대, Java는 플랫폼에 독립적이지 않으므로 실행해야하는 모든 시스템에 대해 JVM 설치가 필요합니다. 그러나 JVM이 설치된 모든 시스템에서 실행됩니다.
Java는 JVM (Java Virtual Machine)이 있으므로 플랫폼에 독립적입니다. 실생활의 예를 들어 설명하겠습니다. 가족에게 자유 롭다고 가정 해 봅시다. 그런데 왜?
당신은 그들을 잘 알고 그들도 당신을 알고 있기 때문입니다. 그러나 당신은 내 가족에게 자유롭지 않습니다. 당신이 그들을 모르고 그들도 당신을 모르기 때문입니다. 하지만 내가 당신의 친구이고 당신을 가족들에게 소개 할 수 있다면 당신은 그들과 자유롭게 대화 할 수있을 것입니다.
비슷한 방식으로, 당신이 코드이고 내가 JVM이라면. 또한 귀하의 가족은 Windows 플랫폼이고 내 가족은 Linux 플랫폼입니다. C 또는 기타 플랫폼 종속 언어 인 경우 가족 구성원 만 알고 그 반대의 경우도 마찬가지입니다. 그렇기 때문에 귀하가 작성한 플랫폼 만이 해당 코드를 알고 지원할 것입니다. 그러나 당신이 JAVA 코드이고 우리 가족에게 올 때. Linux 플랫폼과 저를 찾으면 JVM, 내 가족 인 Linux 플랫폼을 소개해 드리고 상호 작용할 수 있습니다.
플랫폼에 의존하는 언어의 경우 어떤 플랫폼 제품군에도 자신을 소개 할 수있는 JVM과 같은 친구가 없습니다. 이것이 Java가 플랫폼에 독립적 인 방식입니다. :)
JVM은 구체적인 플랫폼에서 추상화됩니다. 프로그램은 JVM에만 의존하고 JVM은 Windows 및 Linux와 같은 다른 플랫폼에서 사용할 수 있으므로 프로그램은 플랫폼 독립적입니다 (하지만 jvm에 따라 다름).
c / c ++에서 컴파일러를 사용하여 컴파일 한 후 소스 코드 (c 프로그램 파일)는 원시 기계어 코드 (코드를 컴파일하는 특정 기계에서 이해할 수 있음)로 직접 변환됩니다. 따라서 c / c ++의 컴파일 된 코드는 다른 OS에서 실행할 수 없습니다.
그러나 Java의 경우 : Java (.java)의 소스 파일은 모든 OS (Physical System)에 설치된 모든 JVM이 이해할 수있는 Byte 코드 (.class 파일)를 제공하는 JAVAC 컴파일러 (JDK에 있음)를 사용하여 컴파일됩니다. .
여기서 우리는 코드를 실행하려는 다른 운영 체제에 대해 서로 다른 JVM (플랫폼에 따라 다름)을 가져야하지만 .class 파일 (컴파일 된 코드 / 중간 코드)은 설치된 모든 JVM이 이해할 수 있기 때문에 동일하게 유지됩니다. 모든 OS에서.
c / c ++ : 소스 코드 만 기계에 독립적입니다. Java에서 : 소스 코드와 컴파일 된 코드는 모두 플랫폼에 독립적입니다.
이것은 자바 플랫폼 (머신)을 독립적으로 만듭니다.
Java는 플랫폼 독립적이 아니며 자체는 플랫폼이며 Java 앱이 실행되는 플랫폼이지만 Java 플랫폼 자체는 플랫폼에 따라 다릅니다.
1:jvm
(예 : 자바 가상 머신)은라는 폴더 (즉, 중간 수준 형식의 프로그램 모음)에 존재하는 다양한 기능을 제공하는 많은 파일을 포함하는 프로그램 모음입니다 packages
. 파일 또는 자바 애플리케이션 만 실행하는 데 도움이되는 부분에 jvm
과부하가 걸리지 않도록 도와 주며, 자바 컴파일러에 의해 컴파일 된 후 동등성 중간 수준 형식을 만들고 바이트 코드 (.class 파일) 표현을 제공하는 데 도움이됩니다. 및에 한정되지 않습니다 . 2 : jvm은 프로세서가 이해할 수 있도록 바이트 코드를 파일로 만들고 frm 바이트 코드를 수신 한 후 모든 함수에 대한 메모리 할당을 확인합니다.o/s
.class
o/s
processor
.exe
3 : jvm은 제어가 실행을 마친 후 ram에서 메모리 할당을 해제합니다.
JVM은 OS에 따라 다릅니다. 모든 OS JVM마다 다릅니다.
".class"는 모든 JVM에서 동일합니다. 따라서 모든 JVM은 ".class"파일 데이터를 이해합니다.
Windows 종속 JVM은 Windows에 Windows 종속 명령을 제공합니다. Linux 종속 JVM은 Linux에 Linux 종속 명령을 제공합니다.
다른 운영 체제에서도 마찬가지입니다. 따라서 java는 모든 운영 체제에서 실행됩니다.
이것이 자바가 OS에 독립적 인 이유입니다.
간단히 말해서 :
Java 프로그래밍 언어 는 플랫폼에 독립적입니다.
JVM 은 플랫폼에 따라 다릅니다.
Java는 JVM에서 실행된다는 점에서 플랫폼 독립적이지 않습니다. 즉, 가장 일반적인 OS 플랫폼 (및 일부 임베디드 어플라이언스)에서 구체적으로 실현되는 단일 추상 시스템에 대한 프로그래밍을 통해 플랫폼 독립성을 확보합니다.
A related idea is the hardware abstraction layer present in many operating systems that allows the same OS to run on disparate hardware.
In you original question, Turbo C is analagous to the javac program, and the JVM is the OS/HAL.
Doesn't independent means that Java code should be able to run on any machine and would need no special software to be installed (JVM in this case has to be present in the machine)?
With Java, you can compile source code on Windows and the compiled code (bytecode to be precise) can be executed (interpreted) on any platform running a JVM. So yes you need a JVM but the JVM can run any compiled code, the compiled code is platform independent.
In other words, you have both portability of source code and portability of compiled code.
Like, for example, we need to have Turbo C Compiler in order to compile C/C++ source code and then execute it.. The machine has to have the C compiler.
The machine doesn't have to have a C compiler, the machine has to use a platform specific binary. With C or C++, the compiled code is specific to each architecture, it is platform independent.
In other words, with C / C++ you have portability of source code (with some discipline) but not portability of compiled code: you need to recompile for each architecture into platform specific binaries.
JVM will be platform dependent.
But whatever it will generate that will be platform independent. [which we called as bytecode or simply you can say...the class file]. for that why Java is called Platform independent.
you can run the same class file on Mac as well on Windows but it will require JRE.
bytecode is not plateform independent, but its JVM that makes bytecode independent. Bytecode is not the matchine code. bytecodes are compact numeric codes, constants, and references (normally numeric addresses) which encode the result of parsing and semantic analysis of things like type, scope, and nesting depths of program objects. They therefore allow much better performance than direct interpretation of source code. bytecode needs to be interpreted before execution which is always done by JVM interpreter.
Just a side note to the discussion about JVM and JIT Compilation. This is the same principle as with C# and the CLR and to some extent in Python, and when somebody says that the code runs "directly on hardware" that is actually true in that instructions that is already compiled will be able to take advantage of optimization on the machine/cpu it's being run on. So even if the initial compilation of a module is rather slow, the next time this module is run, the code being executed runs at native speed and thus runs directly on hardware so to say.
Java is platform independent in aspect of java developer,but this is not the case for the end-user, who need to have platform dependent JVM to run java code. Basically, when java code is compiled, a bytecode is generated which is typically platform independent. Thus, the developer has to have write a single code for entire platform series. But, this benefit comes with a headache for end-user who need to install JVM in order to run this compiled code. This JVM is differnt for every platform. Thus, dependency comes into effect only for end-user.
Javac – compiler that converts source code to byte code. JVM- interpreter that converts byte code to machine language code.
As we know java is both compile**r & **interpreter based language. Once the java code also known as source code is compiled, it gets converted to native code known as BYTE CODE which is portable & can be easily executed on all operating systems. Byte code generated is basically represented in hexa decimal format. This format is same on every platform be it Solaris work station or Macintosh, windows or Linux. After compilation, the interpreter reads the generated byte code & translates it according to the host machine. . Byte code is interpreted by Java Virtual Machine which is available with all the operating systems we install. so to port Java programs to a new platform all that is required is to port the interpreter and some of the library routines.
Hope it helps!!!
When we compile C source data, it generate native code which can be understood by current operating system. When we move this source code to the other operating system, it can't be understood by operating system because of native code that means representation is change from O.S to O.S. So C or C++ are platform dependent .
Now in case of java, after compilation we get byte code instead of native code. When we will run the byte code, it is converted into native code with the help of JVM and then it will be executed.
So Java is platform independent and C or C++ is not platform independent.
well good question but when the source code is changed into intermediate native byte code by a compiler in which it converts the program into the byte code by giving the errors after the whole checking at once (if found) and then the program needs a interpreter which would check the program line by line and directly change it into machine code or object code and each operating system by default cannot have an java interpreter because of some security reasons so you need to have jvm at any cost to run it in that different O.S platform independence as you said here means that the program can be run in any os like unix, mac, linux, windows, etc but this does not mean that each and every os will be able to run the codes without a jvm which saysspecification, implementation, and instance , if i advance then by changing the configuration of your pc so that you can have a class loader that can open even the byte code then also you can execute java byte code, applets, etc. -by nimish :) best of luck
{App1(Java code)------>App1byteCode}........{(JVM+MacOS) help work with App1,App2,App3}
{App2(Java Code)----->App2byteCode}........{(JVM+LinuxOS) help work with App1,App2,App3}
{App3(Java Code)----->App3byteCode}........{(JVM+WindowsOS) help work with App1,App2,App3}
How this is happening ?
Ans: JVM have capability to read ByteCode
and Response In Accordance with the underlying OS As the JVM is in Sync with OS.
So we find, we need JVM with Sync with Platform.
But the main thing is that the programmer dont have to know specific knowledge of the Platform and program his application keeping one specific platform in mind.
This Flexibility of write Program in Java --- compile to ByteCode
and run on any Machine (Yes need to have Platform DEPENDENT JVM to execute it) makes Java Platform Independent.
Edit: Not quite. See comments below.
Java doesn't directly run on anything. It needs to be converted to bytecode by a JVM.
Because JVMs exist for all major platforms, this makes Java platform-independent THROUGH the JVM.
'Program Tip' 카테고리의 다른 글
MVC 및 데이터 주석을 사용하여 클라이언트 측에 0보다 큰 유효성 검사기를 추가하는 가장 좋은 방법은 무엇입니까? (0) | 2020.10.15 |
---|---|
둘 이상의 iPhone 응용 프로그램간에 데이터 공유 (0) | 2020.10.15 |
Enhanced for 문은 배열에 대해 어떻게 작동하며 배열에 대한 반복기를 가져 오는 방법은 무엇입니까? (0) | 2020.10.15 |
토글 버튼 Android의 켜기 / 끄기 텍스트 변경 (0) | 2020.10.15 |
grunt를 설치하는 방법 및 스크립트를 작성하는 방법 (0) | 2020.10.15 |