Зачем нам нужны другие языки JVM

StackOverflow https://stackoverflow.com/questions/85058

  •  01-07-2019
  •  | 
  •  

Вопрос

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

В чем преимущество наличия других языков для JVM?

Что требуется (в терминах высокого уровня) для написания языка / компилятора для JVM?

Как вы пишете / компилируете / запускаете код на языке (отличном от Java) в JVM?

Редактировать: Было задано 3 дополнительных вопроса (первоначально комментарии), на которые были даны ответы в принятом ответе.Они перепечатаны здесь для удобства чтения:

Как приложение, написанное, скажем, на JPython, будет взаимодействовать с Java-приложением?

Кроме того, может ли это приложение JPython использовать какие-либо функции / объекты JDK??

Что, если бы это был код Jaskell, не сделал бы тот факт, что это функциональный язык, его несовместимым с JDK?

Это было полезно?

Решение

Чтобы ответить на ваши три вопроса по отдельности:

В чем преимущество наличия других языков для JVM?

Здесь есть два фактора.(1) Зачем использовать для JVM язык, отличный от Java, и (2) почему в JVM работает другой язык, а не другая среда выполнения?

  1. Другие языки могут удовлетворить другие потребности.Например, Java не имеет встроенной поддержки для закрытия, функция, которая часто бывает очень полезной.
  2. Язык, который выполняется в JVM, является байт-кодом, совместимым с любым другим языком, который выполняется в JVM, что означает, что код, написанный на одном языке, может взаимодействовать с библиотекой, написанной на другом языке.

Что требуется (в терминах высокого уровня) для написания языка / компилятора для JVM?

JVM считывает файлы байт-кода (.class), чтобы получить инструкции, которые ей необходимо выполнить.Таким образом, любой язык, который должен быть запущен в JVM, должен быть скомпилирован в байт-код, соответствующий Спецификация Солнца.Этот процесс аналогичен компиляции в машинный код, за исключением того, что вместо компиляции в инструкции, понятные центральному процессору, код компилируется в инструкции, которые интерпретируются JVM.

Как вы пишете / компилируете / запускаете код на языке (отличном от Java) в JVM?

Очень похоже на то, как вы пишете / компилируете / запускаете код на Java.Чтобы промочить ноги, я бы порекомендовал посмотреть на Скала, который безупречно работает в JVM.

Отвечаю на ваши последующие вопросы:

Как приложение, написанное, скажем, на JPython, будет взаимодействовать с Java-приложением?

Это зависит от выбора реализации для устранения языкового разрыва.В вашем примере, Проект Jython имеет простой способ сделать это (смотрите здесь):

from java.net import URL
u = URL('http://jython.org')

Кроме того, может ли это приложение JPython использовать какие-либо функции / объекты JDK?

Да, смотрите выше.

Что, если бы это был код Jaskell, не сделал бы тот факт, что это функциональный язык, его несовместимым с JDK?

Нет.Scala (ссылка выше), например, реализует функциональные возможности, сохраняя при этом совместимость с Java.Например:

object Timer {
  def oncePerSecond(callback: () => unit) {
    while (true) { callback(); Thread sleep 1000 }
  }
  def timeFlies() {
    println("time flies like an arrow...")
  }
  def main(args: Array[String]) {
    oncePerSecond(timeFlies)
  }
}

Другие советы

Вам нужны другие языки в JVM по той же причине, по которой вам вообще нужно несколько языков программирования:Разные языки лучше подходят для решения разных задач ...статическая типизация противдинамическая типизация, строгая по сравнению сленивый ...Декларативный, Императивный, Объектно-ориентированный...и т.д.

В общем, написание "компилятора" для другого языка для запуска в JVM (или в .Net CLR) - это, по сути, вопрос компиляции этого языка в байт-код java (или, в случае .Net, IL) вместо ассемблера / машинного языка.

Тем не менее, многие дополнительные языки, которые пишутся для JVM, являются не компилируемыми, а скорее интерпретируемыми языками сценариев...

Перевернув это с ног на голову, представьте, что вы хотите разработать новый язык и хотите, чтобы он запускался в управляемой среде выполнения с JIT и GC.Тогда подумайте, что вы могли бы:

(a) напишите свою собственную управляемую среду выполнения (VM) и решайте всевозможные технически сложные проблемы, которые, несомненно, приведут ко множеству ошибок, низкой производительности, неправильному распределению потоков и большим затратам на переносимость

