programing

휴대성이란 무엇입니까?자바는 다른 언어보다 어떻게 더 휴대성이 좋습니까?

javamemo 2023. 11. 6. 21:36
반응형

휴대성이란 무엇입니까?자바는 다른 언어보다 어떻게 더 휴대성이 좋습니까?

자바가 어떻게 C, C++, 그리고 C보다 더 휴대성이 좋은지 궁금합니다.NET 및 기타 언어.자바가 인터프리터와 JVM 때문에 휴대성이 있다는 것을 여러 번 읽었지만, JVM은 하드웨어의 구조적인 차이를 감추고 있을 뿐입니다.서로 다른 머신 아키텍처를 위해서는 여전히 서로 다른 JVM이 필요합니다.내가 뭘 놓치고 있는 거지?따라서 가장 일반적인 아키텍처, 예를 들어 CVM에 대해 C에 대한 추상화 계층을 작성하는 경우 CVM이 설치되면 해당 아키텍처에서 모든 C 프로그램이 실행됩니다. 그렇지 않습니까?

이 휴대성은 정확히 무엇입니까?.NET을 휴대용이라고 부를 수 있습니까?

휴대성은 흑백이 아닙니다. 예, 아니요.휴대성이란 프로그램을 얼마나 쉽게 받아 자신이 아끼는 모든 플랫폼에서 실행할 수 있느냐는 것입니다.

이것에 영향을 미치는 몇 가지가 있습니다.하나는 언어 그 자체입니다.자바 언어 사양은 일반적으로 "구현"에 훨씬 덜 맡겨집니다.예를 들어, "i = i++"는 C 및 C++에서는 정의되지 않지만 Java에서는 정의된 의미를 갖습니다.좀 더 실질적으로 말하자면, 자바에서는 "int"와 같은 타입들이 특정한 크기를 가지고 있는 반면, C와 C++에서는 플랫폼과 컴파일러에 따라 크기가 다릅니다.이러한 차이점만으로 C와 C++로 휴대용 코드를 작성하는 것을 막을 수는 없지만 훨씬 더 부지런해질 필요가 있습니다.

또 하나는 도서관입니다.자바에는 C와 C++가 없는 표준 라이브러리들이 많이 있습니다.예를 들어, 스레드화, 네트워킹 및 GUI 라이브러리가 있습니다.이러한 종류의 라이브러리는 C 및 C++용으로 존재하지만 표준의 일부가 아니며 사용 가능한 해당 라이브러리는 플랫폼마다 매우 다양합니다.

마지막으로, 실행 파일을 다른 플랫폼에 떨어뜨려서 작동시킬 수 있는지에 대한 모든 문제가 있습니다.대상 플랫폼에 JVM이 있다고 가정할 때, 이는 일반적으로 Java와 함께 작동합니다. (그리고 사람들이 관심을 가지는 많은/대부분의 플랫폼을 위한 JVM이 있습니다.)이것은 일반적으로 C와 C++에서는 사실이 아닙니다.최소한 재컴파일이 필요한 경우가 일반적이며, 앞의 두 가지 사항을 이미 처리했다고 가정합니다.

예, 만약 "CVM"이 여러 플랫폼을 위해 존재한다면, C와 C++를 좀 더 휴대성 있게 만들 것입니다.C 코드를 휴대용 방식으로 작성하거나(예: 표준에서 말하는 int의 크기 외에는 아무것도 가정하지 않음), CVM에 작성하거나(모든 대상 플랫폼에서 이와 같은 모든 종류의 것에 대해 균일한 결정을 내렸다고 가정할 경우) CVM에 작성해야 합니다.또한 비표준 라이브러리(네트워킹, 쓰레딩 또는 GUI 없음)의 사용을 포기하거나 CVM별 라이브러리에 쓰기도 해야 합니다.그렇다면 C와 C++를 휴대성 있게 만드는 것이 아니라 휴대성이 뛰어난 특별한 CVM-C/C++를 말하는 것입니다.

다시 한 번 말하지만, 휴대성은 흑백이 아닙니다.자바를 사용하더라도 여전히 호환되지 않을 수 있습니다.GUI 라이브러리(특히 AWT)는 일관성 없는 동작으로 악명이 높았으며, 스레드와 관련된 모든 것은 엉성하게 되면 다르게 동작할 수 있습니다.그러나 일반적으로 C 또는 C++로 작성된 프로그램으로 실행하는 것보다 한 플랫폼에서 작성된 사소한 자바 프로그램을 가져다가 다른 플랫폼에서 실행하는 것이 훨씬 쉽습니다.

