Java, a wydajność GUI

Witam,
Aplikacje desktopowe Javy np. w stosunku do C# i .NET są dość powolne i jest ich bardzo mało (pewnie dlatego, że Java to stosunkowo marna platforma do pisania na desktop, co innego web, przynajmniej w oficjalnej specyfikacji).

1 pytanie:
Zastanawia mnie skąd ta powolność skoro obydwa języki kompilują się do analogicznego byte codu?

2 pytanie:
Standardowy przykład: Azureus muli, Eclipse też.

Czy użycie natywnej biblioteki w Javie pochodzącej z natywnego kodu (konkretnie Qt Jambi) powoduje raczej wzrost czy spadek wydajności aplikacji? Na pierwszy rzut oka wydaje mi się, że wydajność powinna wzrosnąć, ale czy jakieś adaptery JVM -> native nie mogą spowodować spadku wydajności? Czy ktoś z szanownych użytkowników to sprawdzał?

Pytam bo lubię Qt i nie wyobrażam sobie tworzenia aplikacji desktop Javowych np. w Swingu czy innym AWT tudzież SWT, z kolei Jambi wydaje mi się świetne, mimo że support to czyste community i byłoby genialnym wyborem wszędzie tam, gdzie Java np. z powodu fajnych bibliotek lepszym wyborem nad C++ (czyli np. przy obsłudze Bluetooth).

Pozdrawiam,

Nie wiem, czemu ludzie narzekają na to GUI w Javie. Nie wydaje mi się, żebym miał jakąś hiper-maszynę a jednak u mnie nie muli. Ponadto w Javie masz jeszcze JavaFX, która w ogóle zmienia podejście do GUI a w dodatku silnie korzysta z możliwości karty graficznej.

Czy ktoś jeszcze może powiedzieć, że np. Eclipse czy Netbeans mu "mulą" ? A może ja po prostu mam już tak nisko ustawiony prób akceptacji i tego nie zauważam ? :D

Część aplikacji zamula, bo ma skopany design, a żadna platforma magicznie nie przyspieszy skopanego kodu.

Przede wszystkim, jeśli chodzi o porównanie Javowych IDE do np DevC++ czy Visual Studio, to Javowe IDE z reguły nie stosują prekompilacji kodu czy pamięci podręcznej do podpowiadania, która byłaby zapisywana w projekcie. Te informacje są generowane zwykle każdorazowo przy ładowaniu projektu. Chociaż w sumie taki IntelliJ IDEA jakąś tam pamięć podręczną chyba ma.

Jak mam mały projekt Javowy w NetBeansie to jak go spakuję to zabiera bardzo mało miejsca - ułamek megabajta. Tymczasem gdy kiedyś kodziłem w C++ w Visual Studio to równie mały projekt po spakowaniu zajmował wiele (kilkanaście chyba) megabajtów - w środku były właśnie prekompilowane nagłówki, pamięć podręczna IntelliSense i inne tego typu śmieci. A więc to jest pewnego typu kompromis: czy zapychać dysk pamięciami podręcznymi jak w Visual Studio, czy też może parsować w kółko przy każdym ładowaniu projektu jak typowe Javowe IDE.

Jeśli chodzi o zamulanie samego Swinga to nie zaobserwowałem takich rzeczy. Swing jest bardzo mocno zoptymalizowany, korzysta z akceleracji sprzętowej (Java2D, która lata albo na OpenGL albo na DirectX). JavaFX jest jeszcze mocniej akcelerowana niż Swing, dodatkowo cała machineria JavyFX 2+ jest podzielona na wiele wątków, zamiast pojedynczego wątku Swinga.

Oprócz AWT, Swinga, JavyFX i Qt Jambi jest jeszcze np SWT, który chyba działa w sposób zbliżony do Qt Jambi, tzn w większym stopniu niż Swing polega na DLL-kach. Z testów które widziałem na necie to już w Javie 5 różnice wydajnościowe pomiędzy Swingiem a SWT były pomijalne, a Swing wygrywał jeśli chodzi np o zdalne interfejsy, tzn zabierał znacznie mniej pasma (przepustowości łącza).

