IBM будет участвовать в развитии OpenJDK

>Отказалась бесплатно, или даже и продавать не хочет?
Продавать не хочет

VMWare, которая жутко охоча до денег, и не меньше Microsoft хочет чтобы ее ОС VMWare стояла на 99% серверов

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

>Тот кто зарабатывает деньги на хостингах обычно имеет специалистов которые решают все проблемы сами а не ждут когда их порешают в редхате - бизнес такой. И потому редхат проносится мимо.

Не все проблемы легко решается. Малое количество контрактов на поддержку компенсируется огромным размером рынка, из-за которого это «малое» вырастает во вполне нормальные вещи.

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

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

Надо просто понимать, что не всегда хорошее решение - массовое, и не всегда массовое решение - хорошее. Но если оно самое популярное в количественном размере, то с ним надо считаться.

Так что да, макдональдс - гораздо более богатая и серьёзная компания, чем мелкий элитный ресторан в центре туристического города. Разные доходы, разные масштабы. И для рынка этот ресторанчик ничто, а макдональдс - всё.

Ну теперь ораклу точно капец.

>Oracle отказалась выдать лицензию на тест совместимости, так как Harmony не ограничивает область применения проекта.

Получается, IBM признал поражение и сдался?

>А OpenJDK под неё нет.

ее нет не потому что нет - а потому что посыл - качайте с сана. Нет - компилите сами.

А значит опять будет различие и опять не будет полной совместимости.

Я надеюсь тык же относишся к SLES/RHEL и прочим базированным дистрам и требуешь чтобы редхат страдал херней и пилил за спасибо федору.

>и ладно бы какая совсем бесполезная ерунда была, а нет же, мало кто скажет, что если бы это было, было бы хуже

Мало кто скажет что еслибы унитаз у него поставили из золота - было бы хуже. Ты подменяешь понятия.

Рефлективная доступность у генериков есть. В скале с помощью манифестов - элементарно легкая рантаймовая доступность. В джаве нужно хак вида тайпреференсе. Польза от генериков уровня vm - незначительна. От того что ее нет не страдает никто.

>Я надеюсь тык же относишся к SLES/RHEL и прочим базированным дистрам и требуешь чтобы редхат страдал херней и пилил за спасибо федору.

Не стоит сравнивать. Федора - дистрибутив для определённого контингента людей, которым нужен свежий софт. Им редхат не подойдёт. В результате довольны и редхатовцы (бесплатный тест) и пользователи. Получается, что rhel и федора это разные вещи. Для разных задач.

Плюс, при желании на федоре можно работать так же, как и на RHEL-е. Просто надо настраивать по-другому.

А на OpenJDK не получится настраивать по-другому, на ней некоторые вещи просто не работают. Отчего у неё нет преимуществ перед проприетарной, кроме единственного - возможность включать в пакетный менеджер дистрибутивов, которые любят свободные идеи. В остальном этот продукт всегда хуже проприетарного.

>цитата с вики. вывод делайте сами.

Вывод: вы либо сознательный троль либо не врубаетесь о чем разговор. Можете меня цитировать.