다른 사람들이 이미 말했듯이, 휴대성은 다소 모호한 개념입니다.어떤 관점에서 보면, C는 사실 자바보다 더 휴대성이 뛰어납니다.C는 기본 하드웨어에 대한 가정을 거의 하지 않습니다.한 바이트에 8비트가 있다고 가정하거나, 2의 보어를 사용하여 음수를 표현해야 한다고 가정하지도 않습니다.이론적으로는 폰 노이만 기반의 머신과 컴파일러만 있다면 C를 사용해도 좋습니다.

사실, C로 작성된 "Hello world" 프로그램은 자바로 작성된 "Hello world" 프로그램보다 더 많은 플랫폼에서 작동할 것입니다.PDP-11과 아이폰에서도 동일한 "헬로 월드" 프로그램을 사용할 수 있을 것입니다.

그러나 현실은 대부분의 실제 프로그램이 출력된 "Hello world"보다 훨씬 더 많은 것을 한다는 것입니다.자바는 실제 C 프로그램을 실제 자바 프로그램보다 다른 플랫폼으로 포팅하는 데 훨씬 많은 노력이 들기 때문에 C보다 휴대성이 뛰어나기로 정평이 나 있습니다.

이것은 C 언어가 정말로 ANSI-C이기 때문인데, 이것은 매우 범용적이고, 맨 뼈를 가진 언어입니다.네트워크 프로그래밍, 쓰레드 또는 GUI 개발에 대한 지원이 없습니다.따라서 이러한 것들 중 하나를 포함하는 프로그램을 작성하는 즉시 Win32나 POSIX 같은 휴대성이 떨어지는 확장 프로그램을 C에 다시 의존해야 합니다.

그러나 Java의 경우 네트워크 프로그래밍, 쓰레드 및 GUI 도구가 언어에 따라 정의되고 각 VM 구현에 내장됩니다.

그렇기는 하지만 요즘 많은 프로그래머들이 휴대성과 관련하여 현대 C/C++가 이룬 발전을 과소평가하고 있다고 생각합니다.POSIX는 크로스 플랫폼 스레딩을 제공하는 데 큰 도움을 주며, C++와 관련하여 Boost는 기본적으로 Java의 어떤 것과 마찬가지로 휴대성이 뛰어난 네트워킹 및 스레딩 라이브러리를 제공합니다.이러한 라이브러리에는 플랫폼별 특이점이 있지만 Java도 마찬가지입니다.

기본적으로 자바는 바이트 코드를 예측 가능한 방식으로 해석하는 VM 구현을 가진 각 플랫폼에 의존하며 C/C++는 전처리기를 사용하여 플랫폼 고유의 코드를 통합하는 라이브러리에 의존합니다.#ifdefs). 두 전략 모두 교차 플랫폼 쓰레드, 네트워킹 및 GUI 개발이 가능합니다.단지 자바가 휴대성에 있어서 C/C++보다 더 빠른 발전을 이뤘을 뿐입니다.자바 언어 사양은 첫 날부터 쓰레드, 네트워킹 및 GUI 개발이 거의 이루어진 반면, 부스트 네트워킹 라이브러리는 2005년경에 출시되었으며, C++11에서는 2011년이 되어서야 표준 휴대용 쓰레드가 C++에 포함되었습니다.

Java 프로그램을 작성하면 Windows, Linux, MacOS 등 JVM이 작성된 모든 플랫폼에서 실행됩니다.

C++ 프로그램을 작성할 경우 각 플랫폼별로 구체적으로 컴파일해야 합니다.

지금은 자바의 모토인 "한번 쓰고, 어디든 달려라"가 신화라고 합니다.많은 기본 리소스와의 상호 작용이 필요한 데스크톱 애플리케이션의 경우에는 그렇지 않지만 각 JavaEE 애플리케이션은 모든 플랫폼에서 실행될 수 있습니다.현재 저는 윈도우 작업을 하고 있고 다른 동료들은 리눅스 작업을 하고 있습니다. 아무 문제없이 말이죠.

