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

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

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

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

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

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

Ответ 1

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

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

Бруно представил пример в C

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

Ответ 4

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

gcc (GNU Cross Compiler), например, позволит вам скомпилировать C-код для более или менее любой платформы. Это прекрасно в принципе для всего, что ограничено использованием вызовов в stdio.h и нескольких других. Тем не менее, вы столкнетесь с неприятностями довольно быстро, как только попытаетесь использовать что-то более специфичное для ОС, которое имеет тенденцию появляться довольно быстро: графический интерфейс, некоторые операции ввода-вывода, потоки, процессы, сетевое взаимодействие.

Как только вы получите #include <win32.h> или аналогичный код C, вам придется переписать части кода, чтобы перенести его на платформу Linux/OSX, некоторые из этих работ могут быть не очевидны или напрямую возможны.

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

Ответ 5

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

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

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

Ответ 6

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

Существует так называемый адсорбатор класса, но это не так часто встречается.

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

Ответ 7

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

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

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

Ответ 8

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