Почнете міграцію вашого проекту Swing на JavaFX [закрито]

У мене є 4-річний проект, який написаний Swing + SwingX. Наразі він ще живий і все ще б'є.

Однак, оскільки надходить більше запитів щодо функцій, пов'язаних з графічним інтерфейсом (наприклад, таблиця сортувального дерева), я починаю відчувати труднощі при заповненні запитів. Це вірно, тим більше, що не існує жодної активної розробки навколо проекту SwingX.

Крім того, я навряд чи зможу знайти якісь хороші, але активно підтримувані / розроблені / розвиваються GUI 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-has-bad-performance, дивіться колишні повідомлення блогу Ромена Гая в блогах Sun) і дозволяють вам робити досить акуратні речі.

Отже, перш ніж щось перемикати, я рекомендую спершу спробувати невеликий прототип, а можливо, спробуйте перенести деякі діалоги ваших програм і подивитися, як це відбувається.

Зараз я багато займаюся JavaFX і віддаю перевагу Swing. Структура графіка сцени відрізняється від звичної для Swing, але вона забезпечує стільки вдосконалень. З API цікаво працювати, він відчуває себе освіжаючим.

Тут можна зробити набагато більше мультимедіа, анімації, веб-перегляду. Наприклад, ви можете створити додаток Google Maps з кількох рядків коду, вбудувавши html5 та javascript.

Кажуть, що вона включена в час виконання Java 8, що означатиме заміну заміни Swing як рамки ui за замовчуванням

@Migration : Ви повинні почати з ізоляції частин програми, які можна перетворити на JavaFX. Інтеграбельність Swing-JavaFX 2 - це велика річ, ви можете використовувати javafx.embed.swing.JFXPanel для вбудовування вашого елемента JavaFX. Дивіться функцію взаємодії суміші swing-fx . (Для повноти можна також вбудувати SWT.)

Гойдалка стає старою технологією, або вже є. Однак, це дуже добре в тому, що він робить, і не відмирає в будь-якому передбачуваному майбутньому, тому я не бачу причин відходити від нього, особливо якщо хтось уже вклав у це. Програмне забезпечення JIDE робить хороші (комерційні) компоненти Swing, щоб замінити те, що не вистачає у стандартних Swing. Наприклад, сортування дерев для сортування є в їх сітках поза коробкою.

Хоча нові версії JavaFX виглядають дуже вражаюче, я сумніваюся, що варто зробити повну міграцію, якщо ви не готові вкласти багато часу / зусиль / грошей на повний капітальний ремонт графічного інтерфейсу.

Гойдалка може мати свої химерності і показує свій вік, але також має деякі переваги:

• Дуже сильна міжплатформна здатність, на даний момент набагато краща, ніж JavaFX
• Він зрілий і перевірений, набагато більше, ніж JavaFX
• Він має велику екологічну спільноту користувачів / бібліотеку
• Напевно ви вже маєте багато навичок Swing або можете найняти людей з ними легко

Зрештою, якщо вона не зламана, навіщо це виправляти?

Звичайно, для нового проекту я б дуже серйозно дивився на JavaFX, Android та / або веб-інтерфейс GUI (можливо, з чимось на кшталт Vaadin).

Я перебуваю на тій же позиції, що і в ОП - маючи застарілі програми для перекладу, але потрібно впроваджувати нові ідіоми та інтерфейси, які вони не підтримують. Найбільша з цих програм кілька разів була відремонтована з різних причин (покращити модульність, покращити структуру відправлення MVC та події тощо), тому я не зовсім проти переписувати код інтерфейсу. Тому я довго і наполегливо думав над цим питанням.

Однак деякі речі неможливо вирішити за допомогою Swing, не вкладаючи багато більше часу та зусиль на те, що по суті є застарілою технологією. Наприклад, окрім простих подій миші, нові пристрої з сенсорним екраном і їх не підтримує сам Swing. Надання компонента браузера на базі Swing аналогічно клопітно чи дорого, і в моєму випадку підхід javafx-in-swing не є варіантом, оскільки ускладнює обробку подій інтерфейсу користувача нетривіальними способами.

Я думаю, що він був старим і вірним свого часу, і якщо ваша платформа настільки ж незмінна, як і ваша база коду - очевидно, дотримуйтесь її. Але для того, щоб програма рухалася вперед до нових більш сучасних випадків використання, в моєму випадку, можливо, JavaFX 2+, можливо, буде рухатися вперед.

Як зауваження: одна зловживань у Swing, яку я хотів би зникнути в jfx - але ні, - це підхід "єдиний порядок до управління ними" для відправки подій у всіх інтерфейсах. Будь-який нетривіальний користувальницький інтерфейс потребує багаторівневої нарізки, щоб підтримувати інтерфейс користувача чітким та чуйним, а це залишає повністю для розробника додатків, щоб наткнутися на ті самі підводні камені, що так легко є недоліком API IMHO.

Я мав великий досвід використання RCP у великих настільних додатках. В основному він почався як абстрагування графічного інтерфейсу Eclipse, і з того часу пройшов довгий шлях. Замість Swing, який базується на AWT, RCP будує на JFace, який, у свою чергу, базується на SWT. Це дозволяє розробляти додатки та використовувати GUI-концепції, які використовує сам Eclipse (погляди, редактори, перспективи, майстри тощо). Це дуже масштабовано і, як і сам Eclipse, постійно вдосконалюється.

Однак я ніколи не мігрував існуючий проект із Swing на RCP; Я можу уявити, що пройде довгий час, щоб обернути голову навколо різних парадигм, і якщо ви не відокремили свою модель і добре переглянете шари, вам, мабуть, важко. Але оскільки ви запитували про такі речі, як сортовані таблиці дерев, RCP чудово підходить до цього.

Якщо ви хочете ще раз переробити це, ви можете спробувати підручник Ларса Фогеля або ознайомитись із деякими прикладами проектів з відкритим кодом або комерційних проектів, які використовують RCP.

(Наприклад, сортована таблиця дерев), я починаю відчувати труднощі при заповненні запитів. Це вірно, особливо немає активних розробок навколо SwingX проекту.

• неправда, знову ж таки цей проект живий,

• колись блаблабла, коли SwingX втратив гранти Sun (під час придбання Oracle), люди від SwingX перейшли до побудованого JavaFX

Крім того, я навряд чи зможу знайти будь-який товар, але активно підтримується / розвивається / розвивається GUI Java.

• жодна гойдалка - це не рамки, а про Look and Feel

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

• але якщо ви хочете створити реальну програму, ви отримали чіткі знання про Swing та переопрацювання, які також надійшли від Framework,

• прикольний приклад Netbeans має вбудований_в Swing Framework на основі JSR296, але не в змозі безпосередньо змінити значок JFrames,

Ви почали мігрувати свій проект Swing на набагато активніше розроблений графічний інтерфейс, наприклад, JavaFX?

немає причини

• те ж саме з переходом на Java7, можливо, коли буде там Java7.15 - 17

• Я порівнюю JavaFx з Nimbus, розвиток закінчився / відмовився десь у першій половині

• Вибачте, що я не розробник, я лише Java & Swing Fan