Podmiana toolkitu do GUI prawdopodobnie nie wpłynie w sposób znaczący na wydajność aplikacji, no chyba, że masz skopany design, wtedy któryś tam toolkit może sprawować się lepiej.

Ja polecam JavęFX 2+, ma fajny system propertiesów, znacznie lepszy niż w Swingu. Do tego stylowanie CSSem, więcej akcelerowanych przez GPU czynności, lepsze wykorzystanie wielowątkowych procesorów, więcej funkcjonalności (np wbudowany WebKit, dekodery MP3 i filmów), aktywnie rozwijana przez Oracle, itd

Dzięki za obszerne odpowiedzi, Swing poza tym czy takie SWT zwyczajnie mi się nie podoba, bo za bardzo polubiłem Qt, które wydaje mi się o wiele prostsze i dające dobre rezultaty minimalnym nakładem pracy, poza tym dokumentacja jest świetna. Poza tym toolkit wciąż się rozwija i nie ogranicza mnie do jednego języka.

Ale nie dostałem odpowiedzi na moje zasadnicze pytanie:
"Czy używanie natywnej biblioteki np. Qt Jambi ma pozytywny czy negatywny wpływ na wydajność?"
Intuicja podpowiada mi, że tak bo kod natywny jest szybszy. Czy jednak łączenie go z byte-codem JVM nie powoduje powstawania dodatkowych wąskich gardeł, które spowodują że natywna szybkość będzie zupełnie bez znaczenia?

Jave-FX kiedyś na pewno poznam, ale póki co mam inne priorytety, bo Qt całkowicie spełnia moje wymagania jeśli chodzi o tworzenie GUI. Jak poznam CSS to bardzo chętnie wypróbuje, póki co poznaje technologie webowe dla Javy, które bardzo mi się podobają.

"Czy używanie natywnej biblioteki np. Qt Jambi ma pozytywny czy negatywny wpływ na wydajność?"

Przede wszystkim trzeba sobie zadać pytanie jak dużo Swinga jest napisane w Javie, a jak dużo w C++. Generalnie cały JVM jest napisany w C++, więc prawdopodobnie spora część Swinga też. Kod Javowy wchodzący w skład Swinga jest JITowany do kodu natywnego tak samo jak każdy inny kod Javowy.

Jeśli chodzi o wąskie gardła przy łączeniu kodu natywnego z kodem Javowym to są takie i są niemałe. Nie jestem pewien ale prawdopodobnie .NET ma mniejszy narzut na łączenie C# z kodem natywnym niż Java ma na łączenie Javy z kodem natywnym.

Każde wywołanie kodu natywnego z Javy ma jakiś stały narzut + zmienny narzut. Stały narzut jest dość duży, przez co przy wykorzystywaniu kodu natywnego trzeba zwracać uwagę na to, by zminimalizować ilość wywołań kodu natywnego, np poprzez robienie funkcji w kodzie natywnym które robią maksymalnie dużo rzeczy w ciągu jednego wywołania. Na pewno próby zmniejszenia ilości wywołań nie są wygodne i mogą spowodować że kod będzie brzydki. Narzut na wywołanie natywnej funkcji jest większy, gdy przekazujesz obiekty lub tablice, a jest mniejszy gdy przekazujesz tylko prymitywy oraz ByteBuffery zaalokowane poza stertą Javy (tzn direct). Narzut ten jest spowodowany tym, że zwykłe tablice oraz obiekty mają zmienny adres, tzn w trakcie odśmiecania adresy obiektów mogą się zmienić. Takie zachowanie jest niekompatybilne z typowym kodem natywnym, więc JVM jest zmuszony np do przystopowania GC w trakcie wywołań natywnych.

A więc sumarycznie, Qt Jambi nie powinno przynieść żadnych znaczących wzrostów wydajności. Z tym, że dobrze napisany Swingowy czy JavaFXowy kod na pewno jest inaczej skonstruowany niż kod Qt, dlatego nie należy się zbyt mocno kierować bezpośrednimi porównaniami wydajności pojedynczych funkcji.