(휴대성과 관련된 또 다른 것은 Java EE(엔터프라이즈 에디션)입니다.JavaEE 기술로 작성된 애플리케이션은 JavaEE 인증을 받은 애플리케이션 서버에서 실행된다고 합니다.그러나 이는 적어도 JavaEE6까지는 사실이 아닙니다. (여기 참조)

휴대성은 프로그램이 원래의 환경이 아닌 다른 환경에서 실행되도록 하기 위한 노력의 양을 나타내는 척도입니다.

이제 Linux의 JVM이 Windows 환경과 다른 환경인지에 대해 논의할 수 있습니다(그렇다고 주장합니다). 하지만 많은 경우 몇 가지 문제가 발생하지 않도록 주의를 기울인다면 아무런 노력이 필요하지 않다는 사실이 여전히 남아 있습니다.

당신이 말하는 CVM은 POSIX 라이브러리와 런타임 라이브러리가 제공하려는 것이지만, 장애물을 넘어서기에는 큰 구현 차이가 있습니다.확실히 마이크로소프트와 애플의 경우, 개발자들이 경쟁 플랫폼에서 제품을 꺼내는 것을 막기 위해 의도적으로 그렇게 했을 것입니다.

.net front에서, 만약 당신이 mono가 제공하는 것을 고수할 수 있다면, 오픈 소스.순 구현 시 Java와 거의 동일한 종류의 휴대성을 누릴 수 있지만 Windows 버전에 비해 mono가 크게 뒤떨어지므로 이는 일반적인 선택 사항이 아닙니다.이것이 서버 기반 개발에 얼마나 인기가 있는지는 알 수 없지만 문제가 덜 될 것으로 예상됩니다.

자바는 개발자의 관점에서 휴대용입니다: 자바로 작성된 코드는 재컴파일할 필요 없이 어떤 환경에서도 실행될 수 있습니다.C는 많은 경우 특정 OS에 연결되어 있을 뿐만 아니라 컴파일이 완료되면 항상 특정 하드웨어 아키텍처에 연결되어 있기 때문에 휴대용이 아닙니다.C++도 마찬가지입니다.Net은 C/C++보다 휴대성이 뛰어납니다. 가상 머신에 의존하기 때문에 컴파일 시 특정 하드웨어 아키텍처에 연결되지 않지만 Windows 머신(공식적으로)에만 국한되기 때문입니다.

맞습니다. JVM은 플랫폼에 따라 다릅니다.(반드시 그래야 합니다!) 하지만 자바가 휴대용이라고 하면 개발자 입장에서 JVM을 말하는 것이고 표준 자바 개발자들은 JVM을 작성하지 않고 사용합니다. :-).

@Raze2Dust를 편집하여 질문을 해결합니다.네, 할 수 있습니다.실제로 바이트코드가 아닌 머신코드를 생성하는 컴파일러를 작성하면 자바 플랫폼에 특화된 것을 만들 수 있습니다.그런데 다른 분들이 말씀하시는 것처럼 왜 그러시는 거죠?JVM이 작동하는 것과 같은 방식으로 컴파일된 코드를 연산에 매핑하는 인터프리터를 만들어야 합니다.그래서 길고 짧다는 것은, 분명히, 당신은 할 수 있지만, 왜 그렇게 하겠습니까?

Java는 세 가지 유형의 휴대성을 제공합니다.

소스 코드 이식성:주어진 Java 프로그램은 기본 CPU, 운영 체제 또는 Java 컴파일러에 관계없이 동일한 결과를 생성해야 합니다.

CPU 아키텍처 이식성: 현재 Java 컴파일러는 아직 존재하지 않는 CPU의 객체 코드(바이트 코드)를 생성합니다.Java 프로그램을 실행할 실제 CPU, Java 인터프리터 또는 가상 시스템에 대해 J-code를 "실행"합니다.존재하지 않는 CPU를 사용하면 Java 인터프리터가 존재하는 CPU에서 동일한 개체 코드를 실행할 수 있습니다.

OS/GUI 휴대성: 자바는 상상의 OS와 상상의 GUI와 대화하는 일련의 라이브러리 기능(awt, util, lang 등 자바가 제공하는 라이브러리에 포함)을 제공함으로써 이 문제를 해결합니다.JVM이 가상 CPU를 제공하는 것처럼 자바 라이브러리는 가상 OS/GUI를 제공합니다. 모든 자바 구현은 이 가상 OS/GUI를 구현하는 라이브러리를 제공합니다. 이러한 라이브러리를 사용하여 필요한 OS 및 GUI 기능 포트를 상당히 쉽게 제공하는 자바 프로그램입니다.

링크 참조

'CVM'을 쓸 수 있냐고 물으시잖아요. 그렇지 않아요."자바"는 프로그래밍 언어와 가상 머신을 모두 포함하여 많은 것을 의미하는 Sun의 큰 용어입니다."C"는 단지 프로그래밍 언어일 뿐입니다. 결과적인 이진법의 형식을 결정하는 것은 컴파일러와 OS와 CPU에 달려 있습니다.

C는 런타임을 지정하지 않기 때문에 휴대용이라고 말하기도 합니다.당신의 컴파일러를 쓴 사람들은 그 플랫폼에 맞는 것들을 고를 수 있었습니다.단점은 C가 충분히 낮은 수준이고 플랫폼이 충분히 다르다는 것입니다. C 프로그램이 한 시스템에서 잘 작동하고 다른 시스템에서는 전혀 작동하지 않는 것이 일반적입니다.

