Trolltech недавно прислали письмо о выходе Qt Jambi Technology Preview. Из любопытства глянул - да-а, выглядит крайне любопытно. Как-то и Java стала менее убого выглядеть: во-первых, это возможность разрабатывать на Java графические приложения (да ещё с помощью Qt Designer!), которые не тормозят, во-вторых - всё изящество Qt и тут доступно (например, сигналы и слоты, в том числе и для сокетов, к примеру), из-за чего большая часть корявости Java (вроде громоздких селектов nio и всяких Listener'ов) пропадает.

Теперь, значит, Qt не только кросс-платформенная, но и кросс-языковая технология. C++, Python, Java - пиши на чём хочешь. Причём Qt Jambi даёт возможность писать часть приложения на C++, а часть - на Java.

Я вообще не шибко люблю жабу, но тут она вдруг стала смотреться гораздо приятней. Кому интересно - читаем, качаем, пробуем:
http://www.trolltech.com/company/newsroom/announcements/press.2006-07-14.7914556269/

Не понял, что куда пропадает, но по-моему



и



по прозрачности примерно одинаковы (в лучшем случае), а вот по компактности, изящности и читаемости Qt Jambi явный лидер. Да, а moc тут вообще нет, сигналы тут - это объекты специального класса.

С лицензиями действительно лажа. Для свободного ПО под GPL это, однако, никакого значения не имеет. У коммерческих потребителей будут проблемы, да. Хотя это они ещё сначала должны прикинуть, что выгоднее - писать бесплатно на чистой жабе или потратить деньги на лицензию Qt, но и сэкономить на времени разработки и получить более качественный продукт. Ну и от стоимости всё будет зависеть, конечно же.

SWT и Swing - непростительные тормоза. Непростительные буквально. В Windows это ещё не очень заметно, в Unix же на приличной машине они перегружают X настолько, что их даже программным продуктом назвать нельзя - больше, чем на грубый прототип они не тянут. У меня например при запуске Azureus становится невозможно играть в Vavoom и смотреть видео из-за лагов, хотя тот всего лишь отображает прогресс закачки с помощью SWT! Qt же помимо переносимости всегда славился и быстродействием, а поскольку в Qt Jambi основная библиотека всё та же, на C++, то работает оно так же резво. Вроде в SWT идея та же, но разница почему-то очень заметная.

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

А вот декстопные приложения, особенно свободные, на Java - дерьмо, все, что я видел. Ни одним пользоваться не смог, либо тормозит, либо глючит (доходит вплоть до того, что с левой жабой - работает, а с официальным релизом - не хочет), либо просто есть более вменяемые аналоги. Но вообще-то потенциал тут в жабу заложен нехилый, просто реализовать его в силу ряда причин (одна из них - невероятная тормознутость графики) не получается. И тут вдруг появляется возможность присоединить к жабе мощь Qt! Вернее наоборот ^_^

Если бы ещё Sun опомнился и сделал жабу хотя бы наполовину такой же переносимой, как Qt (читай: чтобы нормально шло под Unix в широком смысле ^_^) - уже был бы приличный продукт, а не универсальный микроскоп для забивания корпоративных гвоздей.

Мне кажется, что Тролли это и хотят - спихнуть Жабу и ДотНет с рынка как можно дальше. Надеюсь, что у них получится.

Даже представить страшно ...
Java сама не самолёт, Qt тоде не реактивная, что даст смесь этих йадов ...

Преимущество жабы над всем, что есть на сегодняшний день в том, что .jar созданный на стандартном Sunовском или IBMовском JDK (использовать другой, без необходимости считается плохим тоном) запустится без проблем на любой JVM (или у меня не те .jar? :-). А если JVM у вас нет, то всё, что вам потребуется, - прогуляться на java.sun.com и скачать её оттуда (это касательно windows, к линям в дистры и так сановский jvm укладывается).  

И до тех пор, пока Jampi или SWT не войдут в стандартную поставку JVM (сертифицированную Sun), нормальные жаба программисты не будут использовать.
IBM для продвижения swt уже сделал не мало, но используется он лишь в виде базы для JFace/Eclipse. Так вот для создания RCP намного более привлекателен уже готовый Eclipse RCP.

А Jambi где использовать? Красивые десктопы писать хотите? На Qt и Java? Так по памяти всё= пролетите при использовании хотя бы одного класса. Без JVM никуда не деться. И десктоп приложение, на Qt жрущее +50 метров (использовать один класс - смешно и всё= 30 метров) просто так, юзер не оценит.

Qt - прекрасный фрэймворк для С++ программиста, значитально упрощающий разработку GUI и смежные задачи. И необходимость вязать к нему "мощь Java" (кстати, в чем же она, кроме простоты и кросплатформенности) не существует просто потому, что в Qt это и так уже всё сделано.

ЗЫ: Azareus построен на древнем Eclipse RCP 3.0 (там тормоза вообще везде и никуда от них не денешься), но это проблема Azareus и только. Давно уже есть более совершенный Eclipse.

ЗЫ2: Listener в Java не встроены, это вообще интерфейсы по 10 строчек каждый. В Java реализован чистый ООП и внутренние классы с интерфейсами, которые позволяют реализовывать паттерны значительно проще, чем где либо. Listener всего лишь реализация MVC модели, на котором построен Swing.

ЗЫ3: по поводу десктопов: есть две красивых кросплатформенных штуковины, которые я использую в повседневной жизни: OpenOffice2(03) и Eclipse 3.1/2. Чем они тормознуты?

по поводу OpenOffice (именно ooo у меня professional 203 от инфраресурса)
1) есть в OpenOffice фолдер /program/classes а там лежит много .jar и судя по размеру и названиям там куча логики
2) размер soffice.bin в памяти после запуска ни о чём не говорит?
3) ooo есть свободный расширенный com.sun.staroffice.
а то, что у него там куча dll, это похоже оптимизаторы вкрученной в soffice.bin jvm через JNI механизм. Так что с++ там постольку поскольку.

