Каковы преимущества использования компиляции виртуальной машины (например, JVM) по сравнению с компилируемыми языками?

Question

Я слышал, что преимущество java заключается в том, что люди могут писать код, компилировать его для JVM и запускать его где угодно. Каждому человеку просто нужно приложение JVM для своей платформы.

Конечно, это похоже на текущую ситуацию, когда у каждого есть свой компилятор для своей платформы. Таким образом, преимущество не объясняется этим. Но я думаю, что вижу объяснение ... проблема должна заключаться в том, что в ситуации с Java вы не можете или не должны были напрямую обращаться к реальной машине специфическим для ОС способом.

Полагаю, это означало бы, что в других языках сам код должен быть изменен в зависимости от того, на каком компьютере он работает.

Кто-нибудь может привести короткие примеры этого, например, программу Hello World, которая демонстрирует это? Без сомнения, это было бы не в Java, например. C

Поскольку это не то, что обычно происходит в программе Hello World, или большинство из тех, что я видел со времен книг, которые я использовал на java, к сожалению, они были книгами в стиле «как программировать», и все в них не продемонстрировал это (возможно, потому что они не могли или не хотели использовать Java для демонстрации этого!). Хотя они трубили как большое преимущество. Я хотел бы видеть примеры этого.

Answer 1

... где у каждого есть свой компилятор для своей платформы.Таким образом, преимущество не объясняется этим.

Портирование кода, написанного, например, на C или C ++, почти всегда намного более сложное, чем простая перекомпиляция кода.Это, конечно, не то, что обычный пользователь компьютера, не являющийся разработчиком, может легко это сделать.Код, написанный на скомпилированных языках, очень часто пишется на основе API конкретной операционной системы (например, Win32 API), и поэтому его нелегко скомпилировать в других операционных системах.

Байт-код Java работает на любой платформе, гдедоступна среда выполнения Java.Код не нужно перекомпилировать.Конечно, вы можете писать специфичный для операционной системы код на Java, но стандартная библиотека Java и множество бесплатных библиотек, доступных в Интернете, предоставляют очень богатую кроссплатформенную среду.

Помимо переносимости, работа на виртуальной машинеимеет другие преимущества.Java использует JIT-компилятор для компиляции байт-кода Java в машинный код во время выполнения.JIT-компилятор может выполнять сложные оптимизации для конкретного процессора, на котором выполняется программа, и он может использовать информацию о профилировании, которая не будет доступна для заблаговременного компилятора - поэтому в принципе JIT-компилятор может создавать более оптимальный кодкроме «обычного» компилятора.

Помимо Java VM, существуют и другие виртуальные машины.Например, Microsoft .NET содержит CLR (Common Language Runtime), а также есть LLVM , который имеет интерфейсы для многих различных языков, включая C и C ++ (и который долженпринести преимущества JIT-компиляции также в C и C ++).

Answer 2

Конечно, это похоже на текущая ситуация, когда у всех есть специфичный для их компилятор платформы.

Вам нужно понять, что даже если для каждой платформы есть свой компилятор, языки немного отличаются (если это не тот же самый компилятор, что редко встречается для других, кроме компилятора gcc), и Платформа, которую видят программы, сильно отличается. «О, у нас здесь есть 64-битные целые числа, и вам нужно использовать X11 для графики и т. Д. И т. Д.». Вам нужно обрабатывать эти вещи в коде, и тот факт, что существует довольно большой проект GNU только для обработки конфигурации определения этих различий для программ (automake), должен указывать, что это не тривиальный вопрос.

Платформа, предоставляемая JVM, гораздо жестче определена, и ваши программы ведут себя одинаково на всех них. Целые числа переполнены? О, это значит делать это и игнорировать это. и т.д. Это так хорошо сделано, что ожидается , что все работает одинаково на всех JVM, и что сбои не связаны с различиями в платформах между машинами разработки и развертывания. Вы всегда смотрите сначала по какой-то внешней причине, и только в самых редких случаях вы обнаруживаете ошибку в JVM. Очень хорошо спроектированная часть работы.

Answer 3

Помимо преимуществ JVM, которые позволят вам выполнять код независимо от архитектуры ЦП с разумной производительностью благодаря JIT-компилятору, одним фундаментальным преимуществом Java является то, что это не просто язык программирования, а среда выполнения сAPI, общий для всех базовых платформ, на которых он может работать (иногда есть некоторые отличия, но они, как правило, являются ошибками).

