Зачем нам нужны другие языки JVM - PullRequest
23 голосов
/ 17 сентября 2008

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

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

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

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


РЕДАКТИРОВАТЬ: Было 3 дополнительных вопроса (изначально комментарии), на которые был дан ответ в принятом ответе. Они перепечатаны здесь для разборчивости:

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

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

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

Ответы [ 17 ]

31 голосов
/ 17 сентября 2008

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

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

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

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

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

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

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

Очень похоже на то, как вы пишете / компилируете / запускаете код на Java. Чтобы намочить ноги, я бы порекомендовал взглянуть на Scala , который безупречно работает на 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)
  }
}
13 голосов
/ 17 сентября 2008

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

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

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

6 голосов
/ 17 сентября 2008

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

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

или

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

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

4 голосов
/ 17 сентября 2008

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

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

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

3 голосов
/ 17 сентября 2008

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

2 голосов
/ 17 сентября 2008

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

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

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

2 голосов
/ 17 сентября 2008

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

2 голосов
/ 17 сентября 2008

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

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

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

1 голос
/ 09 января 2009

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

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

1 голос
/ 17 сентября 2008

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

...