по поводу eclipse:
под линём работает товарищ anli насколько я понимаю. http://prog.org.ru/forum/lhtopic_384_0_0_asc_.html

по поводу кроссплатформенности:
C++ может и переносим, но принцип write once - run anywhere ни к одному приложению C++ не применим по определению. К тому же переносимость обеспечивается за счёт работы с одними и теми же (или совместимыми) либами crt,qt. Иначе придётся код править. И при использовании JNI в Java классы тоже перестают быть кросплатформенными.

по поводу стандартной библиотеки:
проект apache.jakarta штука, конечно, хорошая, и стандартная библиотека конечно не ограниченная, но ни то ни другое совсем не обширны. Стандартная библиотека очень хорошо укомплектована самыми нужными прикладнику инструментами(а вовсе не перегружена).  И нескоро ещё количество библиотек для Java покроют то, что было создано для C++ за (кажется 30 лет?). Касательно java.math.(Поэтому сравнивать Java и Qt  вообще некорректно)

Qt позволяет писать прикладное ПО на С++ с той же простотой, что и на java(имхо). В книжке Ж.Бланшет сказано, что C++ нравится программистам, судя по-всему, именно за это. Использование сигнал-слотов вместо листенера не даёт никаких преимуществ, и похоже нацелено на более мягкий переход к Java у Qt программистов (MVC всё-таки паттерн) а сигнал-слот - замена колбэку. А работать с  двумя разными механизма работы с контролами в одном коде... это ведь и патологию головы вызвать может.

По поводу .jar:
если у меня не виндовс, то у меня линь десктопный, макос или юникс от IBM,Sun или HP, в конце-концов нетварь какая-нибудь (даже у нас в режимных организациях именно так, фри нигде нету кроме как на серваках). Европейский рынок  ориентирован на пользователя, а не на windows или админов. Отсутствие дистрибутивов jvm для FreeBSD от Sun лишнее тому подтверждение. А FreeBSD может и третья по распространённости, но только в снг  у людей, близких к IT-сфере.  И никто среди производителей JVM(Sun,IBM,Intel,BEA) .jar выкидывать не собирается. Кстати, под нетварь Qt есть? :-)

по поводу простоты: Java значительно куда более проста для понимания (не сложнее паскаля 5.5, с более ранним не работал), чем C++ который до конца, наверно, не знает никто. А питон... он же даже не компилятор?

Итого: на Jambi должно быть сделано что-то толстое и очень вкусное, чтобы всем нравилось и заставило-таки работать с Jambi, либо его должен признать Sun и упаковать в jvm. Иначе распространения она не получит. Использовать же Java из qtшного ПО.. да, круто, но не более. Излишняя трате ресурсов и проблемы при отладке С++ в паре с Java. И вообще, как выглядит прикладная задача на Java, которую нельзя сделать на С++ и Qt?

придётся отказаться от исследования FreeBSD... на ней нет Java. Кстати, а не пробовали привернуть  JVM от соляриса или линукса? Чем они отличаются-то? JVM 6.0 Sun планирует выложить в opensource, наверно тогда под фрю сделают нормальный JVM.