или

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

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

Java - довольно подробный язык программирования, который очень быстро устаревает из-за появления всех новых модных языков / фреймворков за последние 5 лет.Чтобы поддерживать весь причудливый синтаксис, который люди хотят использовать в языке, И сохранять обратную совместимость, имеет смысл добавить больше языков в среду выполнения.

Другим преимуществом является то, что он позволяет запускать некоторые веб-фреймворки, написанные на Ruby, ala JRuby (он же Rails) или Grails (по сути, Groovy на Railys) и т.д.на проверенной платформе хостинга, которая, вероятно, уже находится в производстве у многих компаний, вместо того, чтобы использовать далеко не такие проверенные среды хостинга Ruby.

Чтобы скомпилировать другие языки, вы просто преобразуете их в байтовый код Java.

Я бы ответил: “потому что Java - отстой” но опять же, возможно, это слишком очевидно … ;-)

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

Написание языка / компилятора для JVM на самом деле ничем не отличается от написания языка / компилятора для реальной машины.Реальная разница заключается в том, что вам приходится компилироваться в байт-код JVM, а не в исполняемый код машины, но на самом деле это незначительная разница в общей схеме вещей.

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

Разные языки адаптированы к разным задачам.Хотя некоторые проблемные области идеально подходят для языка Java, некоторые гораздо проще выразить на альтернативных языках.Кроме того, для пользователя, привыкшего к Ruby, Python и т.д., возможность генерировать байт-код Java и использовать преимущества классов JDK и JIT-компилятора имеет очевидные преимущества.

Отвечаю только на ваш второй вопрос:

JVM - это просто абстрактная машина и модель выполнения.Таким образом, таргетинг на него с помощью компилятора точно такой же, как и на любую другую машину и модель выполнения, на которую может быть нацелен компилятор, будь то реализованный аппаратно (x86, CELL и т.д.) Или программно (parrot, .NET).JVM довольно проста, поэтому на самом деле является довольно легкой мишенью для компиляторов.Кроме того, реализации, как правило, имеют довольно хорошие JIT-компиляторы (для работы с паршивым кодом, который создает javac), так что вы можете получить хорошую производительность, не беспокоясь о множестве оптимизаций.

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

То, что может делать JVM, определяется байт-кодом JVM (который вы найдете в файлах .class), а не исходным языком.Таким образом, изменение языка исходного кода высокого уровня не окажет существенного влияния на доступную функциональность.

Что касается того, что требуется для написания компилятора для JVM, все, что вам действительно нужно сделать, это сгенерировать правильный байт-код / файлы .class.То, как вы пишете / компилируете код с помощью альтернативного компилятора, зависит от соответствующего компилятора, но как только компилятор выводит файлы .class, их запуск ничем не отличается от запуска файлов .class, сгенерированных javac.

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

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

Для написания любого другого языкового компилятора требуется то же самое:анализирую AST, затем преобразую это в инструкции для целевой архитектуры (байтовый код) и сохраняю его в нужном формате (файлы.class).

С точки зрения пользователей, вы просто пишете код и запускаете двоичные файлы компилятора, и на выходе получаются файлы .class, которые вы можете смешивать с теми, которые создает ваш java-компилятор.

Языки .NET предназначены скорее для показа, чем для реальной полезности.Каждый язык был настолько переработан, что все они превратились в C # с новым лицом.

Существует множество причин для предоставления альтернативных языков для виртуальной машины Java:

  • JVM является мультиплатформенной.Любой язык, портированный на JVM, получает это в качестве бесплатного бонуса.
  • Существует довольно много устаревшего кода.Устаревшие системы, такие как ColdFusion, работают лучше, предлагая заказчикам возможность постепенно переходить от устаревших решений к современным.
  • Определенные формы написания сценариев лучше подходят для быстрой разработки.JavaFX, например, разработан с учетом быстрой графической разработки.Таким образом, он конкурирует с такими движками, как DarkBasic.(Процессинг - еще один игрок в этом пространстве.)
  • Среды сценариев могут предложить контроль.Например, приложение может пожелать предоставить пользователю среду, подобную VBA, без предоставления базовых Java API.Использование такого движка, как Rhino, может обеспечить среду, поддерживающую быстрое и грязное кодирование в тщательно контролируемой изолированной среде.
  • Интерпретируемые скрипты означают, что нет необходимости что-либо перекомпилировать.Отсутствие необходимости перекомпиляции приводит к созданию более динамичной среды.например ,Несмотря на использование OpenOffice Java в качестве "языка сценариев", Java не подходит для этого использования.Пользователь должен пройти через все виды циклов перекомпиляции / перезагрузки, которые не нужны в динамической среде сценариев, такой как Javascript.
  • Это подводит меня к другому вопросу.Скриптовые движки легче остановить и перезагрузить, не останавливая и не перезагружая всю JVM.Это повышает полезность языка сценариев, поскольку среда может быть сброшена в любое время.