gcc (например, GNU Cross Compiler) позволит вам скомпилироватьC-код для более или менее любой платформы.Это в принципе хорошо для всего, что ограничено использованием вызовов в stdio.h и некоторых других.Тем не менее, вы столкнетесь с проблемами довольно быстро, как только вы попытаетесь использовать что-то более специфичное для ОС, которое обычно появляется довольно быстро: GUI, некоторые операции ввода-вывода, многопоточность, процессы, работа в сети.Как только вы получите код #include <win32.h> или аналогичный в своем коде C, вам придется переписать части кода, чтобы перенести его на платформу Linux / OSX, некоторые из этих работ могут быть неочевидными или прямо невозможными.

Преимущество Java заключается не только в его виртуальной машине и возможности чтения и запуска одного и того же байт-кода на любой платформе, но также в наличии довольно большой библиотеки в составе JRE (например, J2SE) иобщая модель потоков и сетей.

Answer 4

Я думаю, дело в том, что на Java вы можете делать полезные вещи, которые также переносимы. В C и C ++ вам иногда приходится выполнять арифметику с указателями и беспокоиться о том, что такое размеры (в зависимости от ОС и ЦП) и т.п. В стандартах есть исправления для того, чтобы иметь дело с этим портативным способом, но java был разработан с учетом этого с самого начала. Я думаю, есть еще одно преимущество JVM. Такие вещи, как jython и scala, могут использовать обширные библиотеки Java (и любой другой доступный класс Java), как если бы они были частью их собственного языка. В большинстве других языков способ взаимодействия с разными языками заключается в использовании C ABI, что несколько ограничивает мир ООП. В этом смысле java - это новый C. Кроме того, jvm обеспечивает сбор мусора и его отражение, а также такие приятные вещи.

Answer 5

Основным преимуществом для меня является переносимость библиотеки. Библиотеки могут иметь зависимости версий между собой, но, кроме этого, JAR просто работает.

Там - это так называемый ад загрузчика классов, но это не так часто встречается.

В большинстве других языков вам нужно либо найти правильный двоичный файл библиотеки, либо загрузить исходные коды для его установки.

Answer 6

Думаю, вы говорите о проблемах с портированием.В самом деле, JVM - это то, о чем говорится в популярной литературе, что Java устраняет необходимость портирования кода - это более тонкий оттенок.

Вам не нужно заглядывать слишком далеко.По этой конкретной причине существует небольшая индустрия разработчиков программного обеспечения для переноса кода из Windows в UNIX [и наоборот].Хотите примеры?Как насчет таких вещей, как ближние, дальние указатели в C?Или используя __declspec (dllexport) для создания dll для Windows, в то время как у gcc ничего этого нет, а вам нужна опция -shared?

Одним из наиболее сложных сценариев было создание графического интерфейса на C ++, в частности, до появления QT.Загрузка графического интерфейса пользователя по-прежнему выполняется в .NET, устаревший код находится в MFC, а для Linux / UNIX много устаревшего кода - в XWindows.В таких случаях Java является находкой - большинство вещей будет работать без переизобретения колеса на разных платформах.

Answer 7

Я собрал некоторые ответы ..

Пока я их не проверял .. Я вижу хорошие примеры, которые имеют для меня смысл, из ответов

Бруно привел пример в C

#include <win32.h> (Строка и код для конкретной ОС должны быть переписаны для другой ОС) все, что ограничено использованием вызовов в stdio.h и некоторых других (переносимых)

Гэри, говорил о случае с инт. Что в C «int 32-битный на 32-битном блоке. 64-битный на 64-битном блоке» «портативный способ - это использовать int32_t» и пункт о C и языке ассемблера. Я спросил и обнаружил, что если вы превысите предел, он вернется к 0. Таким образом, это будет случай, когда код будет по-разному влиять на другую систему и компилируется, но, возможно, не будет работать как задумано, и это должно быть переписаны.

Торбьерн предоставил ссылку на примеры ассемблера на разных процессорах. Win32 ASM для 32-битных процессоров и Win64 для 64-битных. В каждом из них есть пример hello world, и он говорит, что преобразовать их нелегко, поскольку «в Win32 все параметры передаются через стек, однако в Win64 они передаются через регистры». Он сказал, что он использует разные инструкции .. Я думаю, что, может быть, это нечто большее, в том смысле, что если это другой язык ассемблера и ассемблер является очевидным случаем непереносимости ... поэтому я не упомянул об этом в вопросе, но хорошо видеть примеры по этой ссылке. И это хорошее знание. Приятно видеть некоторые современные языки ассемблера, не затененные машины ..

Answer 8

Портативность в основном. Тот же двоичный файл Java может работать в Linux / Mac / Windows. Плюс SPARC / PPC / x86 / x86-64 / ARM / MIPS и т. Д. Читайте: тот же двоичный файл. Перекомпиляция не требуется. :)