Каковы преимущества использования компиляции Виртуальной машины (например, JVM) законченный исходно скомпилировал языки?
Я услышал, что преимущество Java состоит в том, что люди могут написать код, скомпилируйте его для JVM и выполните его куда угодно. Каждому человеку просто нужно приложение JVM для их платформы.
Конечно, это выглядит подобным текущей ситуации, где у всех есть компилятор, специфичный для их платформы. Таким образом, преимущество не объяснено этим. Но я думаю, что вижу объяснение.. проблема должна быть то, что в ситуации Java, Вы не можете или не были предназначены для доступа к реальной машине непосредственно в особенном методе ОС.
Я предполагаю, что это означало бы, что на других языках, сам код должен быть исправлен, в зависимости от какого компьютера это работает.
Кто-либо может обеспечить короткие примеры этого как Привет Мировая программа, которая демонстрирует это? Несомненно это было бы в не-Java, например, C
Так как это не что-то, что это было бы - обычно происходить в Привет Мировой программе, или большинство я видел начиная с книг, которые я использовал на Java, они были, к сожалению, "как программировать" книги стиля, и весь материал в них не продемонстрировал это (возможно, потому что они не могли или не хотели использовать Java для демонстрации этого!). Хотя они возвестили о нем как о большом преимуществе. Я хотел бы видеть примеры его.
8 ответов
Я собрал некоторые ответы...
Хотя я не проверял их... Я вижу хорошие примеры, которые имеют смысл для меня, из ответов
Бруно привел пример на C
#include (Строка для конкретной ОС и код придется переписать для другой ОС)
все, что ограничено использованием вызовов в stdio.h и некоторых других (переносимы)
Гэри рассказал о случае с int. Что в Си "int является 32-битным на 32-битной коробке. 64-битный на 64-битной коробке", "переносимый способ - использовать int32_t" и замечание по поводу языка Си и ассемблера... Я поспрашивал и нашел, что если вы превышаете лимит, он возвращается к 0. Так что это был бы случай, когда код имеет другой эффект на другой системе и компилируется, но, возможно, работает не так, как задумано, и его приходится переписывать.
Торбьорн дал ссылку на примеры языка ассемблера на разных CPU. Win32 ASM для 32-битных CPU и Win64 для 64-битных. У него есть пример hello world в каждом, и он говорит, что их нелегко конвертировать, поскольку "В Win32 все параметры передаются через стек, а в Win64 они передаются через регистры." Он сказал, что там используются разные инструкции... Я думаю, что, возможно, это нечто большее, в том смысле, что если это другой язык ассемблера... а язык ассемблера - это очевидный случай непереносимости. Поэтому я не упомянул его в вопросе, но полезно посмотреть примеры по этой ссылке. И это хорошее знание, которое нужно иметь. Приятно видеть некоторые современные языки ассемблера, а не непонятные машины...
... где у каждого есть компилятор, специфичный для его платформы. Так что преимущество объясняется не этим.
Перенос кода, написанного, например, на C или C++, почти всегда намного сложнее, чем простая перекомпиляция кода. Это, конечно, не то, что может легко сделать обычный пользователь компьютера, не являющийся разработчиком. Код, написанный на компилируемых языках, очень часто пишется под API конкретной операционной системы (например, API Win32), поэтому его нельзя легко скомпилировать под другие операционные системы.
Java байткод работает на любой платформе, где есть среда выполнения Java. Код не нужно перекомпилировать. Конечно, на Java можно писать код, специфичный для конкретной операционной системы, но стандартная библиотека Java и множество бесплатных библиотек, доступных в Интернете, обеспечивают очень богатую кроссплатформенную среду.
Помимо переносимости, работа на виртуальной машине имеет и другие преимущества. Java использует JIT-компилятор для компиляции байткода Java в родной машинный код во время выполнения. JIT-компилятор может выполнять сложные оптимизации для конкретного процессора, на котором выполняется программа, и может использовать информацию профилирования, которая была бы недоступна компилятору, работающему на опережение - в принципе, JIT-компилятор может производить более оптимальный код, чем "обычный" компилятор.
Помимо Java VM, существуют и другие виртуальные машины. Например, Microsoft .NET содержит CLR (Common Language Runtime), а также LLVM, которая имеет фронт-энды для многих различных языков, включая C и C++ (и которая должна принести преимущества JIT-компиляции также в C и C++).
Помимо преимуществ JVM, которые позволяют выполнять код независимо от архитектуры ЦП с разумной производительностью благодаря JIT-компилятору, одним из фундаментальных преимуществ Java является то, что это не просто программирование. язык, но среда выполнения с API, общим для всех базовых платформ, на которых он может работать (иногда есть некоторые различия, но они, как правило, являются ошибками).
gcc (кросс-компилятор GNU), например, позволит вам компилировать код C для более или менее любой платформы.В принципе это нормально для всего, что ограничивается использованием вызовов в stdio.h и некоторых других. Однако вы столкнетесь с проблемами довольно быстро, как только попытаетесь использовать что-то более специфичное для ОС, что, как правило, появляется довольно быстро: графический интерфейс, некоторый ввод-вывод, потоки, процессы, сеть.
Как только вы получите #include или аналогичный в вашем коде C, вам придется переписать части кода, чтобы перенести его на платформу Linux / OSX, некоторые этой работы может быть неочевидным или прямо невозможным.
Преимущество Java заключается не только в ее виртуальной машине и способности читать и запускать один и тот же байт-код на любой платформе, но и в наличии довольно большой библиотеки как части JRE (например, J2SE) и общей многопоточная и сетевая модель.
Основным преимуществом для меня является переносимость библиотеки. Библиотеки могут иметь зависимости версий между собой, но в остальном JAR просто работает.
Там есть так называемый ад загрузчика классов, но это не так часто.
Для большинства других языков вам необходимо либо найти правильный двоичный файл библиотеки, либо загрузить исходные коды для ее установки.
Предположим, вы говорите о проблемах с портированием. Действительно, JVM - это то, о чем говорится в популярной литературе, что Java устраняет необходимость в переносе кода - это оттенок более тонкий.
Вам не нужно смотреть слишком далеко. Небольшая индустрия разработчиков переноса кода Windows на UNIX [и наоборот] существует именно по этой причине. Хотите примеры? Как насчет таких вещей, как ближние, дальние указатели в C? Или использовать _declspec(dllexport) для создания библиотеки DLL для Windows, в то время как gcc не будет иметь ничего из этого, и вам нужен параметр -shared?
Одним из самых сложных сценариев было выполнение графического интерфейса на основе C++, в частности, до появления QT. Загрузка графического интерфейса по-прежнему выполняется в .NET, устаревший код находится в MFC, а для Linux / UNIX много устаревшего кода находится в XWindows. Java в таких случаях является находкой - большинство вещей будут работать без повторного изобретения колеса на разных платформах.
В основном переносимость. Тот же двоичный файл Java может работать в Linux / Mac / Windows. Плюс SPARC / PPC / x86 / x86-64 / ARM / MIPS и т. Д. Чтение: тот же двоичный файл. Перекомпиляция не требуется. :)
Я думаю, дело в том, что на java можно делать полезные вещи, которые к тому же переносимы. В C и C++ иногда приходится делать арифметику указателей, беспокоиться о том, какого размера ints (зависит от ОС и процессора) и т.д.. В стандартах есть исправления для решения этой проблемы переносимым способом, но java была разработана с учетом этого с самого начала. Есть еще одно преимущество JVM, как мне кажется. Такие вещи, как jython и scala, могут использовать обширные библиотеки java (и любые другие доступные классы java), как если бы они были частью их собственного языка. В большинстве других языков для взаимодействия с различными языками используется ABI C, что несколько ограничивает возможности ООП. В этом смысле java - это новый C. Кроме того, jvm обеспечивает сборку мусора, рефлексию и тому подобные приятные вещи.
Конечно, это похоже на текущую ситуацию, когда каждый имеет компилятор, специфичный для их платформы.
Нужно понимать, что даже если есть компилятор, специфичный для каждой платформы, языки немного отличаются (если только это не точно такой же компилятор, что редкость для других компиляторов, кроме gcc), и что платформы, которые видят программы, сильно отличаются. "О, у нас тут 64-битные целые числа, и вам нужно использовать X11 для работы с графикой и т.д. и т.п.". Вам нужно обрабатывать эти вещи в коде, и тот факт, что существует довольно большой проект GNU, предназначенный только для обработки конфигурации, указывающей эти различия программам (automake), должен показать, что это не тривиальный вопрос.
Платформа, предоставляемая JVM, гораздо более жестко задана, и ваши программы ведут себя одинаково на всех из них. Целые числа переполняются? О, это означает, что нужно сделать вот это, а это проигнорировать. И т.д. Это настолько хорошо сделано, что ожидается, что вещи работают одинаково на всех JVM, и что сбои не связаны с различиями в платформе между машинами разработки и развертывания. Вы всегда сначала ищете какую-то внешнюю причину и только в самых редких случаях находите ошибку в JVM. Очень хорошо спроектированная работа.