Выходит Qt Jambi - Qt для Java

[Alqualos]

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/

[Sergey B.]

По мне Жабьи  Listeners, гораздо прозрачнее Qt сигнал - слотов...
Так как они часть языка! А не расширение, которое потом пропадает при moc обработке. Потом Swing не менее мощен чем Qt.
Потом есть же SWT. Qt уже не первая...
Во вторых, не знаю как оно пойдёт, но ведь основная беда Qt это коммерческая версия, т.е. если пишешь на java там нет никаких cost. Ставь пиши, продавай... Всё доступно.
С Qt слинковать не получиться...
Eclipse тоже есть в недрах IBM, вернее SWT обвязанная вокпуг Qt, и только несовместимость лицензий вынудила IBM отказаться от его публикования.

Так что...

[Alqualos]

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

Код:

slider.addChangeListener(new ChangeListener() {
    public void stateChanged(ChangeEvent e) {
        spinner.setValue(slider.getValue());
    }
});
spinner.addChangeListener(new ChangeListener() {
    public void stateChanged(ChangeEvent e) {
        slider.setValue((Integer)spinner.getValue());
    }
});

и

Код:

slider.valueChanged.connect(spinBox, "setValue(int)");
spinBox.valueChanged.connect(slider, "setValue(int)");

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

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

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

[Sergey B.]

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

Код:

slider.addChangeListener(new ChangeListener() {
    public void stateChanged(ChangeEvent e) {
        spinner.setValue(slider.getValue());
    }
});
spinner.addChangeListener(new ChangeListener() {
    public void stateChanged(ChangeEvent e) {
        slider.setValue((Integer)spinner.getValue());
    }
});

и

Код:

slider.valueChanged.connect(spinBox, "setValue(int)");
spinBox.valueChanged.connect(slider, "setValue(int)");

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

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

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

Я бы привёл в пример адаптеры...
а не листенеры, потом анонимные классы, позволяют избавиться от проверки условий вызова мотодов.
Код выполниться только здесь!
Всё таки Qt это десктоп библиотека, а ява больше платформа.
Потом в энтерпрайз секторе где рулит Java EE и NET всем плевать на скорость, главное стабильность и масштабируемость!
Потом Swing-application можно через java web start вызвать не как апплет, а как приложение.
Сможет ли оно подгрузить qt не знаю..
но вот SWT вроде бы не видел...
Мне кажеться места там уже заняты, и тролли не смогут потеснить M$ и java...
Лучше б занялись доводкой до ума фич новых...
Но если хотят, пусть пробуют...

добавлено спустя 3 минуты:

 Потом сектор Java уже устаканился. Есть Swing, в котором есть все навороты. SWT и та идёт с трудом, а они ведь бесплатны.
По моему, если пишешь для десктоп пиши на qt, если на заказ в компанию на java...
Потом скажем если надо юзать оракл, скажем халявный но оракл - заказчик упёрся, Qt - без коммерческой версии этого сделать не позволит, к бАльшому сожалению...

[Alqualos]

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

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

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

[Sergey B.]

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

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

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

Это точно, но вот блин беда, от этих горе java программеров, которые сейчас начнут пробовать переписывать всё через Qt, больше вреда чем пользы...
УЖ если Qt неАсилили лучшеб и не брались ...

[Racheengel]

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

[Maxz]

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

[Sergey B.]

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

http://www.trolltech.com/developer/downloads/qt/qtjambi-techpreview

[Dimchansky]

Причём Qt Jambi даёт возможность писать часть приложения на C++, а часть - на Java.

Я не очень понял. А во что это будет собираться, в какой код?

[Sergey B.]

Причём Qt Jambi даёт возможность писать часть приложения на C++, а часть - на Java.

Я не очень понял. А во что это будет собираться, в какой код?

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

[Alqualos]

Код, написанный на C++ будет собираться в родные библиотеки (so, DLL), а код, написанный на жабе, будет к ним обращаться. Точно также, как жаба обращается к классам Qt, написанным на C++.

При грамотном применении даёт очень хороший результат. Грамотное применение - это когда поменьше вызовов туда-сюда и разделение подчинено разумной логике. То есть на жабе можно писать, к примеру, высокоуровневую логику, а на C++ - высокоэффективные компоненты, например, работу с сетью, с графикой, операции, требующие грамотного использования памяти (что в жабе нереально) и т. п. В принципе жаба и так это всю жизнь позволяла через JNI (часть жабы написана на C++), но Qt Jambi это дело сильно упрощает и автоматизирует. Насколько сильно - не знаю, не пробовал.

Возможен ли обратный вариант (приложение на C++ использует библиотеку на жабе) - Хрен его знает, но сомнительно, да и зачем такой изврат?

[Orlov_O]

Преимущество жабы над всем, что есть на сегодняшний день в том, что .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. Чем они тормознуты?

[Alqualos]

прогуляться на java.sun.com и скачать её оттуда (это касательно windows...

А если у вас не Windows, то можете выкинуть этот .jar в помойку, как только поймёте, что под вашу платформу (NetBSD, OpenBSD, ...) жабы просто не существует. Это к вопросу о переносимости жабы. Под FreeBSD (наверное, 3-ю по популярности систему после Linux) она выходит, к примеру, с запозданием года на два и с большим скрипом. Хотя как надо умудриться написать приложение, чтобы оно нормально работало под Linux, но не хотело работать под FreeBSD - лично мне совсем не понятно.

Мощь жабы как раз не в кроссплатформенности (жаба гораздо менее переносима, чем C и C++, что легко проверяется экспериментально) и тем более не простоте (Где она в жабе?! Кому нужна простота, учите Python.), а в огромной стандартной библиотеке, плюс большом наборе дополнительных библиотек (Log4j и другие проекты Apache, например). Qt же, в отличие от жабы, перегруженной функциональностью не отличался особо никогда, так что там многого нет (java.math - ещё один пример).

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

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

OpenOffice2(03) - это OpenOffice.org 2? Так то C++. Хоть и тормозит почти как жаба (но всё же меньше, да).
Eclipse - вы пробовали его запустить не на Windows? Тормозов более чем достаточно. Или в 3.1 что-то сильно изменилось после 3.0 в этом смысле?

[Orlov_O]

по поводу 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.