Почему многие настаивают на перетаскивании JVM в новые приложения?

Question

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

Из того, что я видел, есть много ресурсов, которые связаны с использованием JVM для поддержки языков, таких как Groovy, JRuby и Jython, вместо прямых Ruby или Python.

Ruby и Python могут интерпретироваться практически на любой ОС, так что я не вижу никакого преимущества "пиши когда-нибудь где-нибудь" ... зачем брать с собой неповторимую JVM?

Answer 1

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

Например, недавно я искал что-то вроде JAXB для Python или Ruby. В конце концов, я остановился на JRuby только потому, что не нашел ни одной зрелой, широко используемой библиотеки XML-привязок.

Answer 2

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

И я не знаю, откуда у вас эта идея «неповоротливой» JVM с огромными затратами ресурсов. JIT имеет тенденцию создавать довольно быстрый код, а ядро ​​JVM по современным меркам далеко не огромное. Обычно он имеет большой объем памяти при работе, но это потому, что современные машины имеют много оперативной памяти, и GC работает лучше всего, когда на нем много оперативной памяти. При желании, GC может быть настроен на ад и обратно , чтобы быть более консервативным.

Как сказал кто-то еще: «Самое лучшее в Groovy - это то, что мне не нужно использовать Java. Второе лучшее в Groovy - это то, что я могу использовать Java ».

Answer 3

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

Многое также зависит от зрелости и возможностей платформы, то есть JVM и всего, что с ним связано (вся экосистема Java). Несколько примеров из головы:

• Вы можете подключить удаленный отладчик к работающей JVM и получать все виды информации о работающем приложении, что просто невозможно с Python, Ruby и т. Д. Если пойти еще дальше, есть JMX стандартный способ написания кода, позволяющий отслеживать объекты и даже настраивать их в реальном приложении. Взгляните на JConsole и посмотрите, не пускаете ли вы немного слюни (несмотря на уродство интерфейса).

• Если пойти еще дальше в этом направлении, существует OSGi , стандарт для написания высокомодульного кода, который можно развертывать, запускать, останавливать и даже обновлять в реальном приложении. С OSGi вы разбиваете большое приложение на множество меньших «пакетов», которые затем можно поддерживать (развертывать, запускать / останавливать, обновлять) отдельно. Это действительно большое дело для больших приложений или любых приложений, которые должны постоянно работать.

• Платформа имеет очень хорошую поддержку для асинхронного и надежного обмена сообщениями. Вы получаете JMS в качестве базового уровня и множество превосходных и мощных библиотек, построенных на нем для выполнения сложных задач с очень небольшим кодом (ср. Apache Camel , ServiceMix , Мул и многие другие). Это еще одна особенность, которая чрезвычайно полезна в больших приложениях или приложениях, которые должны работать в более крупном юниверсе кода.

• JVM имеет реальную (на уровне ОС) многопоточность, в то время как Python et al. очень ограничены в этом отношении (как известно, так). (Это, как говорится, параллелизм общего состояния - многопоточность - это неправильный подход; ср. Erlang , Алиса , Моцарт / Оз и т. Д.)

• Существует множество вариантов JVM, выходящих за рамки стандартных реализаций Sun, таких как JRockit , IBM JVM и т. Д. Это область разработки с другими языками - в Python есть Jython, Iron Python, даже PyPy и без стека; В Ruby есть JRuby, Rubinius и другие , но, как бы они ни были, они не могут соответствовать уровню зрелости, найденному в различных предложениях JVM.

Несмотря на это, я действительно не люблю Java язык и избегаю его настолько, насколько это возможно. В эти дни со всеми отличными альтернативными языками для JVM мне не нужно. Groovy получил мой голос за доступность и тесную интеграцию с платформой (и даже с языком), а также из-за Grails, которые я иногда люблю называть «Rails для взрослых». Мне больше нравятся другие языки JVM, в частности Clojure и Scala , но они не так доступны для среднего программиста. Тем не менее, в последнее время Scala часто появляется, особенно благодаря широкому использованию в Twitter , так что есть надежда на интересные и по-настоящему превосходные языки, делающие его в больших средах. Но это уже другая тема.

Answer 4

зачем брать с собой на работу JVM вместе с вами?

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

