IcedTea

А в репозиториях уже есть?

Это хорошо. Ну в смысле лучше, чем плохо. По собственным замерам говорю: openJDK 1.7 по сравнению с 1.6 жрет на 10%-15% меньше памяти. А тем более GPL.

Я наверно что-то непонимаю, разве sun не открыла исходники явы? Или тут не про то?

+ из подробностей http://article.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/5

True LOR Reference:

> At the present time it's not possible to build a fully Free Software version of OpenJDK, because of the presence of some "binary plugs". Quoting http://openjdk.java.net/:

> "Not all of the source code that makes up the JDK is available under an open-source license. In order to build an OpenJDK binary from source code, you must first download and install one or more of the following files from which the build process will copy over 'binary plugs' for these encumbered components."

> In addition to this, it's necessary to download an unfree JDK to build OpenJDK.

> We have been working within Red Hat to replace these binary plugs with free software based on GNU Classpath and to remove the need for bootstrapping with unfree software. This is important for a number of reasons, the most pressing being that only free software may be used to build operating systems like Fedora.

to anonymouse: нет, в репах пока не появился.

Двоичные ли файлы, исходники ли, все равно гнусная Ява получается кривой (например, некоторые установщики, писанные на Яве, не работают). Про более серьезные проекты, типа Оракла или хотя бы JDS (Гном, переписанный на Яве), и говорить нечего, пробовать их запускать на гнусной Яве несерьезно.

Действительно, не совсем понятно, ради чего гнусники городили огород. Только ради нужного им типа лицензии???!!! - верится слабо. Возможно, была надежда превзойти быстродействие сановской JVM за счет динамической компиляции (от которой отказался Сан), а не интерпретации, но при этом существенно повышается уязвимость системы.

у дебиановцев что ли учатся подбирать названия строго антагонистические?

Велосипед...

Э-э-э... А от какой динамической компиляции отказался Сан? И о какой интерпретации идет речь?

Выбрасываем OpenJDK, Cacao и подобное. Ставим стандартное JDK фирмы Sun. Если работать, а не играться в ппрограамирование на Java.

> Э-э-э... А от какой динамической компиляции отказался Сан? И о какой интерпретации идет речь?

Это основы информатики, милейший. Программа (исполнимый файл, НЕ сценарий) может содержать машинные команды (машинный код, native по-английски) или некоторый промежуточный МАШИННО-НЕЗАВИСИМЫЙ двоичный код, полученный из исходного языка программирования (Java, языки .NET) и выполняемый специальной исполняющей системой. Ко второму типу относятся байт-код Java и двоичный код промежуточного языка CLI (а также, с некоторой натяжкой, двоичное представление старого микрософтовского бейсика).

Есть две возможности для выполнения кода на промежуточном языке: 1) Интерпретация - когда из промежуточного кода выбирается одна команда, переводится в машинные команды и исполняется, затем выбирается следующая и т.д.; 2) Динамическая компиляция (JIT, just-in-time compilation по-английски) - команды промежуточного языка выбираются и переводятся в машинный язык (компилируются) с некоторым опережением по отношению к ИДУЩЕМУ ПАРАЛЛЕЛЬНО С КОМПИЛЯЦИЕЙ исполнению. Собственно, вторая концепция является более новой и разработана группой г-на Бабаяна из Зеленограда, нынче работающего на Интел. Второй концепцией пользовались Борланд и Микрософт в своих системах Java (когда таковые были еще живы). Теоретически, вторая концепция при надлежащем оборудовании и управлении со стороны ОС может давать более высокую производительность, на практике же ни Микрософт, ни Сан, ни Борланд ее больше не используют. Гнусники решили эту концепцию реанимировать; получится их этого, вероятно, что-то подобное борландовской Яве.

> Выбрасываем OpenJDK, Cacao и подобное. Ставим стандартный JDK фирмы Sun. Если работать, а не играться в программирование на Java.

+2. Се речь не мальчика, но мужа. Если надо не шашечки, а ехать.

А теперь почитайте вот это: http://java.sun.com/developer/technicalArticles/Networking/HotSpot/

> А теперь почитайте вот это:

Что прекрасно подтверждает сказанное выше. HotSpot - это оптимизирующая навеска на ИНТЕРПРЕТАТОР: отличие с JIT имеется ПРИ ПЕРВОМ ПРОХОДЕ ПРОГРАММЫ, который выполняется в этом случае "чистым" интерпретатором у Сана и динамическим компилятором у остальных, а при ПОСЛЕДУЮЩИХ выполнениях программы HotSpot выполняет весьма нетривиальную оптимизацию, отличающуюся от обычного JIT как небо от земли. Благодарю за ссылку длля посетителей.

Ладно, мы немного о разных вещах говорим. Хотспот имеет возможности более оптимального управления памятью, потоками и ресурсами, поскольку он собирает статистику о работе приложения, и компилирует участки кода в зависимости от этой статистики. Например он может придерживать объекты, идущие в мусор (более того, он так и делает), и при выполнении инструкции new - возвращать указатель на такой объект (естественно с учетом типа). При полной компиляции перед запуском на месте оператора new будет стоять malloc(), что займет некоторое время. При активной работе с памятью (что вообще характерно для Явы) это может сэкономить не один миллион тактов процессора. Другой пример - сворачивание или наоборот разворачивание циклов в процессе выболнения в зависимости от значения переменной в рантайме. JIT сможет сделать так только с константой. Так что утверждение, что чистый JIT будет всегда выигрывать у хотспота - сомнительна.