Poważne zastosowanie JavyFx

Czy JavaFx jest jeszcze jakkolwiek używana w poważnych projektach?

Pytam, bo chciałem sobie postawić pusty projekt, java+javafx+gradle; i strasznie to jest oporne do zrobienia. Trzeba albo odpalać runtime przekazując jakieś flagi --module-path oraz włączać te moduły; albo dodać module-info.java. Dodatkowo jest straszny problem z tym żeby jakoś sensownie to odpalić, bo od Javy 11tki javafx jak rozumiem nie jest dystrybuowana z Javą, więć trzeba dodać samemu .jar od JavyFX oraz odpowiedni runtime (czyli na Windowsie to będą te paczki z .dll). I trzeba wtedy albo samemu to dostarczć podczas deploy'a, albo korzystać z takich narzędzi jak jlink żeby je jakoś wkompilować. Wtedy odpalanie z gradle'a działa nawet spoko, ale odpalanie tego prosto z IDE wiąże się z ręcznym linkowaniem tych elementów i dodawaniem tych paramsów.

Biblioteka do testów na Githubie ma 800 starów, co sugerowałoby że nie jest znowu tak często używana.

Więc pytanie - czy JavaFx to nadal to jest duży gracz do aplikacji desktopowych, czy raczej powinno się już korzystać z czegoś innego?

Riddle napisał(a):

Czy JavaFx jest jeszcze jakkolwiek używana w poważnych projektach?

nie wiem czy jeszcze, ale to jest wycinek aplikacji javafx z 2016 roku: https://devm.io/java/20-javafx-real-world-applications-123653 . te apki wyglądają mi na raczej poważne korporacyjne wewnętrzne narzędzia.

Pytam, bo chciałem sobie postawić pusty projekt, java+javafx+gradle; i strasznie to jest oporne do zrobienia. ...

eee, coś z tutoriala nie działa? https://openjfx.io/openjfx-docs/
jest parę kroków do wykonania na start, ale chyba nie jest to rocket science?

Więc pytanie - czy JavaFx to nadal to jest duży gracz do aplikacji desktopowych, czy raczej powinno się już korzystać z czegoś innego?

prawdopodobnie w aplikacjach szerokiego użytku nie jest często stosowana. masówka to i tak najczęściej html5 w przeglądarce i/lub mobilki, a jak zwykły użytkownik chce zainstalować apkę desktopową to zwykle korzysta z tych popularnych i natywnie kompilowanych. apkę javafx da się skompilować za pomocą native-image z graalvma, ale to chyba i tak nie wystarczy, by typowy użytkownik chciał instalować przypadkową apkę natywną z neta.

ostatecznie, moim zdaniem, wybór zależy od sytuacji:

• jeśli chcesz zrobić masówkę (tzn. apkę dla każdego, bez względu na miejsce zatrudnienia, itd) to zrób apkę w przeglądarce i/lub na komórki
• jeśli masz klienta korporacyjnego (lub jakiegokolwiek innego, który ci zaufa na tyle, by instalować twoje natywne apki) to javafx jak najbardziej może być akceptowalna

Wibowit napisał(a)

Pytam, bo chciałem sobie postawić pusty projekt, java+javafx+gradle; i strasznie to jest oporne do zrobienia. ...

eee, coś z tutoriala nie działa? https://openjfx.io/openjfx-docs/
jest parę kroków do wykonania na start, ale chyba nie jest to rocket science?

No udało mi się to zrobić; ale chodzi własnie o to że to jest dosyć toporne, o wielu dodatkowych rzeczach trzeba pamiętać. I dlatego się zastanawiam, czy to jest tak by design; że to jest jakaś niemożliwa do obejścia konsekwencja; czy po prostu ten plugin do gradle'a do javyfx jest słabo napisany i to z niego wynikają te komplikacje. W GTK w Rubym też trzeba było manualnie dołączać runtime do aplikacji, ale potem można ją było normalnie włączyć ruby program.rb bez dodatkowego kombinowania - tutaj w JavieFx to jest jeszcze bardziej skomplikowane, zależnie od tego czy włącza się apkę z gradle'a czy z IDE, i w zależności czy używa się module-info.java czy nie. Wiadomo - to jest do ogarnięcia, ale nie jest simple.

No i nadal nie jestem pewien technologii do testowania tego.

javafx została odłączona od głównych dystrybucji openjdk i ma to pewne konsekwencje (jak już napisałeś).

negatywne, np:

• trzeba kombinować z ustawieniami modułów, bo java 9+ jest zmodularyzowana i javafx z tego korzysta (javafx była wbudowana jeszcze w javę 9 chyba, no i zresztą modularyzacja jest ogólnie dobra)
• trzeba kombinować z dodawaniem zależności natywnych