> А в дистрибах Linux`а OpenJDK -по-умолчанию. Почему Гармонию не любят?

Гармония не сертифицирована TCK, а значит не получает Sun-овские лицензии на java. И Sun и Oracle этот TCK не дают. вот такая петрушка.

> Или МежДелМаш не в состоянии проспонсировать ASF для покупки лицензии?

не в состоянии - для этого им пришлось бы купить Sun.

>Малое количество контрактов на поддержку компенсируется огромным размером рынка

Я подозреваю что их не мало - их нет.

В тех случаях, когда специалистов нет, и фирма готова ждать, пока сторонняя поддержка починит, не берут редхаты и линуксы вообще.

Это вооющето основные клиенты редхата.

Но если оно самое популярное в количественном размере, то с ним надо считаться.

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

И для рынка этот ресторанчик ничто, а макдональдс - всё.

А ты попробуй попитаться каждый день исключительно это едой. Тогда поймешь про важность для рынка массовых дешевых решений.

>А на OpenJDK не получится настраивать по-другому, на ней некоторые вещи просто не работают.

Список вещей в студию. А то у меня подозрение что ты по теме знаешь что тебе рабинович напел.

> Мало кто скажет что еслибы унитаз у него поставили из золота - было бы хуже.

Конечно было бы хуже! Все бы старались прийти погадить ко мне. А каждый второй мечтал бы унести его себе :)

>Список вещей в студию. А то у меня подозрение что ты по теме знаешь что тебе рабинович напел.

Ну вот, как пример, про который писал кто-то в комментах на лоре недавно - банк-клиент от БИФИТ-а для юрлиц. Очень распространён на российских просторах.

Далее в этом же треде писали про jedit, но за это я поручиться не могу.

А ещё постоянные разговоры вида «тормозит нетбинс - поставь нормальную джаву».

>А ещё постоянные разговоры вида «тормозит нетбинс - поставь нормальную джаву»

То есть списка неработающих вещей нет - есть песни рабиновичей неясной этимологии. ЧИТД.

>То есть списка неработающих вещей нет - есть песни рабиновичей неясной этимологии. ЧИТД.

А банк-клиент?

А ещё отсутствие JavaFX, кстати.

>>. Есть проприетарная джава, на неё всё работает быстрее и стабильное.

Ну покажи мне ее под эппл.

Вообще-то есть такая штука как Apple Java. И она является неотъемлемой частью Mac OS X. Помнится, я как-то им даже баг-репорты слал.

> А ещё отсутствие JavaFX, кстати.

Кстати да, если бимеры запилят его в OpenJDK, обещаю перевести всех кого знаю, на их эту DB2.

Так вот эти ваши доли процента нихрена не доли. Большая половина агентов работае с эпловыми форматами.

Это да. Но, справедливости ради, владел бы Торвальдс, а не Джобс, «голливудскими» акциями - было бы иначе.

>А банк-клиент?

Ты сказал что проблемы решить нельзя - они просто не работают. Разработчики банк-клиента тестировли его на openjdk? Проверяли совместимость? Пытались решить эту проблему? Нет? Какие вопросы? Жабаплатформа - охрененно здоровая софтина - и в ней как и во всех бывают баги. Я тебе с легкостью покажу пример где драгєндроп вешает эпловскую жабу в эпловском нативе в коке при дропе на неверхний контрол, и где это без проблем работает в openjdk. Понятно что основная вина тут на эпле. Но при чем тут жаба как платформа - если кто-то пускает приложение на платформе на которой оно даже не тестировалось? Когда-то была пробелам с RMI при взаимодействии между сановской и бимеровской VM - не десереализовались данные.

Разные реализации жаваплатформы потому и разные - в них разные баги. Чтобы продукт был копатибл - нажо тестировать на всех и делать так чтобы работало на всех.

Вон тебе монобаги вида - на венде работает на линуксе нет:

http://bugs.mysql.com/bug.php?id=12871
http://www.gamedev.net/community/forums/topic.asp?topic_id=526073
http://ubuntuforums.org/showthread.php?t=1463408
....
А это вообще одна и та же мона.

>Вообще-то есть такая штука как Apple Java.

Не сыпь мне соль на сахар. Особенно относительно доступности актуальных версий на PPC и IA32.

Я надеюсь тык же относишся к SLES/RHEL и прочим базированным дистрам и требуешь чтобы редхат страдал херней и пилил за спасибо федору.

Кстати, да, двойная мораль - не редкость в Linux-сообществе. С одной стороны - «хорошо, что мы не Windows, у нас все свободное», с другой - «идите в сад со своим BSD, нам косточку в виде блоба бросили, у нас всё работает, остальное не интересует».

> Увидел на сайте http://www.rabbitmq.com/ логотип SpringSource, т.е. это та же жаба?

Это Erlang. Ориентирован на клиентов на Java/.NET.

jEdit в OpenJDK6 изначально нормально работал.

>Ты сказал что проблемы решить нельзя - они просто не работают. Разработчики банк-клиента тестировли его на openjdk? Проверяли совместимость? Пытались решить эту проблему? Нет? Какие вопросы?

Хах, ну тогда любой софт можно просто переписать, чтобы работало с другой платформой. Хоть IE под линукс переписать.

В чём смысл кучи разных реализаций джавы, если они несовместимы между собой? Где тогда её легендарная кроссплатформенность - «написал и запустил на любой платформе не думая», которой так гордятся джавакодеры?

Ты сам подтверждаешь, что OpenJDK требует дополнительной работы по портированию, в лучшем случае тесты, в худшем - переписывание кусков кода. При этом OpenJDK делается саном-ораклом и претендует на использование в продакшене. А по сути это какая-то триал-версия, полезная только GPL-фанатикам.

Но при чем тут жаба как платформа - если кто-то пускает приложение на платформе на которой оно даже не тестировалось?

Так постой, ты ж пишешь, что жаба это платформа. На ней приложение и писалось. Как так это оно на ней же не тестировалось? Или ты признаешь, что жаба и что-то, названное OpenJDK - другая платформа, но тогда жаба - не платформа, а просто какое-то название абстрактного стандарта, как html/xhtml - стандарт есть, а никто не соблюдает.

Разные реализации жаваплатформы потому и разные - в них разные баги. Чтобы продукт был копатибл - нажо тестировать на всех и делать так чтобы работало на всех.

«Разные реализации ОС (линукс, виндовс, мсдос) потому и разные - в них разные баги. Чтобы продукт был компатибл - надо тестировать на всех и делать так, чтобы работало на всех». Только тогда, уж простите, не стоит говорить про кроссплатформенность джавы из коробки. Она не более кроссплатформенна, чем Си.

Вот бы ещё java-plugin для FF на нём заработал

> Вон тебе монобаги вида - на венде работает на линуксе нет:

Ну кстати с Моной тут я не нашел, что связано. Коннектор к MySql пишут не они, «porting Windows Forms on Mac OS X» --- э, они Windows.Forms и кривые, никто ни не обещал, третье --- запуск внешних процессов.

Для JavaFX нужно сначала интегрировать в OpenJDK Java Plug-in, для того, чтобы заработали апплеты в окнах браузеров.

>В чём смысл кучи разных реализаций джавы, если они несовместимы между собой?

Они совместимы. Какого хрена? В чем смысл линуксов если они несовместимы между собой? Давай я возьму пакет из дебиан тестинг положу его в стабле и вынесу приговор на основании того что не раюотает что дебиан не нужен и вообще линукс говно без смысла?

Ты сам подтверждаешь, что OpenJDK требует дополнительной работы по портированию

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

Что за бредовая претензия вообще? Программа не работает на платформе где ее не почесался некто даже потестировать. Найди мне хоть одну которая в таких условиях работает.

Или ты признаешь, что жаба и что-то, названное OpenJDK - другая платформа, но тогда жаба - не платформа,

Сча я вытащу прогу для кедов из федоры и запущу на моей сусе. Результат предсказуем. Вывод: кеды, qt, C++ и линукс гавно. Правильно?

Только тогда, уж простите, не стоит говорить про кроссплатформенность джавы из коробки.

У тебя что-то с головой не то. Тебе говорят что софта идеальтного не бывает и что в разных реализациях разные баги что естественно - а ты делаешь далеко идущие выводы космического характера.

>Ну кстати с Моной тут я не нашел, что связано.

Дык - в заявленных претензиях тоже не работает клиентбанк а не жаба. Указанные баги абослютно симметричны.

А, ну да, там же инвоки сертифицированных dll...

>А, ну да, там же инвоки сертифицированных dll...

Нет - там проблемы которые никто не потрудился проверить под платформами по которым выставляются претензии. Природа проблем - не важна - посколько природы проблем пока никто не изложил. А ну как действительно там есть инвоуки сертифицированных классов из пакета com.sun.*?

>jEdit в OpenJDK6 изначально нормально работал

Извини, - нет.

Я не вру, - так было. Я точно помню, что долго пробовал разные варианты запуска, под конец плюнул и установил сановскую машину + библиотеки и альтернативой переключился на нее. И только тогда редактор нормально заработал. На машине, если не ошибаюсь, стояла OpenSuSE 11.1 Архитектура... хм.. по-моему x86_64 была.

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

>Что с твоей аналогией не так.

Это не с моей аналогией а с твоим аргументом - что что-то дозарезу нужно тольтко на том основании что если бы оно было - то никто не был бы против.

>А ну как действительно там есть инвоуки сертифицированных классов из пакета com.sun.*?

К стати учитывая что это клиентбанк - это весьма вероятно что они полезли своими лапами в непортабельную криптографию сана.

А Марк?

>Что за бредовая претензия вообще? Программа не работает на платформе где ее не почесался некто даже потестировать. Найди мне хоть одну которая в таких условиях работает.

Ну вообще-то такое бывает. Не обязательно тестировать, чтобы работало, если написана программа с учётом кроссплатформенности и прочих нюансов.

Хоть ты и сравниваешь немного утрированно (дистрибутивы линукса итд), но ты, в общем, прав, так что ты победил, и больше я спорить не буду.

>Ну покажи мне ее под эппл.

вы не поверите, но эпловская java уже давным давно почти полностью (кроме части Swing'а) на сановской основывается

Она не более кроссплатформенна, чем Си.

а что не так с Си?

Как только, так сразу.

Время работы измеряется по time, выбирается минимальное в серии из 2-3 запусков. Хотелось бы измерить и потребляемую память, но time никак не хочет понимать опцию --format. Кто-то подскажет пример её использования?

Тут рассказали, как это починить, цитирую:

лечится двумя строчками

sudo emerge -avq sys-process/time
alias time="/usr/bin/time"

ибо тот тайм, который не ест --формат, - это тайм, встроенный в баш, унылейший

Причем скорее всего, что оно уже стоит. У меня вот, например, говорит:

[~] % /usr/bin/time --version
GNU time 1.7

Тогда сделать алиас - и спокойно использовать --format.

>Тут рассказали, как это починить, цитирую

Отличие bash'евского time от GNU /usr/bin/time я к тому времени уже знал. Или, как раз, после того постинга меня носом ткнули. Другое дело, что %M в Ubuntu мне возвращал всегда 0.

А позже, в Gentoo, я так полнообъёмное сравнение провести и не собрался. Начал по мелочи, но времени не было возиться. Нужно будет как-нибудь снова собраться.

>Получается, IBM признал поражение и сдался?
IBM нужен прогресс Java. Слишком много на неё завязано.
И да - IBM сдался.

Как только, так сразу.

Затестировал перл: ClassicOOFib.pm

package ClassicOOFib;

sub new {
        my $class = $_[0];
        return bless({value => $_[1]}, $class);
}

sub value {
        my $value = $_[0]->{value};
        if($value <= 2) {
                return 1;
        }
        my $fib1 = new ClassicOOFib($value - 1);
        my $fib2 = new ClassicOOFib($value - 2);
        return $fib1->value() + $fib2->value(); 
}

1;

MooseFib.pm:

package MooseFib;

use Moose;

has '_value' => (
        is  => 'rw',
        isa => 'Int'
);

sub value {
        my $value = $_[0]->_value;
        if ($value <= 2) {
                return 1;
        }
        my $fib1 = new MooseFib(_value => $value - 1);
        my $fib2 = new MooseFib(_value => $value - 2);
        return $fib1->value() + $fib2->value();
}

no Moose;
__PACKAGE__->meta->make_immutable;

OOFibTest.pl

#!/usr/bin/perl

use strict;
use warnings;
use Benchmark qw(:all);

use ClassicOOFib;
use MooseFib;

sub main_classic {
        for (1 .. 1) {
                my $fib = new ClassicOOFib(40);
                print $fib->value() . "\n";
        }
}

sub main_moose {
        for (1 .. 1) {
                my $fib = new MooseFib(_value => 40);
                print $fib->value() . "\n";
        }
}

timethese(
        1,
        {   'Classic Perl OO' => \&main_classic,
                'Moose OO'        => \&main_moose
        }
);

Результат:

$ time ./OOFibTest.pl                                                                                                                                                                                                
Benchmark: timing 1 iterations of Classic Perl OO, Moose OO...                                                                                                                                                                                                                 
102334155                                                                                                                                                                                                                                                                      
Classic Perl OO: 338 wallclock secs (329.79 usr +  0.49 sys = 330.28 CPU) @  0.00/s (n=1)                                                                                                                                                                                      
            (warning: too few iterations for a reliable count)                                                                                                                                                                                                                 
102334155
  Moose OO: 1541 wallclock secs (1520.62 usr +  1.85 sys = 1522.47 CPU) @  0.00/s (n=1)
            (warning: too few iterations for a reliable count)

real    31m19.866s
user    30m50.587s
sys     0m2.344s

Процессор Core2 Duo E8500 3.16GHz. This is perl, v5.10.1

>user 30m50

Это 1850 сек. И на C2D...

У PHP на Celeron-1860 вышло 1328. ООП на Перле - это сурово :)

Это два разных ОО в перле. Просто интересно стало их сравнить.

>>Я уже сказал, что быстродействие вообще не играет роли

Вообще-вообще? Ну, как знаете... :D

В своё время Java захватила рынок с таким лозунгом.
И разрыв в производительности с С++ был не меньше чем сейчас междй Java и Python/Ruby

jEdit в OpenJDK6 изначально нормально работал

Извини, - нет.

С OpenJDK6 во FreeBSD и jEdit я ни разу не испытывал проблем совместимости. А вот с NetBeans 6.x уже начались проблемы (предыдущие версии 5.x работали удивительно стабильно). Tomcat 5.x и 6.x работают стабильно. Eclipse 3.4, 3.5 компилируются в OpenJDK6 и работают с ним без ошибок.