CSS dla JavyFX 2+ jest skonstruowany tak, by był w miarę podobny do CSSa stosowanego na stronach webowych. A więc jeśli pisałeś jakikolwiek CSS dla stron webowych, to w JavaFXowym CSSie powinieneś się odnaleźć dość szybko.

Tak więc kierować się będę przede wszystkim funkcjonalnością.

Dokładnie. A najlepiej także wsparciem i rozwojem - AWT i Swing nie są już od wielu lat rozwijane, w przeciwieństwie do JavyFX 2+, która jest intensywnie rozwijana.

Swing jest nadal najpopularniejszym toolkitem i to w nim najłatwiej znaleźć pracę w desktopowej Javie, natomiast JavaFX 2+ jest dość przyszłościowa i myślę, że w ciągu najbliższych lat będzie powoli wypierać Swinga.

Qt Jambi natomiast wygląda na porzucony dwa lata temu projekt i prawdopodobnie będziesz miał sporo problemów z wykorzystaniem funkcjonalności z nowych wersji Qt.

Roadmap dla JavyFX jest tutaj: http://www.oracle.com/technetwork/java/javafx/overview/roadmap-1446331.html
Szczególnie ciekawie zapowiada się JavaFX wbudowana w JDK8, za sprawą lambd oraz szeregu nowych funkcjonalności.
Jeśli masz Javę zainstalowaną razem z JavąFX (najlepiej najnowszy update Javy 7) to możesz zobaczyć demówkę JavyFX 2+: http://www.oracle.com/technetwork/java/javafx/samples/index.html

@Wibowit, oświeć mnie do czego stosuje się to JavaFX?
Można w tym robić aplikacje client-server dla desktopa czy też tylko jakieś fikuśne zegarki / slideshow-y?
Czy to jest bezpośredni odpowiednik .NET WPF ?
(obu nie znam)

Z tym porzuceniem Qt Jambi to półprawda, bo dotyczy tylko wsparcia firmy Nokia. Bindingi społecznościowe Qt mają się świetnie. Listy mailingowe wciąż są aktywne, nowa strona projektu od czasu przejęcia projektu przez Community działa bardzo dobrze. Nie wykluczam, że Qt 5 prędzej czy później zostanie ponownie oficjalnie przeniesione na Jave (w końcu Digia, która kupiła Qt kontynuuje np. port androidowy, który zaczynał jako społecznościowy). To żywy projekt, tyle że jest znacznie odmienny niż Qt dla C++. Posiada np. zupełnie inaczej działający system sygnałów i slotów niż ten z wersji dla C++, który sprawił mi trochę problemów przy pracy z Javowymi wątkami przy implementacji MVC z braku tak dobrej dokumentacji jak dla C++, ale można sobie poradzić (gdybym wiedział, że szukam QSignalEmitter to był poradził sobie od razu). Ale po przeskoczeniu tych drobnych niedogodności uzyskujemy nowe świetne, dojrzałe narzędzie, które znamy wraz z potęgą Javy.

Poza tym jakie funkcjonalności Qt są dla mnie interesujące: tak naprawdę głównie GUI (Qt Widget) oraz system sygnałów - slotów, pewnie Qt SQL, może Qt OpenGL. Do reszty jak np. gniazd Java ma natywne biblioteki i wolę ich używać (chociaż np. gniazda Qt, wątki Qt są dostępne, parsery też, z kolei QStringi zostały zastąpione przez Stringi, a kolekcje w stylu C++ kolekcjami w stylu Javy imo elegancko to wygląda).

Wizualny designer tzn. do XML-owego .juic działa świetnie, potem wystarczy dodać do Eclipse wygenerowany plik java. Świetne narzędzie RAD, jedyna wada po porzuceniu oficjalnego wsparcia jest w oddzielnej aplikacji i trzeba używać CLI aby dokonać konwersji .juic -> .java.

