Вы начинаете миграцию проекта Swing на JavaFX [закрыто]

У меня есть 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
• Это зрелый и проверенный, гораздо больше, чем 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.

(Например, сортируемая древовидная таблица), я начинаю испытывать трудности при заполнении запросов. Это правда, особенно если вокруг проекта SwingX не ведется активная разработка.

• не правда, опять этот проект жив,

• Blablabla однажды, когда SwingX потерял гранты от Sun (во время приобретения Oracle), люди из SwingX пошли на создание JavaFX

Кроме того, я вряд ли смогу найти что-то хорошее, но в то же время активно поддерживаемый / развивающийся / развивающийся графический интерфейс Java.

• нет Swing не о Framework, но о внешнем виде

• Фреймворки предназначены для нетехнических пользователей (MsAccess может быть лучшим примером для GUI Framework)

• но если вы хотите создать реальное приложение, у вас есть глубокие знания о Swing, и переопределение также пришло из Framework,

• забавный пример Netbeans имеет встроенную Swing Framework, основанную на JSR296, но там не может изменить значок JFrames напрямую,

Вы начали мигрировать ваш проект Swing в гораздо более активную инфраструктуру GUI, такую ​​как JavaFX?

нет причин, почему

• То же самое с миграцией на Java7, может быть, когда будет Java7.15 - 17

• Я сравниваю JavaFx с Nimbus, разработка закончилась / сдалась где-то в первой половине

• извините, я не разработчик, я только Java & Swing Fan