C 언어를 특정 ABI와 결합하는 경우 JVM과 유사하게 해당 언어에 대한 VM을 정의할 수 있습니다.다음과 같은 몇 가지 사항이 이미 있습니다.

  • "Intel Binary Compatibility Specification"(인텔 바이너리 호환성 사양)은 이러한 ABI의 한 예입니다(오늘날 거의 아무도 사용하지 않음).
  • "Microsoft Windows"는 이러한 ABI(거대하고 제대로 지정되지 않은 ABI)일 수도 있습니다. Wine은 이를 위해 작성된 프로그램을 실행하는 VM 중 하나입니다.
  • "MS-DOS"(dosemu가 하나의 VM인 경우)
  • 리눅스(Linux)는 오늘날 가장 인기있는 프로그램 중 하나로, 리눅스 자체, NetBSD, FreeBSD로 프로그램을 실행할 수 있습니다.
  • HP의 Dynamo가 JIT와 같은 VM이었던 "PA-RISC"

이 모든 CVM은 사실 실제 머신입니다. AFAIK를 비롯한 그 누구도 순수하게 가상화된 CVM을 만들어 본 적이 없습니다.C는 하드웨어에서 효율적으로 실행되도록 설계되었으므로 한 시스템에서 정상적으로 실행할 수 있습니다.HP가 보여주었듯이 동일한 플랫폼에서도 코드를 보다 효율적으로 실행할 수 있는 JIT를 만들 수 있습니다.

다양한 아키텍처를 위해 JVM이 필요하지만, 물론 Java 프로그램은 해당 JVM에서 실행됩니다.아키텍처에 대한 JVM이 있으면 해당 아키텍처에 대해 Java 프로그램을 사용할 수 있습니다.

그래서 자바 프로그램을 작성하여 자바 바이트 코드(아키텍처에 구애받지 않음)로 컴파일할 수 있으며, 이는 모든 아키텍처의 모든 JVM에서 실행할 수 있음을 의미합니다.JVM은 기본 아키텍처를 추상화하고 프로그램은 가상 머신에서 실행됩니다.

아이디어는 자바 언어가 휴대용(또는 더 정확하게는 컴파일된 바이트 코드가 휴대용)이라는 것입니다.각 VM에 특정 하드웨어 프로파일에 대한 특정 구현이 필요한 것이 맞습니다.하지만 그 노력이 이루어지면 모든 자바 바이트코드가 해당 플랫폼에서 실행됩니다.자바/바이트 코드를 한 번 작성하면 모든 JVM에서 실행됩니다.

.NET은 상당히 유사하지만 원칙에 훨씬 더 낮은 강조점을 가지고 있습니다.CLR은 JVM과 유사하며 자체 바이트 코드를 가지고 있습니다.*nix에 모노가 존재하지만 "공식"이 아닌 것이 맞습니다.

소프트웨어 이식성(Portability)은 여러 환경(OS)에서 동일한 소프트웨어(코드)를 재사용할 수 있는 기능입니다.Java JVM은 Windows, Linux, Mac OS 등을 위해 설계된 운영 체제에서 실행할 수 있는 JVM입니다.

.NET에서는 소프트웨어를 다른 플랫폼으로 포팅할 수 있습니다.위키피디아에서:

의 디자인.NET Framework를 사용하면 이론적으로 플랫폼에 구애받지 않으므로 플랫폼 간 호환이 가능합니다.즉, 프레임워크를 사용하기 위해 작성된 프로그램은 프레임워크가 구현되는 모든 유형의 시스템에서 변경 없이 실행되어야 합니다.

그리고 마이크로소프트는 단 한 번도 구현하지 않았기 때문입니다.NET 프레임워크를 Windows 밖에서 사용할 수 있습니다.NET은 플랫폼에 구애받지 않으며 Mono는 실행을 가능하게 했습니다.리눅스에서 실행할 NET 응용 프로그램 및 컴파일 코드.

C+++Pascal 등의 언어의 경우 각 OS로 이동하여 해당 플랫폼에서 실행하려면 해당 플랫폼에서 구축해야 합니다.Windows의 EXE 파일이 다음 파일과 같지 않습니다..so둘 다 커널과 대화하기 위해 서로 다른 라이브러리를 사용하고 각각의 OS가 고유한 커널을 가지고 있기 때문에 리눅스 (기계 코드)에서.

WEARED - 모든 곳에 한 번만 실행 시 쓰기

실제로는 JVM이 있는 플랫폼에만 제한이 있지만, 구축하고자 하는 대부분의 플랫폼에는 제한이 있습니다.이것은 통역 언어와 컴파일 언어의 거의 절반으로 둘 다의 이점을 얻습니다.

언급URL : https://stackoverflow.com/questions/3925947/what-is-portability-how-is-java-more-portable-than-other-languages

반응형