У меня есть 4-летний проект, который написан на Swing + SwingX. В настоящее время это все еще живо и все еще пинает.
Однако, когда поступает больше запросов, связанных с графическим интерфейсом (например, таблица сортируемого дерева), я начинаю ощущать трудности при заполнении запросов. Это верно, особенно если учесть, что вокруг проекта SwingX не ведется активная разработка.
Кроме того, я едва ли могу найти какую-либо хорошую, но активно поддерживаемую / разрабатываемую / развивающуюся инфраструктуру Java с графическим интерфейсом.
Мне было интересно, кто-нибудь из разработчиков Swing чувствует то же самое? Вы начали мигрировать ваш проект Swing в гораздо более активно разработанную среду графического интерфейса, такую как JavaFX?
Ответы:
Я лично перехожу на JavaFX (2.1+, а не старая странная версия 1.x с неприятным языком сценариев). Новый JavaFX не идеален на 100%, но он уже чертовски приятен в использовании, чем Swing, я вижу для него разумное будущее (особенно учитывая встроенный движок Webkit).
источник
Я часто спрашиваю себя об одном и том же, но не думаю, что перенесу существующие проекты в JavaFX. По крайней мере, пока, и не для средних и крупных проектов. Однако я бы рассмотрел JavaFX для новых проектов и снова рассмотрел вопрос о миграции в будущем и переоценил вопрос, основываясь на прогрессе JavaFX.
На данный момент мои опасения:
Незрелость
Да, скоро мы выйдем на 3.0, но это не было так долго, и все еще претерпел серьезные изменения. Так что для крупных и не склонных к риску корпоративных программ это довольно болезненное место.
Производительность
Я не видел достаточно точных данных о различиях в производительности.
Виджеты и Компоненты
Я не видел достаточного усиления в новых компонентах. Я думаю, это может быть связано с незрелостью. Я также пока не знаю, насколько хорошо они могут быть расширены и объединены, в отличие от Swing.
В целом, я предполагаю, что точные данные о преимуществах - это то, чего мне не хватает, чтобы полностью убедиться в JavaFX.
С другой стороны, Swing проверен и проверен. Да, API неуклюж и вызывает автоматическое завершение в вашей IDE для объекта Swing, такого как JTextPane, заставит его плакать и плакать о его мамочке, но, если вы достаточно осведомлены, вы можете создавать удивительные интерфейсы с Swing, что работают хорошо (я никогда не покупал ошибку Swing-имеет-плохую производительность, см. бывшие сообщения Романа Гая в блогах Sun) и позволяю вам делать довольно аккуратные вещи.
Поэтому, прежде чем что-то переключать, я бы порекомендовал вам сначала попробовать небольшой прототип, и, возможно, попытаться портировать некоторые из диалогов вашего приложения и посмотреть, как они работают.
источник
Я много занимался JavaFX и предпочитаю Swing. Структура Scene Graph отличается от того, к чему вы привыкли в Swing, но она обеспечивает так много улучшений. С API приятно работать, он выглядит освежающим.
Вы можете сделать с ней гораздо больше: мультимедиа, анимация, просмотр веб-страниц. Например, вы можете создать приложение Google Maps из нескольких строк кода, встраивая html5 и javascript.
Говорят, что он включен в среду выполнения Java 8, что будет означать определенную замену Swing в качестве структуры пользовательского интерфейса по умолчанию.
@ Миграция. Начать следует с выделения частей приложения, которые можно преобразовать в JavaFX. Взаимодействие Swing-JavaFX 2 - это большая вещь, вы можете использовать javafx.embed.swing.JFXPanel для встраивания вашего элемента JavaFX. Смотрите Swing-FX-совместимость . (Для полноты вы также можете встроить в SWT.)
источник
Swing становится устаревшей технологией или уже есть. Тем не менее, это довольно хорошо в том, что он делает, и не уходит в обозримом будущем, поэтому я не вижу причин от него уходить, особенно если кто-то уже вложил в него средства. JIDE Software делает хорошие (коммерческие) компоненты Swing, чтобы заменить то, что отсутствует в стандартном Swing. Например, сортируемые древовидные таблицы находятся в их сетках из коробки.
источник
Хотя новые версии JavaFX выглядят очень впечатляюще, я сомневаюсь, что стоит выполнить полную миграцию, если вы не готовы вкладывать много времени / усилий / денег в полный пересмотр графического интерфейса.
У свинга могут быть свои причуды, и он показывает свой возраст, но он также имеет некоторые преимущества:
В конечном счете, если это не сломано, зачем это чинить?
Конечно, для нового проекта я бы очень серьезно посмотрел на JavaFX, Android и / или веб-интерфейс (возможно, с чем-то вроде Vaadin).
источник
Я нахожусь в той же позиции, что и OP - у меня есть устаревшие свинг-приложения, но мне нужно реализовать новые идиомы и интерфейсы, которые он изначально не поддерживает. Самое большое из этих приложений было реорганизовано несколько раз по разным причинам (улучшение модульности, улучшение MVC и структуры диспетчеризации событий и т. Д.), Поэтому я не совсем против переписывания кода пользовательского интерфейса. Так что я долго думал над этим вопросом.
Тем не менее, некоторые вещи не могут быть решены с помощью Swing без больших затрат времени и усилий на то, что по сути является устаревшей технологией. Например, кроме простых событий мыши, новых устройств с сенсорным экраном и не поддерживается самим Swing. Предоставление компонента браузера на основе Swing аналогично хлопотно или дорого, и в моем случае подход javafx-in-swing не является вариантом, так как он усложняет обработку событий пользовательского интерфейса нетривиальными способами.
Я думаю, что он был старым и верным в свое время, и если ваша платформа так же неизменна, как и ваша кодовая база - придерживайтесь ее, очевидно. Но для того, чтобы приложение перешло в новые, более современные варианты использования, JavaFX 2+, вероятно, будет способом продвижения вперед в моем случае.
В качестве дополнительного примечания: единственное неверное решение в Swing, которое я бы хотел, чтобы он исчез в jfx, но не сделал этого, - это подход «один поток для правила их всех» при отправке событий пользовательского интерфейса. Любой нетривиальный пользовательский интерфейс нуждается в многопоточности, чтобы пользовательский интерфейс был четким и отзывчивым, а оставление приложения одним и тем же способом легко преодолевать те же ловушки - недостаток в API IMHO.
источник
Я имел большой опыт использования RCP в больших настольных приложениях. В основном это началось как абстракция уровня графического интерфейса Eclipse и с тех пор прошло долгий путь. Вместо Swing, основанного на AWT, RCP основывается на JFace, который, в свою очередь, основан на SWT. Он позволяет разрабатывать приложения и использовать концепции графического интерфейса, которые использует сам Eclipse (представления, редакторы, перспективы, мастера и т. Д.). Он очень масштабируемый и, как и само Eclipse, постоянно совершенствуется.
Однако я никогда не переносил существующий проект из Swing в RCP; Я полагаю, что потребуется много времени, чтобы обернуть голову вокруг различных парадигм, и, если вы плохо разделите модель и просмотрите слои, вам непременно придется испытать трудности. Но поскольку вы спрашивали о таких вещах, как таблицы сортируемых деревьев, RCP отлично справляется с этим.
Если вы хотите еще раз повторить это, вы можете попробовать учебник Ларса Фогеля или взглянуть на некоторые примеры проектов с открытым исходным кодом или коммерческих проектов , использующих RCP.
источник
не правда, опять этот проект жив,
Blablabla однажды, когда SwingX потерял гранты от Sun (во время приобретения Oracle), люди из SwingX пошли на создание JavaFX
нет Swing не о Framework, но о внешнем виде
Фреймворки предназначены для нетехнических пользователей (MsAccess может быть лучшим примером для GUI Framework)
но если вы хотите создать реальное приложение, у вас есть глубокие знания о Swing, и переопределение также пришло из Framework,
забавный пример Netbeans имеет встроенную Swing Framework, основанную на JSR296, но там не может изменить значок JFrames напрямую,
нет причин, почему
То же самое с миграцией на Java7, может быть, когда будет Java7.15 - 17
Я сравниваю JavaFx с Nimbus, разработка закончилась / сдалась где-то в первой половине
извините, я не разработчик, я только Java & Swing Fan
источник