Подтвердить что ты не робот

Почему существует множество реализаций JRE?

Мне было интересно... Есть Sun JRE, IBM JRE, BEA JRE, Oracle JRE и некоторые менее известные JRE на рынке. Почему так много реализаций JRE? Является ли тот факт, что Sun открыл платформы Java, означает, что будет один открытый JRE/JDK? Или мы идем к тому, что случилось с Linux и его многочисленными дистрибутивами?

4b9b3361

Ответ 1

Почему существует более одного компилятора C? Почему существует более одной реализации Ruby? Различные реализации позволяют различным группам исследовать различные возможности оптимизации и т.д. Например, я уверен, что в один момент IBM JRE была намного быстрее, чем Sun для плавающей точки. Другие реализации могут иметь специальные функции для предварительной компиляции и т.д.

Относительно того, сможет ли OpenJDK сократить доступное разнообразие - трудно сказать. Я рад, что разнообразие существует, хотя конкуренция, как это, помогает всем.

Ответ 2

Sun поддерживает Solaris, Windows и Linux со своими JRE и JDK. Другие поставщики хотели, чтобы их платформы поддерживались, поэтому они написали свои собственные, обычно на основе технологии, лицензированной Sun. Именно поэтому Apple разработала JVM, они хотели поддержку OS X. Разработчики с открытым исходным кодом хотели, чтобы Java поддерживалась на BSD и на платформах Linux, отличных от x86 и Sparc (например, PowerPC). IBM хотела JVM для z/OS и AIX, и, поскольку они все-таки ее разрабатывали, они могут также выпускать ее для Windows и Linux.

Является ли Oracle JRE просто JRockit, который они приобрели с помощью BEA?

Ответ 3

Потому что они обслуживают разные потребности? Sun JRE являются основными для Windows и Linux для настольных компьютеров и многих серверных приложений. BEA обладает некоторыми хорошими возможностями управления и улучшенной производительностью для многих случаев (за счет более высоких сроков запуска и более высокого потребления памяти). IBM также теоретически работает быстрее и настроена на работу с серверами приложений. Это дает ему несколько пользователей в Linux и Windows, но в большинстве своем они популярны на платформах, поддерживаемых не Sun (IBM AIX, OS400 и т.д.).

Я считаю, что "Oracle JRE", о котором вы говорите, - это просто ребрендинг BEA JRE после покупки BEA.

В конце концов, все они совместимы с Sun TCK и, как правило, используют много кода (библиотеки Java, Swing, в некоторых случаях Hotspot), а также чрезвычайно высокую степень совместимости. На практике они по меньшей мере совместимы друг с другом как различные версии Windows (Vista против сервера и т.д.).

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

И тогда, конечно, Sun не выпускает виртуальную машину для Mac, так как Apple управляет ею сами.

Итак, похоже ли это на ситуацию с дистрибутивами Linux? На самом деле, я не думаю, что по двум причинам:

  • Тестирование. Каждый из них передает TCK для обеспечения совместимости со стандартом. В дистрибутивах Linux очень мало усилий для поддержания аналогичной совместимости.
  • Версии - Java 1.6 == Sun 1.6 == IBM 1.6 == Любая Java 1.6. У Linux очень мало стандартизации в плане управления версиями, чтобы обеспечить совместимость между выпусками. LSB пытается это сделать, но пока не существует.
  • Консистенция. За исключением нечетных платформ, для которых стандартные инструменты jdk вряд ли будут работать "стандартным" способом (например, AS/400), каждый будет чувствовать себя точно так же. Каждый из них имеет один и тот же "javac" и другие инструменты, соответствующие стандартам Sun. На практике они намного больше похожи на дистрибутивы Linux.

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

Ответ 4

BEA сделал один, потому что для его сервера WebLogic необходимы специальные улучшения производительности. Другие по тем же причинам. Они все думают, что могут сделать это немного лучше, и все они нуждаются в чем-то особенном от JRE. У Солнца есть спецификации для JRE, и все, что я знаю, соответствуют ему. Поэтому любой написанный вами код Java или Scala должен работать.

О, а openJDK не решит все проблемы, поэтому все еще будет много проприетарных JRES.

Ответ 5

Есть много JRE, потому что люди, использующие Java, имеют множество разных наборов требований. Использование сервера часто будет использовать JRockit ранее BEA, теперь Oracle), поскольку он специально настроен для использования сервером. Предложения Sun настроены так, чтобы работать хорошо для любого использования, но предложения сторонних производителей могут быть настроены на работу лучше, чем Sun JRE в конкретных или нишевых режимах.

Это отличается от Linux и его многочисленных дистрибутивов из-за гарантий, которые устанавливаются требованиями лицензирования Sun для сторонних реализаций Java. Barring bugs, вы в значительной степени знаете, как будут работать все Java JRE. Спецификации довольно плотные.

Ответ 6

Я не думаю, что открытие JDK означает, что количество JRE останется прежним или уменьшится. Если что-нибудь, основанное на опыте сообщества с открытым исходным кодом (Linux, например?), У нас, вероятно, будет еще больше JRE.

А почему бы и нет? Конкурс - это хорошо.

Ответ 7

Java была разработана для того, чтобы начать с стандартной спецификации, которую любой мог реализовать. Цель заключалась в том, чтобы выгрузить некоторую работу от Sun, чтобы сделать ее более универсальной (поскольку поставщики ОС/платформ могут писать свои собственные JRE), но что более важно, чтобы обеспечить конкуренцию и, следовательно, повысить производительность.

В значительной степени эта модель работала достаточно хорошо. Многие из новых методов сбора мусора были изначально разработаны, опробованы и опробованы на исследовательских JRE. Так что некоторые другие оптимизации (например, IBM Researched используется для поддержки отдельной JRE). Другие производители создали реализации, оптимизированные для конкретной архитектуры.

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

Ответ 8

Если вы сомневаетесь, просто используйте стандартную Java VM от Sun/Oracle.

Помните, что Sun не полностью Open Source все Java, некоторые части закрыты.

Основные причины сторонних внедрений VM
- Поддержка поддерживаемых солнцем платформ
- Закрытые платформы (Mac, их дает лучшую интеграцию с ОС, поэтому вы не можете жаловаться.
- Ограничения лицензирования (не могут быть распределены по дистрибутивам)
- Политика дистрибутива ОС (Fedora предоставляет только бесплатное и открытое программное обеспечение)
- Просто пытается конкурировать и создавать лучшую Java VM
- Оптимизация/расширение платформы (Android)

Ответ 9

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

Ответ 10

Существуют другие JRE, такие как OpenJDK, который является открытым исходным кодом. Существуют также версии J2ME, которые работают на мобильных устройствах и вещах таких игроков blu-ray.

Ответ 11

Некоторые реализации JRE адаптированы для рынка встроенных систем, где размер памяти иногда более важен, чем необработанная скорость.

Даже у Sun есть как минимум две версии JRE - серверная версия, которая лучше работает, но использует больше памяти и занимает больше времени для запуска, а также клиентскую версию, оптимизированную для запуска небольших приложений.