Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
этого следовало ожидать — java уходит с десктопа потихоньку, к сожалению.
Почему же? А как же SWT?
Да и к тому же JavaFX гораздо перспективнее Swing'a выглядит, в том числе и на десктопах.
Да и к тому же JavaFX гораздо перспективнее Swing'a выглядит, в том числе и на десктопах.
SWT отходит немного от идеологии кроссплатформенности и управляемого кода.
+1, кроме того я очень редко, да практически два раза за 10 лет в нише, работал с эклипсовскими фичами. В продакшн их боятся вставлять.
В чём это, по Вашему, выражается, уточните?
en.wikipedia.org/wiki/Standard_Widget_Toolkit
«SWT widgets, unlike almost any other Java toolkit, requires manual object deallocation, as opposed to the standard Java practice of automatic garbage collection. SWT objects must be explicitly deallocated using the ».dispose()" function, which is analogous to the C language's «free».[14] If this is not done, memory leaks or other unintended behavior may result."
«SWT is written in Java. To display GUI elements, the SWT implementation accesses the native GUI libraries of the operating system using JNI (Java Native Interface) in a manner that is similar to those programs written using operating system-specific APIs. Programs that call SWT are portable, but the implementation of the toolkit, despite the fact that it is written in Java, is unique for each platform.»
«SWT widgets, unlike almost any other Java toolkit, requires manual object deallocation, as opposed to the standard Java practice of automatic garbage collection. SWT objects must be explicitly deallocated using the ».dispose()" function, which is analogous to the C language's «free».[14] If this is not done, memory leaks or other unintended behavior may result."
«SWT is written in Java. To display GUI elements, the SWT implementation accesses the native GUI libraries of the operating system using JNI (Java Native Interface) in a manner that is similar to those programs written using operating system-specific APIs. Programs that call SWT are portable, but the implementation of the toolkit, despite the fact that it is written in Java, is unique for each platform.»
С первым ещё как-то соглашусь, а вот со вторым — нет: Swing тоже имеет native часть.
Самое большое отличие Swing'a и SWT в том, что SWT более тонко интегрируется в OS, соответственно тут вы получаете некоторые плюсы в частности интерфейс выглядит в едином стиле с OS, в винде все кнопки и свойства окон будут вточь вточь такие же. Минусы этого подхода в том, что надо сохранить платформо-независимость. А это значит, что нельзя давать доступ к примеру winapi циклу, т.к. под тем же юниксом, другие принципы отрисовки интерфейсов.(в частности нельзя удалить элетемент, без пересоздания окна, или встанить новый элемент, все должно быть сделано до отрисовки окна). ИМХО подход SWT более жизнеспособный, но зато возникают проблемы с платформенно-независимостью(для разработчиков библиотеки).
Ну и согласитесь, Swing выглядит весьма убого, с учетом, что многие уже давно сидят в винде на Aero, и даже look and feel библиотеки не сильно тут помогают. Плюс недавно вышел новый стандарт OsGi bundle.
Ну и согласитесь, Swing выглядит весьма убого, с учетом, что многие уже давно сидят в винде на Aero, и даже look and feel библиотеки не сильно тут помогают. Плюс недавно вышел новый стандарт OsGi bundle.
Нынешних возможностей Java уже вполне достаточно для создания десктопных приложений разной степени наворочености, нужно лишь уметь готовить. Как показывет практика работы в коммерческом проекте с функционально богатой десктопной частью, тянущегося еще с ранних версий Java, вполне посильная задача придать приложению самый современный вид пользуясь богатыми наработками open-source сообщества без необходимости переписывать весь интерфейс на корню. Могут ли этим похвастаться приложения на других языках которые начинали писать лет 5 назад, а то и больше? Принципы, изначально заложенные в swing, дают очень широкие возможности разработчикам сторонних библиотек, даже без поддержки Sun/Oracle.
да-да, я помню как такие же говорили лет 10 назад мне, что винт на 40 гигов мне хватит навечно и заполнить будет нечем. Любой продукт в IT сфере, не развиваясь, быстро устаревает. Винформс вот тоже устарели, хотя их и развивают, жить им уже не так долго.
Разумеется не развиваясь устаревает, я не спорю, но ведь я о том, что околосвинговая флора успешно развивается, а судьба одного проекта не показательна еще, истерия топика искусственна. С WinForms я бы не сравнивал, от него изначально Delphi VCL веяло, совсем другие принципы, и судьба последнего уже кажется ясна…
ну почему сразу истерия, уход в веб это не так уж плохо. Когда состоится сделка с ораклом, судьба десктопной платформы будет точно известна уже (а ораклу десктоп нафиг не нужен:). JavaFX, кстати, тоже как слабо развивается. А вот JavaEE развивать явно будут.
ps винформс это к тому, что устаревае все со временем. Опенсорсное сообщество не вытянет развитие десктопной платформы без санок. (свит не в счет)
ps винформс это к тому, что устаревае все со временем. Опенсорсное сообщество не вытянет развитие десктопной платформы без санок. (свит не в счет)
QtJambi рулит =)
Да декстопе джавы не так уж и много кстати. В основном это или IDE или какие то специализированые приложения типа CADов или навроде Матлаба. Основная её ниша это Enterprise системы.
Кто-бы сомневался. На GUI реализованное средствами java без слез не взглянешь. Оно быть может и функционально. Но пользоваться им можно только там, где нужна функциональность и можно не обращать внимание на внешний вид и интеграцию в ОС. Кстати, Eclips весьма радует в этом смысле, но он вроде для каждой ОС юзает нативные библиотеки?
Я кагбы без наездов, я так это вижу.
Я кагбы без наездов, я так это вижу.
Используйте подходящий Look and Feel (Например, Quaqua: www.randelshofer.ch/quaqua) и всё будет красиво.
это ужасно.
Вот так вот получаются сенсации для новостей…
Swing Application Framework — это не Swing. SAF является надстройкой над Swing, позволяющей делать некоторые вещи несколько проще. Например, указывать параметры компонентов в property-файле, объявлять команды (actions) аннотированием метода и т. п.
Далеко не все Swing-приложения используют этот фреймворк.
Swing, в свою очередь, вполне жив и пока умирать не собирается.
Swing Application Framework — это не Swing. SAF является надстройкой над Swing, позволяющей делать некоторые вещи несколько проще. Например, указывать параметры компонентов в property-файле, объявлять команды (actions) аннотированием метода и т. п.
Далеко не все Swing-приложения используют этот фреймворк.
Swing, в свою очередь, вполне жив и пока умирать не собирается.
Ну на мой взгляд, текущее его состояние сложно назвать жизнью, это больше похоже на существование.
Я не хочу вступать с Вами в дискуссию на тему Swing rokzz/Swing suxx.
Однако, было бы здорово, если бы Вы либо убрали фразу "[...] новость, означающую его смерть", либо эту фразу обосновали.
Однако, было бы здорово, если бы Вы либо убрали фразу "[...] новость, означающую его смерть", либо эту фразу обосновали.
Оно прекратило над ним работу, в том виде как это осуществлялось и планировалось. Многое будет переработано. И вряд ли это можно будет считать первозданным SAF.
Готов изменить название на дословный перевод, если это всех будет устраивать.
Спасибо, я исправил. Несколько импульсивное название было вызвано большими ожиданиями от SAF, а тут такие новости. Неприятно.
А через сколько веков будет Java 8? Это как смерть для массового использования.
интриги, скандалы, расследования.
тут уже были одни с заголовком «java стала платной» по поводу коммерческой поддержки G1. кричали упорно, пока Sun сама не сказала обратного.
теперь вот Swing похоронили.
внимательнее надо быть, товарищ (:
тут уже были одни с заголовком «java стала платной» по поводу коммерческой поддержки G1. кричали упорно, пока Sun сама не сказала обратного.
теперь вот Swing похоронили.
внимательнее надо быть, товарищ (:
*опять придирки к названию*
Как-то не ложится на душу «Sun убрало».
Как-то не ложится на душу «Sun убрало».
Нельзя делать выводы, что Sun забили на Swing — а как же NetBeans Platform? Да и при работе над JavaFX было множество улучшений для платформы сделано.
Что касается Java GUI — то тут кроме Eclipse RCP стоит отметить ещё Griffon.
Что касается Java GUI — то тут кроме Eclipse RCP стоит отметить ещё Griffon.
Блин, ну не надо так-то пугать! Куда Java без Swing-a? Как NetBeans без него будет работать? А тысячи апликаций и аплетов? Swing Application Framework — это отдельный проект из инкубатора, который предоставляет некоторые шаблоны для создания декстопной апликации. Swing никто не собирается убирать. Тот же JavaFX использует под собой Java2D/Swing. И вообще без Swing Java остается без GUI (разве что бедный AWT)
Вместе с тем, направление Swing довольно бесперспективное. Различные сторонние библиотеки виджетов (напр. QT) уже превзошли по скорости, функционалу и простоте использования. Swing наполовину дохлый. Но убрать его никто не собирается.
Вместе с тем, направление Swing довольно бесперспективное. Различные сторонние библиотеки виджетов (напр. QT) уже превзошли по скорости, функционалу и простоте использования. Swing наполовину дохлый. Но убрать его никто не собирается.
Случаем не подскажите — порт QT на Java и правда работает быстрее swing?
Просто развиваю хороший проект на swing, это для меня довольно критично.
А вообще, если грамотно продумать интерфейс и работу, то медленности можно психологически свести к минимуму. Просто надо реализовать так, чтобы программа делала вычисления в моменты пользовательской неактивности.
Например, критично, когда после клика на кнопке прога подвисает дольше пол-секунды (создание нового окошка с уймой компонентов, и т.п.)
Но если подгрузить нужное заранее, и по клику лишь вывести графически, то создается иллюзия скорости.
Просто развиваю хороший проект на swing, это для меня довольно критично.
А вообще, если грамотно продумать интерфейс и работу, то медленности можно психологически свести к минимуму. Просто надо реализовать так, чтобы программа делала вычисления в моменты пользовательской неактивности.
Например, критично, когда после клика на кнопке прога подвисает дольше пол-секунды (создание нового окошка с уймой компонентов, и т.п.)
Но если подгрузить нужное заранее, и по клику лишь вывести графически, то создается иллюзия скорости.
Nokia прекратила официальную разработку Qt-Jambi, так как бросила силы на более перспективные разработки, и отдала его на откуп сообществу, поэтому лучше или полностью на Qt перейти, который по понятным причинам быстрее любого джавовского UI и при этом нативен в каждой из систем или остаться полностью на джаве. А вот гибрид как то не очень жизнеспособен оказался.
Кстати этот же рецепт годится для любого графического фреймворка, кеширование творит чудеса
Кстати этот же рецепт годится для любого графического фреймворка, кеширование творит чудеса
Тот факт, что QtJambi отныне будет развивать только сообщество ещё не убивает сам QtJambi. Так что он ещё жив.
> А вот гибрид как то не очень жизнеспособен оказался.
Вот в этом месте по подробнее, плиз, если речь не только о том, что не-open source версию QtJambi закрыли.
> А вот гибрид как то не очень жизнеспособен оказался.
Вот в этом месте по подробнее, плиз, если речь не только о том, что не-open source версию QtJambi закрыли.
Ну в общем то о том самом :) Ибо я на яве не пишу, а пользуюсь самым что ни на есть родным для Qt C++
Ну а ежели сообщество справится, то отлично, но может и так выйти что Джамби будет потихоньку умирать, отставая от мейнстрима все сильнее и сильнее. Посмотрите например на то, что творится в QtD, идеи хорошие, а вот не поспевают.
Ну а ежели сообщество справится, то отлично, но может и так выйти что Джамби будет потихоньку умирать, отставая от мейнстрима все сильнее и сильнее. Посмотрите например на то, что творится в QtD, идеи хорошие, а вот не поспевают.
Если вы про QT на C++, то по понятным причинам быстрее.
А если порт QT на java — не совсем ясно, почему.
Если можно, поподробнее? Другая архитектура?
А если порт QT на java — не совсем ясно, почему.
Если можно, поподробнее? Другая архитектура?
Ну ясно дело, что Qt будет рисовать с одной скоростью виджеты, будь то родная C++ прога или любой из биндингов
Так может qt на java-машине будет по скорости даже медленнее swing?
Будь порт swing на C++, думаю, может он бы мог сравниться по скорости с QT
Будь порт swing на C++, думаю, может он бы мог сравниться по скорости с QT
Если бы я знал, как там все взаимодействует ответил бы на вопрос, а я только примерно представляю, как Qt это дело рисует, там есть бэкенды, так называемые графические системы и при переносе на новую платформу пишется бэкенд под неё, а после дергается родной для платформы движек стилей. В джаве с этим проблематично, она идеологически не слишком приемлет нативные вызовы
Зацените сами:
dist.trolltech.com/developer/download/webstart/index.html
Мои проекты тоже на Swing вертятся. Скорость вроде бы удовлетворительная.
dist.trolltech.com/developer/download/webstart/index.html
Мои проекты тоже на Swing вертятся. Скорость вроде бы удовлетворительная.
Мммде, слышу звон да не знаю где он…
Никто на свинг не забивал.
openjdk.java.net/projects/jdk7/features/
Nimbus look-and-feel for Swing — A next-generation cross-platform look-and-feel for Swing.
Swing updates — Small additions to the Swing API including the JXLayer component decorator, JXDatePicker, and possibly CSS-based styling.
Фреймворка не будет… пока. Но некоторые апдейты всёже будут. Плюс Нимбус — клёвый look'n'feel.
openjdk.java.net/projects/jdk7/features/
Nimbus look-and-feel for Swing — A next-generation cross-platform look-and-feel for Swing.
Swing updates — Small additions to the Swing API including the JXLayer component decorator, JXDatePicker, and possibly CSS-based styling.
Фреймворка не будет… пока. Но некоторые апдейты всёже будут. Плюс Нимбус — клёвый look'n'feel.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Sun убрало Swing Application Framework из Java 7