Зачем нам нужны другие языки JVM
вы ищете что-то вроде этого?
[o.specific_attr for o in objects]
17 ответов
Обратиться к Вашим трем вопросам отдельно:
, Каково преимущество в наличии других языков для JVM?
здесь существует два фактора. (1) Почему имеют язык кроме Java для JVM и (2) почему другой язык работал на JVM вместо различного времени выполнения?
- Другие языки могут удовлетворить другие потребности. Например, Java не имеет никакой встроенной поддержки закрытия , функция, которая часто очень полезна.
- язык А, который работает на 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)
}
}
Они делают это, чтобы не отставать от.Net..Net, позволяет C#, VB, J# (раньше), F#, Python, Ruby (прибывающий скоро), и C++. Я, вероятно, скучаю по некоторым. Вероятно, большим там является Python для людей сценариев.
До некоторой степени, это - вероятно, 'Гонка вооружений' против CLR.NET.
, Но я думаю, что существуют также подлинные причины представления новых языков к JVM, особенно когда они будут выполнены 'параллельно', можно использовать правильный язык для правильного задания, язык сценариев как Groovy может быть точно, в чем Вы нуждаетесь для своего представления страницы, тогда как регулярный старый Java лучше для Вашей бизнес-логики.
я собираюсь оставить кого-то более квалифицированным для разговора о том, что требуется, чтобы писать новый язык/компилятор.
Что касается того, как к записи кода, Вы делаете это в notepad/vi, как обычно! (или используйте средство разработки, которое поддерживает язык, если Вы хотите сделать это простой способ.) Компиляция потребует специального компилятора для языка, который интерпретирует и скомпилирует ее в байт-код.
, Так как Java также производит байт-код технически, Вы не должны делать ничего специального для выполнения его.
Для разработчика компилятора намного легче генерировать байт-коды CLR или JVM. Они - намного более чистая и высокоуровневая абстракция, чем какой-либо машинный язык. Из-за этого намного более выполнимо экспериментировать с созданием новых языков чем когда-либо прежде, потому что все, что необходимо сделать, предназначаться для одной из этой архитектуры VM, и у Вас уже будет ряд инструментов и библиотек доступным для Вашего языка. Они позволяют разработчикам языка сфокусироваться больше на языке, чем вся необходимая инфраструктура поддержки.
Преимущество для этих других языков состоит в том, что они получают относительно легкий доступ к большому количеству библиотек Java.
преимущество для людей Java варьируется в зависимости от языка - у каждого есть история, говорят кодерам Java о том, что они добиваются большего успеха. Некоторые подчеркнут, как они могут использоваться для добавления динамических сценариев к основанным на JVM приложениям, другие будут просто говорить о том, как их язык легче использовать, имеет лучший синтаксис, или так дальше.
, Что требуется, то же самое для записи любого другого языкового компилятора: парсинг к AST, затем преобразование это к инструкциям для целевой архитектуры (код байта) и хранение его в правильном формате (.class файлы).
С точки зрения пользователей, Вы просто пишете код и выполняете двоичные файлы компилятора, и прибывает .class файлы, в которых можно смешаться с теми компилятор Java производит.
Языки.NET больше для шоу, чем фактическая полноценность. Каждый язык был так забит, что они - весь C# с новой поверхностью.
существует ряд причин для обеспечения альтернативных языков для Java VM:
- JVM является многоплатформенной. Любой язык, портированный к JVM, получает это как свободную премию.
- там существует довольно мало унаследованного кода. Устаревшие механизмы как ColdFusion работают лучше при предложении клиентам способности медленно поэтапно осуществить их приложения от унаследованного решения до современного решения.
- формы Certain сценариев лучше подходят для быстрой разработки. JavaFX, например, разработан с быстрой Графической разработкой в памяти. Таким образом это конкурирует с механизмами как DarkBasic. (Обработка является другим плеером в этом пространстве.)
- среды Сценариев могут предложить управление. Например, приложение может хотеть представить подобную VBA среду пользователю, не представляя базовые API Java. Используя механизм как Носорог может обеспечить среду, которая поддерживает быстрое и грязное кодирование в тщательно управляемой песочнице.
- Интерпретируемые сценарии означают, что нет никакой потребности перекомпилировать что-либо. Никакая потребность перекомпилировать не переводит в более динамическую среду. например, Несмотря на использование OpenOffice Java как "язык сценариев", Java сосет для того использования. Пользователь должен пройти все виды, перекомпилировали/перезагрузили циркуляции, которые являются ненужными в динамической среде сценариев как JavaScript.
- , Который приносит мне к другой точке. Механизмы выполнения сценариев могут быть более легко остановлены и перезагружены, не останавливаясь и перезагружая всю JVM. Это увеличивает утилиту языка сценариев, поскольку среда может быть сброшена в любое время.
Ответ просто Ваш второй вопрос:
JVM является просто абстрактной машиной и моделью выполнения. Так быть предназначением это с компилятором все равно как любая другая машина и модель выполнения, для которой компилятор мог бы предназначаться, быть реализованным в аппаратных средствах (x86, ЯЧЕЙКА, и т.д.) или программное обеспечение (попугай.NET). JVM довольно проста, таким образом, на самом деле довольно легкая цель для компиляторов. Кроме того, реализации имеют тенденцию иметь довольно хорошие JIT-компиляторы (для контакта с паршивым кодом, который javac производит), таким образом, можно получить хорошую производительность, не имея необходимость волноваться о большой оптимизации.
Несколько протестов применяются. Во-первых, JVM непосредственно воплощает модуль Java и систему наследования, таким образом пытаясь сделать что-либо еще (множественное наследование, несколько диспетчеризируют), вероятно, будет хитро и потребует замысловатого кода. Во-вторых, JVMs оптимизированы для контакта с видом байт-кода, который производит javac. Создание байт-кода, который очень отличается от этого, вероятно, войдет в дальние уголки JIT-компилятора / JVM, которая, вероятно, будет неэффективна в лучшем случае (в худшем случае, они могут разрушить JVM или по крайней мере дать побочные исключения VirtualMachineError).
Различные языки адаптируются в соответствии с различными задачами. В то время как определенные проблемные области соответствуют языку Java отлично, некоторых намного легче выразить на альтернативных языках. Кроме того, поскольку пользователь приучил к Ruby, Python, и т.д., способность генерировать Байт-код Java и использовать в своих интересах классы JDK и JIT-компилятор обладает очевидными преимуществами.
Преимуществом для наличия других языков для JVM является вполне то же как преимущество для наличия других языков для компьютера в целом: в то время как все полные Тьюрингом языки могут технически выполнить те же задачи, некоторые языки делают некоторые задачи легче, чем другие, в то время как другие языки делают другие задачи легче. Так как JVM - что-то, что у нас уже есть способность работать на всех (хорошо, почти все) компьютеры и много компьютеров, на самом деле уже иметь ее, мы можем получить "запись однажды, выполнить куда угодно" преимущество, но не требуя, чтобы каждый использовал Java.
Запись языка/компилятора для JVM не действительно отличается от записи той для реальной машины. Реальная разница - то, что необходимо скомпилировать в байт-код JVM вместо к исполняемому коду машины, но это - действительно незначительные различия в главной схеме вещей.
код Записи для языка кроме Java в JVM действительно не отличается от записи Java кроме, конечно, который Вы будете использовать различный язык. Вы скомпилируете использование компилятора, который кто-то пишет для него (снова, не очень отличающийся от компилятора C, существенно, и в значительной степени не отличающийся вообще от компилятора Java), и Вы закончите способность выполнить его точно так же, как Вы были бы скомпилированный код Java с тех пор, как только это находится в байт-коде, JVM не может сказать, из какого языка оно прибыло.
Я ответил бы, “because , Java сосет ”, но с другой стороны, возможно, это слишком очевидно †¦ В;-)
Вам нужны другие языки на JVM по той же причине, Вам нужны языки параллельного программирования в целом: Различные языки лучше как решают различные проблемы... статический контроль типов по сравнению с динамическим контролем типов, строгим по сравнению с ленивым... Описание, Обязательное, Объектно-ориентированное... и т.д.
В целом, пишущий "компилятор" для другого языка для работы JVM (или на.Net CLR), является по существу вопросом компиляции того языка в байт-код Java (или в случае.Net, IL) вместо к блоку/машинному языку.
Однако много дополнительных языков, которые пишутся для JVM, не компилируется, а скорее интерпретируемые языки сценариев...
Java является довольно подробным языком программирования, который становится устаревшим очень быстро со всеми новыми необычными языками/платформами, выходящими за прошлые 5 лет. Поддерживать весь необычный синтаксис, который люди хотят на языке И сохраняют назад совместимость, имеет больше смысла добавлять больше языков ко времени выполнения.
Другое преимущество - он, позволяет Вам выполнить некоторые веб-платформы, записанные в крыле Ruby JRuby (иначе направляющие), или Grails (Groovy на Railys по существу), и т.д. на доказанной платформе хостинга, которая, вероятно, уже работает во многих компаниях, вместо того, чтобы иметь необходимость к использованию этого совсем не как проверенные на практике среды хостинга Ruby.
Для компиляции других языков Вы просто преобразовываете в Байт-код Java.
Переворачивание с ног на голову этого, полагайте, что Вы хотите разработать новый язык, и Вы хотите, чтобы оно работало в управляемом времени выполнения с JIT и GC. Тогда полагайте, что Вы могли:
(a) пишут, что Вы владеете управляемым временем выполнения (VM) и занимаетесь всеми видами технически сложных вопросов, которые, несомненно, приведут ко многим ошибкам, плохая производительность, неподходящая поточная обработка и большое усилие по мобильности
или
(b) компилируют Ваш язык в байт-код, который может работать на Java VM, который уже довольно зрел, быстро и поддерживаемый в ряде платформ (иногда больше чем с одним выбором поставщика impementation).
, Учитывая, что байт-код JavaVM не связывается так тесно с языком Java, что незаконно ограничило тип языка, который можно реализовать, это была популярная целевая среда для языков, которые хотят работать в VM.
То, что может сделать JVM, определяется байт-кодом JVM (что Вы находите в .class файлах), а не исходный язык. Так изменение языка исходного кода высокого уровня не собирается оказывать существенное влияние на доступную функциональность.
, Что касается какой требуется, чтобы писать компилятор для JVM, все, что действительно необходимо сделать, генерируют корректный байт-код / .class файлы. Как Вы пишете/компилируете, что код с альтернативным видом компилятора зависит от рассматриваемого компилятора, но однажды выходы компилятора .class файлы, выполняя их не отличается, чем выполнение .class файлов, сгенерированных javac.
Причина состоит в том, что платформа JVM предлагает много преимуществ.
- Гигантское количество библиотек
- Более широкая степень реализаций платформы
- Зрелые платформы
- Унаследованный код это уже - часть Вашей инфраструктуры
языки, которые Sun пытается поддерживать с их спецификацией Сценариев (например, Python, Ruby) произошли и посетители в основном из-за их воспринятых улучшений производительности. Выполнение Jython позволяет Вам, в теории, быть более продуктивным, и усилить возможности Python , чтобы решить проблему больше подходящее для Python, но все еще быть в состоянии интегрироваться, на уровне во время выполнения, с Вашей существующей кодовой базой. Классические реализации Python и производят Ruby ту же способность к [1 113] библиотеки C.
Кроме того, часто легче выразить некоторые вещи на динамическом языке, чем в Java. Если это верно, можно пойти другим путем; используйте библиотеки Python/Ruby от Java.
существует хит производительности, но многие готовы признать это в обмен на менее подробную, более ясную кодовую базу.
-
1you' право ре, Martin! I' ll восстанавливают мой ответ немного. – Michael Dautermann 4 July 2013 в 17:11
Поскольку процесс JSR представляет более мертвый Java: http://www.infoq.com/news/2009/01/java7-updated
Это - позор, что даже существенные и давно известные дополнения как Закрытия не добавляются просто, потому что участники не могут договориться о реализации.
Java накопила огромную базу пользователей за семь основных версий (от 1.0 до 1.6). Его способность развиваться ограничена необходимостью сохранения обратной совместимости для бесчисленных миллионов строк кода Java, выполняемого в производственной среде.
Это проблема, потому что Java должна развиваться, чтобы:
- конкурировать с новыми языками программирования, которые извлекли уроки из успехов и неудач Java.
- включают новые достижения в разработке языков программирования.
- позволяют пользователям в полной мере использовать преимущества аппаратного обеспечения - например, многоядерные процессоры.
- исправляют некоторые передовые идеи, которые приводили к неожиданным проблемам (например, проверенные исключения, дженерики).
Требование обратной совместимости является препятствием для сохранения конкурентоспособности.
Если вы сравниваете Java с C #, у Java есть преимущество в виде зрелых, готовых к производству библиотек и фреймворков, а также недостаток с точки зрения языковых функций и скорости увеличения доли рынка. Это то, чего вы ожидаете от сравнения двух успешных языков, которые живут в одном поколении.
Любой новый язык имеет те же преимущества и недостатки, что и C # в значительной степени по сравнению с Java. Один из способов максимизировать преимущества с точки зрения языковых функций и минимизировать недостатки с точки зрения зрелых библиотек и фреймворков - создать язык для существующей виртуальной машины и сделать его совместимым с кодом, написанным для этой виртуальной машины.Это причина скромного успеха Groovy и Clojure; и ажиотаж вокруг Scala. Без JVM эти языки могли бы занять лишь крошечную нишу в очень специализированном сегменте рынка, тогда как с JVM они занимают значительную нишу в мейнстриме.