Czy zaczynasz migrować swój projekt Swing do JavaFX [zamknięte]

Mam 4-letni projekt napisany w Swing + SwingX. Obecnie wciąż żyje i wciąż kopie.

Jednak w miarę pojawiania się kolejnych żądań funkcji związanych z GUI (na przykład sortowalna tabela drzewa), zaczynam mieć trudności z realizacją żądań. Jest to szczególnie ważne, ponieważ nie ma żadnego aktywnego rozwoju wokół projektu SwingX.

Nie mogę też znaleźć żadnego dobrego, ale aktywnie utrzymywanego / rozwijanego / rozwijającego się interfejsu GUI Java.

Zastanawiałem się, czy któryś z twórców Swinga czuje to samo? Czy zacząłeś migrować swój projekt Swing do znacznie bardziej aktywnego środowiska GUI, takiego jak JavaFX?

Osobiście przechodzę do JavaFX (2.1+, a nie do starej dziwnej wersji 1.x z nieprzyjemnym językiem skryptowym). Nowy JavaFX nie jest w 100% idealny, ale jest już o wiele bardziej przyjemny w użyciu niż Swing, widzę rozsądną przyszłość (szczególnie biorąc pod uwagę wbudowany silnik Webkit).

Często zadaję sobie to samo, ale nie sądzę, że migrowałbym istniejące projekty do JavaFX. Przynajmniej nie na razie i nie w przypadku średnich i dużych projektów. Zastanawiałbym się jednak nad JavFX dla nowych projektów i ponownie rozważę migrację w przyszłości i ponownie oceniam pytanie w oparciu o postępy JavaFX.

W tej chwili moje obawy są następujące:

• Niedojrzałość

  Tak, niedługo przejdziemy do wersji 3.0, ale nie było to tak długo i nadal przeszliśmy poważne zmiany. Tak więc w przypadku dużego oprogramowania korporacyjnego unikającego ryzyka jest to dość obolałe miejsce.

• Występ

  Nie widziałem wystarczającej ilości twardych danych na temat różnic w wydajności.

• Widżety i komponenty

  Nie widziałem wystarczającego zysku w nowych komponentach. To może dotyczyć niedojrzałości. Nie wiem też jeszcze, jak dobrze można je rozbudowywać i komponować, w przeciwieństwie do Swinga.

Ogólnie rzecz biorąc, wydaje mi się, że twarde dane na temat zalet są tym, czego brakuje mi, aby być w pełni przekonanym przez JavaFX.