Тем не менее, хорошие компиляторы, нацеленные на JVM, создают хорошо работающие программы. Я не знаю насчет JRuby; но цель Jython - быть быстрее, чем обычный C Python, и они приближаются (это уже быстрее в нескольких важных случаях).

Помните, что хороший JIT (например, для JVM) может применять некоторые оптимизации, недоступные для статических компиляторов C, поэтому получение более быстрого кода из них - несбыточная мечта. Конечно, виртуальная машина, оптимизированная для вашего языка , должна быть быстрее, чем «не совсем универсальная» виртуальная машина типа JVM; но есть проблема зрелости: JVM выполнил много работы, в то время как JIT для Ruby и Python совсем рядом.

К сожалению, похоже, что нет лучшего универсального байт-кода VM. CLI от Microsoft страдает от тех же ограничений, что и JVM (ironPython намного медленнее и тяжелее, чем JPython). Лучший кандидат, кажется, LLVM. Кто-нибудь знает, почему в LLVM нет более динамичных языков? Я видел несколько компиляторов Scheme, но, похоже, есть несколько проблем.

Answer 5

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

Производительность, простота и гибкость синтаксиса для разработчиков делают Groovy привлекательным для экосистемы Java - ruby ​​или python были бы столь же привлекательны, если бы приводили к байт-коду Java (см. Jython).

Java-разработчики на самом деле не боятся ruby; на самом деле, многие быстро принимают groovy или jython, близкие к ruby ​​и python. То, что их не волнует, оставляет такую ​​удивительную платформу (java) для менее производительного, менее масштабируемого и даже менее используемого языка, такого как ruby ​​(при всех его достоинствах).

Answer 6

Оба Ruby и Python могут быть интерпретируется практически на любой ОС, поэтому я не вижу "пиши один раз беги везде "преимущество ... зачем приносить вместе с тобой JVM?

Главным образом потому, что вы хотите воспользоваться преимуществами ОГРОМНОЙ существующей экосистемы библиотек Java, API и продуктов, которые затмевают все, что доступно для Ruby или Python, особенно в корпоративной области.

Кроме того, имейте в виду, что JRuby и Jython во многих тестах быстрее , чем обычные (реализации C) языков, особенно Ruby (даже Ruby 1.9).

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

То же самое происходит в пространстве .NET, когда несколько языков нацелены на CLR. Виртуальный проект Parrot (steamware) также нацелен на то же самое, и это также заявленная цель проекта LLVM .

Answer 7

Большой недостаток RoR заключается в том, что он не масштабируется и его сложно развернуть. Используя платформу Java, вы можете использовать существующую инфраструктуру.

grails war

Создает файл войны, который легко развертывается на Glassfish, Jboss и т. Д.

Answer 8

Причина - горячая точка.

Это инженерная экскурсия.

Answer 9

Я сталкивался с этим и тоже был сбит с толку, и вот моя теория.

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

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

Итак, когда кто-то приходит и говорит: «Эй! Давайте использовать интерпретируемый язык Си! Это быстро, имеет аккуратные библиотеки и намного быстрее для сценариев и создания прототипов!» Во-первых, парень из Java говорит: «Мне нужно запустить файл make для настройки этого? QUEL HORREUR!» Тогда реальность необходимости развертывания и размещения этого на серверах, работающих под управлением устаревших операционных систем и устаревших версий Tomcat, и ничего больше не начинает действовать.

"Привет, я знаю! Существует Java-версия этого интерпретируемого языка! Он может сломаться на быстрой полосе на мосту в час пик, и иногда он загорается, но я могу заставить Tomcat запустить его. Мне не нужно запачкать руки, изучая не Java, и я могу вставить их в существующую инфраструктуру! Выиграй! "

Итак, является ли это "правильной" причиной выбора Java-реализации языка сценариев? Возможно нет. Зависит от вашего определения «право». Но я подозреваю, что именно по этой причине их выбирают чаще, чем снобам, как я хотел бы верить.

Answer 10

Другая причина, о которой мало кто упоминал, - это существующая инфраструктура, связанная с jvm - если у вас уже есть сервер, на котором работает java, почему бы не использовать его вместо того, чтобы вводить еще одну платформу (например, rails)?