Является ли язык виртуальной машины Java агностиком?

Ответ 1

В том смысле, что байт-код JVM и java завершен, любой другой язык, дополняющий turing, может быть преобразован и скомпилирован в java-байт-код и запущен на JVM. Это может быть ужасно неэффективно, но не невозможно. Что касается самого строгого определения "агностика", такого понятия не существует. На аппаратном уровне все процессоры имеют определенный набор двоичных инструкций, которые они поддерживают, поэтому в какой-то момент любой язык должен быть преобразован в сборку, совместимую с аппаратным обеспечением, которое он должен выполнять.

EDIT: JVM не был разработан в вакууме, он был разработан в сочетании с языком программирования JAVA, поэтому разумно, что язык Java сильно повлиял на дизайн байт-кода Java и JVM. Итак, в этом смысле вы могли бы сказать, что JVM был разработан с учетом Java. Но также верно и то, что в архитектуре JVM сознательно дезактивировался с языка Java (через формат промежуточного байт-кода), поэтому в проекте есть элементы, которые учитывают возможные альтернативные языки.

Ответ 2

JVM определенно не является языковым агностиком, и некоторые языки не могут быть эффективно реализованы на нем. Например, JVM не предлагает операций с адресацией памяти, поэтому реализация языка более низкого уровня, такого как C, будет ужасно неэффективной. Но его набор примитивов способен поддерживать многие популярные языки с функциями, отличными от Java, учитывая подходящий интеллектуальный компилятор. Языки, которые могут быть выполнены прилично, не обязательно являются просто Java с синтаксическим сахаром; но, конечно, чем больше отличается от Java, тем сложнее реализовать язык

Ответ 3

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

Другие языковые барьеры включают в себя дизайн, который JVM представляет собой машину на основе стека, что означает, что явные адреса являются бессмысленными для JVM на уровне байт-кода. Там нет операций "загрузки" или "хранения"; однако это не останавливает людей, которые хотят внедрять языки, которые обращаются к JVM. Это просто усложняет тем, кто хочет заниматься адресацией.

Чтобы делать адресацию на JVM, вы в основном пишете симулятор; где у вас есть объект, содержащий таблицу поиска "адрес для объекта". Это позволяет выполнять рудиментарную адресацию посредством моделирования на виртуальной машине, которой не хватает адресации. Это не всегда красиво, и качество моделирования обычно распространяется только на те варианты использования, которые разрешал имитируемый язык.

Да, вы теряете немного производительности, делая адрес (объект) в Map (ссылка на объект Java на кучу) на ссылку java heap на физический адрес памяти (внутри JVM). Но это то, что нужно сделать, чтобы поддерживать платформу агностикой. Если у вас прямой доступ к памяти, в конечном итоге вы будете переведены в кодировку для разных аппаратных платформ вместо кодирования для виртуальной машины. Ну, по крайней мере, вы были бы переведены в специфичный для платформы код намного раньше, чем это происходит в наши дни.

Ответ 4

Игнорируя встроенные инструкции ООП, некоторые языки лучше подходят для виртуальной машины на основе регистров (например, попугай) вместо виртуальной машины на основе стека (например, JVM).

Этот документ хорошо освещает проблему: http://db.usenix.org/events/vee05/full_papers/p153-yunhe.pdf