Względnie nowa wersja Qt tzn. 4.7.1 jest wyprodukowana przez Community, a Nokia wydała o ile wiem 4.4 i potem im się odechciało. Jedyna wada to moim zdaniem trochę za słaba dokumentacja, ale przecież sam mogę napisać kilka tutoriali jak mi się zaczną wakacje, sam miałem wątpliwości czy warto wchodzić w Jambi, a na pewno użytkownicy C++ byliby zainteresowani oraz osoby nie znające Qt dla C++ (a sama biblioteka jest banalnie prosta i wygodna jak się załapie kilka podstawowych rzeczy). Poza tym w Qt szykuje się zupełnie nowe podejście do GUI też oparte na coś w ramach CSS i QML, bardzo prawdopodone, że Jambi też będzie to wspierać (pewnie konkurencja dla Java-FX, tyle że na wiele języków niekoniecznie związanych z JVM i to jest moim zdaniem powód dla którego warto znać Qt).

Po obejrzeniu sampli na stronie Oracle JavaFX wydaje się sympatyczna i zamierzam zapoznać się z tym narzędziem, aby poszerzyć sobie horyzonty, ale nie chcę się zamykać na jedyne słuszne rozwiązania. Ograniczony czas, niestety.

No to jak tam chcesz. Nie znam sygnałów i slotów z Qt, ale znam trochę system bindingów, listenerów, obserwowalnych kolekcji itd z JavyFX i mogę powiedzieć, że nawet to zdaje egzamin. Warto mieć JavęFX na oku, bo ma dobre wsparcie od Oracle i intensywnie się rozwija.

@vpiotr:
JavaFX ma w zamierzeniu zastąpić Swinga i może być używana w zasadzie wszędzie gdzie da się wyświetlić GUI. A więc począwszy od apletów na stronach WWW, poprzez aplikacje ładowane przez JNLP, do samodzielnych aplikacji desktopowych oraz aplikacji klient-serwer.

JavaFX ma mieć wszystkie funkcjonalności Swinga + dodatkowo dużo więcej. W JavieFX można korzystać z CSS i FXML przez co ludzie robią analogie do WPFa, który chyba też korzysta z podobnego podejścia (nie jestem pewien, nie interesuję się .NETem mocno). Gdy w Javie 8 dojdą lambdy to możliwe że programowanie w JavieFX i WPFie będzie dość podobne. Tymczasem już teraz istnieją wrappery na JavęFX dla różnych języków, np Groovy, Scala czy JRuby.

@Wibowit: OK, ale na razie piszesz w czasie przyszłym.
Mnie bardziej interesuje w czym robić aplikacje bazodanowe - jeśli chodzi o Jave.
Mam świadomość istnienia czegoś takiego jak Spring Framework, ale JavaFX jakoś mi do tego zadania nie pasuje - z tego co oglądałem demonstracje bardziej jest to środowisko do aplikacji-prezentacji niż do aplikacji biznesowych. Dobrze mi się wydaje?
Pytam o czas teraźniejszy.

Są dwie główne gałęzie JavyFX:

• JavaFX 1.x, która jest oparta o JavaFX Script - ten język skryptowy jest w zasadzie porzucony (jest port na JavęFX 2+, ale nieoficjalny) przez Oracle, JavaFX 1.x była mało popularna właśnie ze względu na ten język skryptowy oraz to, że w czasach JavyFX 1.x trzeba ją było oddzielnie doinstalować i skonfigurować i chyba nie była dostępna na tyle platform co teraz jest dostępna JavaFX 2,
• JavaFX 2+, która jest oparta w całości o język Java (ale można korzystać z niej też w innych językach), czyli tak samo jak Swing. Dodatkowo począwszy od któregoś tam update Javy 7 od Oracle, JavaFX 2.x jest wbudowana w instalator Javy i jest dostępna na coraz większą ilość platform - obecnie Windows, Linux i Mac OS, Win i Lin chyba dostępne zarówno w 32bit jak i 64bit x86, dodatkowo jest przygotowywana JavaFX pod Linux/ARM,

JavaFX 2+ nie zastępuje reszty Javy, jest po prostu Javowym toolkitem do GUI, podobnie jak Swing i podobnie jak Swinga, możesz łączyć ją z Hibernate czy Springiem. W poprzedniej firmie np z powodzeniem połączyliśmy z kumplem JavęFX 2 ze Springiem i Apache Axis2, a całość latała na Windows XP 32-bit.