Z drugiej strony Swing jest sprawdzony i przetestowany. Tak, interfejs API jest niezgrabny, a wywołanie automatycznego uzupełniania w twoim IDE na obiekcie Swing, takim jak JTextPane, spowoduje, że będzie płakać i płakać za mamusią, ale jeśli masz wystarczającą wiedzę, możesz tworzyć niesamowite interfejsy użytkownika za pomocą Swinga, osiągają dobre wyniki (nigdy nie kupiłem fałszywej wersji Swing-has-bad-performance, zobacz poprzednie posty Romaina Guy'a na blogach Sun) i pozwalają robić całkiem fajne rzeczy.

Przed przełączeniem czegokolwiek poleciłbym najpierw wypróbować mały prototyp i być może spróbować przenieść niektóre okna dialogowe aplikacji i zobaczyć, jak to działa.

Robiłem dużo JavaFX i wolę to niż Swing. Struktura wykresu scen różni się od tego, do czego przywykłeś w Swing, ale zapewnia wiele ulepszeń. Interfejs API jest przyjemny w obsłudze, wydaje się odświeżający.

Jest o wiele więcej do zrobienia, multimedia, animacje, przeglądanie stron internetowych. Możesz na przykład zbudować aplikację Google Maps w kilku wierszach kodu, osadzając HTML5 i JavaScript.

Mówi się, że jest zawarty w środowisku wykonawczym Java 8, co oznaczałoby zastąpienie Swing jako domyślnej struktury interfejsu użytkownika

@Migracja : Rozpocznij od izolacji części aplikacji, które można przekonwertować na JavaFX. Współdziałanie Swing-JavaFX 2 to wielka sprawa, możesz użyć javafx.embed.swing.JFXPanel, aby osadzić swój element JavaFX. Zobacz interoperacyjność swing-fx . (Dla kompletności możesz również osadzić w SWT).

Swing staje się starszą technologią lub już jest. Jest jednak całkiem dobry w tym, co robi i nie odchodzi w żadnej dającej się przewidzieć przyszłości, więc nie widzę powodu, by się od niego odchodzić, zwłaszcza jeśli ktoś już w to zainwestował. Oprogramowanie JIDE tworzy dobre (komercyjne) komponenty Swing, które zastępują to, czego brakuje w standardowym Swing. Na przykład sortowalny treetable jest w ich siatkach po wyjęciu z pudełka.

Podczas gdy nowe wersje JavaFX wyglądają bardzo imponująco, wątpię, że warto przeprowadzić pełną migrację, chyba że jesteś gotów zainwestować dużo czasu / wysiłku / pieniędzy w całkowity przegląd GUI.

Swing może mieć swoje dziwactwa i pokazuje swój wiek, ale ma również pewne zalety:

• Bardzo silne możliwości obsługi wielu platform, obecnie znacznie lepsze niż JavaFX
• Jest dojrzały i sprawdzony, o wiele bardziej niż JavaFX
• Ma duży ekosystem społeczności / bibliotek użytkowników
• Prawdopodobnie masz już wiele umiejętności Swing lub możesz łatwo zatrudnić z nimi ludzi

Ostatecznie, jeśli nie jest zepsuty, dlaczego to naprawić?

Oczywiście w przypadku nowego projektu bardzo poważnie patrzę na JavaFX, Androida i / lub graficzny interfejs użytkownika (być może z czymś takim jak Vaadin).

Jestem w tej samej pozycji co OP - mam starsze aplikacje swing, ale muszę zaimplementować nowe idiomy i interfejsy, których natywnie nie obsługuje. Największa z tych aplikacji została przebudowana kilka razy z różnych powodów (poprawa modułowości, lepsza MVC i struktura wysyłania zdarzeń itp.), Więc nie jestem całkowicie przeciwny przepisywaniu kodu interfejsu użytkownika. Tak długo zastanawiałem się nad tym problemem.

Jednak niektórych rzeczy nie da się rozwiązać za pomocą Swinga bez zainwestowania dużo więcej czasu i wysiłku w to, co zasadniczo jest starszą technologią. Na przykład inne niż proste zdarzenia myszy, nowe urządzenia z ekranem dotykowym i nie są obsługiwane przez sam Swing. Zapewnienie komponentu przeglądarki opartego na Swing jest podobnie kłopotliwe lub kosztowne, aw moim przypadku podejście javafx-in-swing nie jest opcją, ponieważ komplikuje obsługę zdarzeń interfejsu użytkownika w trywialny sposób.

Myślę, że to był stary i wierny w swoim czasie, a jeśli twoja platforma jest tak niezmienna jak baza kodu - trzymaj się jej, oczywiście. Ale aby aplikacja mogła przejść do nowych, bardziej współczesnych przypadków użycia, JavaFX 2+ prawdopodobnie będzie sposobem na przejście do przodu w moim przypadku.

Na marginesie: jedynym błędem w Swing, który chciałbym, aby zniknął w jfx - ale tego nie zrobiło - jest podejście do wysyłania zdarzeń w interfejsie za pomocą jednego wątku. Każdy nietrywialny interfejs użytkownika wymaga wielowątkowości, aby interfejs użytkownika był przejrzysty i responsywny, a pozostawienie w gestii programisty aplikacji, by bez problemu natknąć się na te same pułapki, jest brakiem w IMHO API.

Mam duże doświadczenie w korzystaniu z RCP w dużych aplikacjach stacjonarnych. Zasadniczo zaczęło się jako abstrakcja warstwy GUI Eclipse i od tego czasu przeszła długą drogę. Zamiast Swinga opartego na AWT, RCP opiera się na JFace, który z kolei opiera się na SWT. Umożliwia tworzenie aplikacji i korzystanie z koncepcji GUI, z których korzysta samo środowisko Eclipse (widoki, edytory, perspektywy, kreatory itp.). Jest bardzo skalowalny i, podobnie jak samo środowisko Eclipse, jest stale ulepszany.

Jednak nigdy nie przeprowadziłem migracji istniejącego projektu ze Swing do RCP; Wyobrażam sobie, że zajęłoby to sporo czasu, aby owinąć głowę wokół różnych paradygmatów, a jeśli nie rozdzielisz modelu i nie widzisz warstw dobrze, na pewno będzie ci ciężko. Ale ponieważ pytałeś o takie rzeczy jak sortowalne tabele drzew, RCP jest w tym świetny.

Jeśli chcesz ponownie to sprawdzić, możesz wypróbować samouczek Larsa Vogela lub zapoznać się z przykładami projektów open source lub projektów komercyjnych korzystających z RCP.

(Na przykład sortowalna tabela drzew), zaczynam odczuwać trudności w realizacji żądań. Jest to prawda, zwłaszcza że nie ma aktywnego rozwoju wokół projektu SwingX.

• nieprawda, czy ten projekt jeszcze żyje,

• blablabla pewnego razu, kiedy SwingX stracił dotacje Sun (podczas akwizycji przez Oracle), ludzie z SwingX poszli do zbudowanego JavaFX

Poza tym prawie nie mogę znaleźć żadnego dobrego, a jednocześnie aktywnie utrzymywanego / rozwijanego / rozwijającego się interfejsu GUI Java.

• Swing nie dotyczy Framework, tylko Look and Feel

• Frameworki są dla użytkowników nietechnicznych (MsAccess może być najlepszym przykładem dla GUI Framework)

• ale jeśli chcesz zbudować prawdziwą aplikację, masz solidną wiedzę na temat Swinga, a overriden również pochodzi z Framework,

• zabawny przykład Netbeans ma wbudowaną Swing Framework opartą na JSR296, ale nie ma możliwości bezpośredniej zmiany ikony JFrames,

Czy zacząłeś migrować swój projekt Swing do znacznie bardziej aktywnego środowiska GUI, takiego jak JavaFX?

bez powodu

• to samo dotyczy migracji do Java7, może kiedy będzie tam Java7.15 - 17

• Porównuję JavaFx do Nimbusa, rozwój zakończył się / zrezygnowałem gdzieś w pierwszej połowie

• przepraszam nie jestem programistą Jestem tylko fanem Java i Swing