pozytywne, np:

• można użyć nowej javyfx na starszej javie, np. teraz na https://jdk.java.net/javafx20/ jest napisane JavaFX 20 is designed to work with JDK 20, but it is known to work with JDK 17 and later versions. więc możesz sobie skorzystać z nowych wersji javyfx bez narażania się na problemy z niekompatybilnością z nową wersją javy.

No i nadal nie jestem pewien technologii do testowania tego.

ja też nie. w ogóle jeszcze nie wiem jak porządnie testować jakikolwiek nietrywialny frontend :) cały czas jestem backendowcem.

Wibowit napisał(a):

ja też nie. w ogóle jeszcze nie wiem jak porządnie testować jakikolwiek nietrywialny frontend :)

zatrudnić testera ;p

@kixe52: a w sumie to przypomniałem sobie pracę w sabre i ten osobny zespół testerów to może nie była taka kiepska sprawa. mieli wyspecjalizowane narzędzia do testowania aplikacji desktopowych. wadą jest oczywiście to, że pracowali na pełnej wersji aplikacji, a nie mogli testować komponentów w izolacji (bo im oczywiście nie dostarczaliśmy żadnych poobcinanych wersji apki do wycinkowego testowania).

kixe52 napisał(a):

Wibowit napisał(a):

ja też nie. w ogóle jeszcze nie wiem jak porządnie testować jakikolwiek nietrywialny frontend :)

zatrudnić testera ;p

Słaby joke, testy manualne stają się bardzo długie i bardzo drogie dosyć szybko, a po pewnym czasie w ogóle nierzetelne.

W poważnych aplikacjach tylko zautomatyzowane testy mają sens - chyba że jest jakiś na prawdę bardzo dobry powód czemu czegoś nie da się przetestować automatycznie.

@Riddle: o ile dobrze pamiętam z pracy w sabre to testerzy część swoich testów mieli oskryptowane, tzn. część testów robili ręcznie, a część automatyzowali. jednak było to tak dawno, że nie dam sobie nic za to uciąć. oczywiście zostaje wada, o której wspomniałem wcześniej, czyli takie testowanie dotyczy poskładanej apki (tzn. jest wolne i późne), a nie komponentów w izolacji. inna wada to napięcia na linii programiści vs testerzy, bo testerzy chcą ujawnić jak najwięcej błędów, a programiści nie chcą się użerać z irytującymi i pracochłonnymi błędami. koniec końców, wiele błędów było zamiatanych pod dywan dla świętego spokoju.

Daruj sobie JavaFX.
Napisałem jedną aplikację komercyjną w tym jeszcze za czasów "świetności". Development był bardzo przyjemny po pokracznych JSFach, ale utrzymanie tego - czyli instalacja odpowiedniej Javy, runtime'ów i przede wszystkim wyjaśnianie, że są problemy z kartą graficzną.

A to było dawno temu. W dzisiejszych czasach JavaFx nie jest częścią Javy, nie jest nawet oficjalnie wspierana przez Oracle'a, i mam spore wątpliwości, że np. różne Linuxy ogarną JavęFx. Użyj jakiegoś Fluttera czy .NET.

Ps. jeśli chodzi o testy to masz klasę jafafx.scene.Robot.

Nie wiem czy moje projekty są poważne, ale jest używana. O ile te problemy ze środowiskiem da się obejść brzydko, ale łatwo dołączając odpowiedni runtime do aplikacji, to większym problemem są bugi i brak sensownego tempa rozwoju. Oracle traktuję ten kawałek Java, jako coś, co szkoda zabić, ale utrzymywać też się nie opłaca.

Jeśli chcesz robić apliakcje okienkowe, to Swing jest nadal używany (np. Intelij Idea jest w swingu) i jest multiplatformowy

JavaFX to jest dzołk, rozwija się ale w ślimaczym tempie, brakuje darmowych kontrolek, w sumie abandonware.
Co do szablonu kiedyś zrobiłem gotowca żeby za każdym razem nie startować od zera: https://github.com/marcin-chwedczuk/javafx-template
Mam na GH parę głupich apek w JavaFX, jak trzeba kilka zrobić prostaka z kilkoma guzikami i inputem to daje radę, ale do niczego poważnego bym nie użył (obsługa Tray'a jest fatalna). Teraz zaczynam się bawić Swift + applowe UI.

Jakby ktoś się pytał czy używają tego jeszcze komercyjnie to tak. Dzisiaj dostałem na hrowym fejsbuku ofertę dla Java developera gdzie stack to min Swing/JavaFX. Stack nie zachęca, ale branża może być ciekawa bo statki bezzałogowe/geoinformatyka.