Разработчику компилятора гораздо проще генерировать байт-коды JVM или CLR.Они представляют собой гораздо более чистую и высокоуровневую абстракцию, чем любой машинный язык.Из-за этого гораздо более целесообразно экспериментировать с созданием новых языков, чем когда-либо прежде, потому что все, что вам нужно сделать, это настроить таргетинг на одну из этих архитектур виртуальных машин, и у вас будет набор инструментов и библиотек, уже доступных для вашего языка.Они позволяют разработчикам языков больше сосредоточиться на самом языке, чем на всей необходимой инфраструктуре поддержки.

Потому что процесс JSR делает Java все более и более мертвой: http://www.infoq.com/news/2009/01/java7-updated

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

Java накопила огромную базу пользователей за семь основных версий (от 1.0 до 1.6).Его способность развиваться ограничена необходимостью сохранения обратной совместимости для бесчисленных миллионов строк кода Java, запущенных в производство.

Это проблема, потому что Java должна эволюционировать, чтобы:

  • соревнуйтесь с новыми языками программирования, которые извлекли уроки из успехов и неудач Java.
  • внедряйте новые достижения в разработке языков программирования.
  • позволить пользователям в полной мере воспользоваться достижениями в области аппаратного обеспечения - напримермногоядерные процессоры.
  • исправьте некоторые передовые идеи, которые привели к неожиданным проблемам (например,проверенные исключения, дженерики).

Требование обратной совместимости является препятствием для сохранения конкурентоспособности.

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

Любой новый язык имеет те же преимущества и недостатки, что и C #, по сравнению с Java в крайней степени.Одним из способов максимизации преимуществ с точки зрения языковых возможностей и минимизации недостатков с точки зрения зрелых библиотек и фреймворков является создание языка для существующей виртуальной машины и обеспечение его совместимости с кодом, написанным для этой виртуальной машины.В этом причина скромного успеха Groovy и Clojure;и ажиотаж вокруг Scala.Без JVM эти языки могли бы занять лишь крошечную нишу в очень специализированном сегменте рынка, тогда как с JVM они занимают значительную нишу в мейнстриме.

Они делают это, чтобы не отставать от .Net..Net поддерживает C #, VB, J # (ранее), F #, Python, Ruby (скоро появится) и c ++.Наверное, я чего-то не понимаю.Вероятно, самый большой из них - это Python, для специалистов по написанию сценариев.

В какой-то степени это, вероятно, "Гонка вооружений" против .NET CLR.

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

Я собираюсь предоставить кому-то более квалифицированному рассказать о том, что требуется для написания нового языка / компилятора.

Что касается того, как писать код, вы делаете это в notepad / vi, как обычно!(или используйте инструмент разработки, поддерживающий язык, если вы хотите сделать это простым способом.) Для компиляции потребуется специальный компилятор для языка, который будет интерпретировать и компилировать его в байт-код.

Поскольку java также создает байт-код технически, вам не нужно делать ничего особенного для его запуска.

Причина в том, что платформа JVM предлагает множество преимуществ.

  • Гигантское количество библиотек
  • Более широкий уровень платформы реализации
  • Зрелые фреймворки
  • Устаревший код, который уже является частью вашей инфраструктуры

Языки, которые Sun пытается поддерживать с помощью своей спецификации сценариев (напримерPython, Ruby) популярны во многом благодаря их предполагаемому повышению производительности.Запуск Jython теоретически позволяет вам быть более продуктивным и использовать возможности Питон чтобы решить проблему, более подходящую для Python, но при этом иметь возможность интегрироваться на уровне среды выполнения с вашей существующей кодовой базой.Классические реализации Питон и Рубин дает ту же способность для C библиотеки.

Кроме того, часто бывает проще выразить некоторые вещи на динамическом языке, чем на Java.Если это так, вы можете пойти другим путем;потреблять Python/Ruby библиотеки из Java.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top