Zestaw narzędzi GWT: Twórz potężne interfejsy JavaScript za pomocą Java

GWT Web Toolkit, wcześniej znany jako Google Web Toolkit, to zestaw narzędzi programistycznych do tworzenia i optymalizacji złożonych aplikacji opartych na przeglądarce przy użyciu języka programowania Java.

Tym, co sprawia, że ​​GWT nie jest „kolejnym narzędziem Java do pisania aplikacji internetowych”, jest fakt, że sercem zestawu narzędzi jest kompilator, który konwertuje Javę na JavaScript (a także HTML i CSS), umożliwiając programistom pisanie front-endowych aplikacji internetowych jednocześnie wykorzystując wszystkie mocne strony Javy.

Jest nawet łatwe w użyciu połączenie Java i JavaScript, ponieważ GWT zawiera solidną architekturę interoperacyjności do łączenia się z platformą internetową. Podobnie jak Java Native Interface (JNI) umożliwia Java Virtual Machine (JVM) wywoływanie procedur specyficznych dla platformy (na przykład w celu uzyskania dostępu do określonych funkcji sprzętowych lub korzystania z zewnętrznych bibliotek z innych języków), GWT pozwala nam napisać większość w języku Java, a następnie, jeśli to konieczne, użyć określonego internetowego interfejsu API lub wykorzystać istniejące biblioteki JavaScript, aby „przejść na natywną” i przejść do JavaScript.

GWT narodził się jako produkt Google, ale przeszedł na open source pod koniec 2011 roku i jest obecnie udostępniany na licencji Apache License (wersja 2) pod nazwą GWT Open Source Project . Zarządza nim komitet sterujący, w skład którego wchodzą przedstawiciele kilku firm, w tym Google, RedHat, ArcBees, Vaadin i Sencha, a także niezależni programiści ze społeczności.

GWT w przeszłości i w przyszłości

Google Web Toolkit został po raz pierwszy wydany w 2006 roku. Został stworzony jako narzędzie, które ma pomóc inżynierom Google w opracowywaniu złożonych aplikacji opartych na przeglądarce, takich jak AdWords, Google Wallet i Google Flights, a ostatnio jest używany w centrum Aplikacje Arkuszy Google i Skrzynki odbiorczej.

W 2006 roku przeglądarki (i interpretery JavaScript) były dalekie od standaryzacji. Kod front-endowy był powolny, błędny i trudny w użyciu. Niemal całkowity brak wysokiej jakości bibliotek i frameworków do tworzenia stron internetowych. Na przykład jQuery nie istniało nawet w tym roku. Aby więc móc tworzyć aplikacje internetowe na dużą skalę, inżynierowie Google postanowili wykorzystać istniejące narzędzia i kompetencje. Java była językiem najlepiej dopasowanym do ich potrzeb, ponieważ była dobrze znana i doskonale zintegrowana z IDE, takimi jak Eclipse, i tak rozpoczął swoje życie Google Web Toolkit.

Celem było mniej więcej ukrycie różnic między przeglądarkami i uchwycenie trików potrzebnych do napisania wydajnego JavaScript w kompilatorze Javy, uwalniając programistów od tyranii technicznych przeglądarek.

Oczywiście w ciągu ostatniej dekady sieć się zmieniła; przeglądarki stały się szybsze i zbliżyły się do standardów implementacji, a także opracowano wiele niesamowitych frameworków i bibliotek front-end, w tym jQuery, Angular, Polymer i React. Więc pierwsze pytanie, które możesz naturalnie zadać, brzmi: „Czy GWT jest nadal przydatne?”

Jednym słowem: tak .

W kontekście współczesnego tworzenia stron internetowych, targetowanie przeglądarek jest nieuniknione, a JavaScript stał się lingua franca aplikacji front-end. Ale oczywiście różne narzędzia i języki lepiej nadają się do różnych zadań. GWT, wraz z kilkoma podobnymi projektami, ma na celu kierowanie do przeglądarek bez ograniczania programistów do korzystania z JavaScript.

Rozwój i stosowanie narzędzi „kompilujących do sieci”, takich jak GWT, w niedalekiej przyszłości ułatwi tzw. grupa WebAssembly należąca do konsorcjum World Wide Web. Istnieje nie tylko ogromna przestrzeń dla narzędzi, które kompilują się do JavaScript, ale takie podejście może zaspokoić rzeczywiste potrzeby w kontekstach, które obejmują odciążenie części obliczeń do przeglądarek, ponowne wykorzystanie istniejącego kodu i bibliotek, współdzielenie kodu między back-endem i front-endem , wykorzystując istniejące kompetencje i przepływy pracy oraz wykorzystując cechy różnych języków (na przykład statyczne pisanie w przypadku GWT).

Projekt GWT ma wkrótce wydać wersję 2.8, a wersja 3.0 jest w fazie rozwoju, z dużymi ulepszeniami w pracach:

• na nowo wymyślona interoperacyjność z JavaScript
• ulepszony (prawie całkowicie przepisany) kompilator
• najnowocześniejsza obsługa Javy (np. lambdy)

W rzeczywistości większość funkcji GWT 3.0 jest już dostępna w publicznym repozytorium Git. Po prostu sprawdź łącze tutaj i skompiluj GWT zgodnie z dokumentacją tutaj.

Społeczność GWT

Odkąd GWT stało się open source w 2011 roku, społeczność odegrała kluczową rolę w ewolucji projektu.

Cały rozwój odbywa się w repozytorium Git hostowanym na gwt.googlesource.com, a wszystkie przeglądy kodu są wykonywane na gwt-review.googlesource.com. Na tych stronach każdy zainteresowany rozwojem zestawu narzędzi może wnieść swój wkład i zobaczyć, nad czym pracuje społeczność. W ciągu ostatnich kilku lat odsetek nowych łat pochodzących od osób niebędących Googlerami wzrósł z ok. 5 proc. w 2012 r. do ok. 25 proc. w zeszłym roku, potwierdzając rosnące zaangażowanie.

W tym roku społeczność spotkała się na kilku dużych spotkaniach w USA i Europie. GWT.create, organizowane przez Vaadin, odbyło się w styczniu w Monachium w Niemczech iw Mountain View w Kalifornii i zgromadziło ponad 600 uczestników z kilkudziesięciu krajów. 11 listopada we Florencji we Włoszech odbędzie się druga edycja GWTcon, społecznościowej konferencji GWT, którą pomagam w organizacji.

Do czego nadaje się GWT?

Coroczna ankieta na temat zestawu narzędzi GWT, wydana przez Vaadin, omawia ewolucję rozwoju GWT, opinie deweloperów na temat zestawu narzędzi, dobre i złe strony i tak dalej. Ta ankieta pozwala nam również zrozumieć, do czego jest używany zestaw narzędzi, jak zmienia się społeczność użytkowników oraz jakie są oczekiwania programistów dotyczące przyszłości zestawu narzędzi.

Raport o przyszłości GWT za rok 2015 można znaleźć tutaj i jasno pokazuje, że GWT jest bardzo popularny do tworzenia aplikacji internetowych na dużą skalę. Na przykład na stronie 14 czytamy: „Większość aplikacji to aplikacje biznesowe, które wymagają dużej ilości danych i są używane przez wiele godzin dziennie”.

Zgodnie z oczekiwaniami, łatwo można stwierdzić, że naturalnym środowiskiem GWT jest dziedzina aplikacji webowych na dużą skalę, gdzie ważna jest konserwowalność kodu, a duże zespoły czerpią korzyści ze struktury języka Java.

Z drugiej strony, patrząc na testy porównawcze kodu generowanego przez GWT (na przykład w przemówieniu z zeszłorocznej konferencji GWT.create na stronach 7, 8 i 11), łatwo to dostrzec w kategoriach wydajności i rozmiar kodu, skompilowany JavaScript jest oszałamiająco niesamowity. Przy prawidłowym użyciu uzyskana wydajność jest porównywalna z najlepszym ręcznie napisanym JavaScriptem. W rezultacie możliwe jest zastosowanie GWT do przenoszenia bibliotek Java do sieci.

To wyjaśnia kolejny idealny scenariusz dla GWT. Ekosystem Java jest pełen wysokiej jakości bibliotek, które nie mają gotowego do użycia odpowiednika w JavaScript. Kompilator GWT może być użyty do dostosowania takich bibliotek do sieci. Innymi słowy, GWT pozwala nam mieszać biblioteki dostępne zarówno w Javie, jak i JavaScript i uruchamiać je w przeglądarce.

Takie podejście można zaobserwować w rozwoju PicShare, gdzie pokazujemy, jak kilka bibliotek Java, które nie są powszechnie uznawane w sieci (na przykład NyARToolkit), można przenieść do przeglądarki za pomocą GWT i połączyć z internetowymi interfejsami API, w tym WebRTC i WebGL, aby uzyskać całkowicie internetowe narzędzie Augmented Reality. Miałem zaszczyt zaprezentować PicShare na konferencji GWT.create 2015 w styczniu ubiegłego roku.

Pod maską: przekształcenie Javy w JavaScript

GWT Toolkit to umiarkowanie złożony zestaw narzędzi, ale dzięki zaskakująco łatwej w obsłudze integracji z Eclipse każdy może zacząć z niego korzystać migiem.

Tworzenie prostej aplikacji za pomocą GWT jest stosunkowo łatwe dla każdego, kto ma doświadczenie w projektach programistycznych Java. Aby jednak zrozumieć, co „naprawdę się dzieje”, warto przeanalizować główne elementy zestawu narzędzi:

• Transpiler Java na JavaScript
• Emulowane środowisko wykonawcze Java
• Warstwa interoperacyjności

Kompilator optymalizujący GWT

Dogłębny opis działania kompilatora dość wcześnie staje się wysoce techniczny i nie musimy zagłębiać się tak głęboko, ale warto przyjrzeć się niektórym ogólnym koncepcjom.

Pierwszą rzeczą do zrozumienia jest to, że GWT kompiluje Javę do JavaScriptu poprzez tłumaczenie na poziomie kodu źródłowego. Oznacza to, że źródło Java jest tłumaczone ( transpilowane to termin techniczny) na JavaScript. Jest to w przeciwieństwie do posiadania jakiejś wirtualnej maszyny Javy napisanej w JavaScript, która wykonuje kod bajtowy Javy. (Jest to rzeczywiście możliwe i jest to podejście stosowane przez Doppio, ale tak nie działa GWT).

Zamiast tego kod Java jest podzielony na abstrakcyjne drzewo składni (AST) reprezentujące elementy składniowe kodu. Następnie jest mapowany do równoważnego (i zoptymalizowanego) kodu JavaScript AST, który jest ostatecznie konwertowany z powrotem na rzeczywisty kod JavaScript.

Rozważenie zalet i wad transpilacji jest dalekie od przedmiotu tego postu, ale pozwólcie mi zauważyć, że dzięki tej metodzie GWT może bezpośrednio wykorzystać usługi garbage collection interpretera JavaScript, a także wszelkie inne funkcje natywne dla przeglądarki.

Oczywiście jest kilka trudnych części. Na przykład JavaScript ma tylko jeden typ numeryczny, który nie może zawierać 64-bitowego typu liczb całkowitych Javy long long wymagają specjalnego traktowania przez kompilator. Ponadto statyczne typowanie Javy nie ma bezpośredniego znaczenia w JavaScript, więc należy zachować szczególną ostrożność, aby na przykład operacje rzutowania typów były równoważne po transpilacji.

Z drugiej strony, łatwo docenioną zaletą transpilacji jest to, że GWT może przeprowadzać optymalizacje (zarówno pod względem rozmiaru, jak i wydajności) na poziomie Java i JavaScript. Wynikowy standardowy kod JavaScript może być nawet dalej przetwarzany w potoku wdrażania. Na przykład powszechna praktyka, która została teraz zintegrowana ze standardową dystrybucją GWT, obejmuje optymalizację wyjścia JavaScript przez transpiler przy użyciu wysoce wyspecjalizowanego kompilatora zamknięć JavaScript do JavaScript (kolejny dar od bogów Google).

Najbardziej dogłębny opis kompilatora GWT, jaki znam, można znaleźć w tym zestawieniu slajdów, a także w oryginalnym przemówieniu, z którego pochodzi. Tutaj znajdziesz szczegóły dotyczące innych fajnych funkcji procesu kompilacji, takich jak zdolność GWT do dzielenia kodu, generowania wielu oddzielnych plików skryptów, które mogą być ładowane niezależnie przez przeglądarkę.

Emulowane JRE

Kompilator Java-to-JavaScript byłby niczym więcej niż nowością, gdyby nie został uzupełniony implementacją środowiska Java Runtime Environment (JRE), które zapewnia podstawowe biblioteki, na których opiera się prawie każda aplikacja Java. Z grubsza rzecz biorąc, praca w Javie bez na przykład metod Collections lub String byłaby frustrująca, a przenoszenie tych bibliotek jest oczywiście tytanicznym zadaniem. GWT wypełnia tę dziurę tzw. Emulowanym JRE.

Emulowane środowisko JRE nie jest w żadnym wypadku pełną reimplementacją środowiska Java JRE, ale raczej rodzajem zbioru klas i metod, które mogą być przydatne (i użyteczne) po stronie klienta. Funkcjonalności, które są w Java JRE, ale których nie znajdziesz w emulowanym JRE, dzielą się na trzy kategorie:

• Rzeczy, których nie można przenieść po stronie klienta. Na przykład java.lang.Thread lub java.io.File nie mogą być zaimplementowane w przeglądarce z tą samą semantyką co Java. Strona przeglądarki jest jednowątkowa i nie ma bezpośredniego dostępu do systemu plików.

• Rzeczy, które można by zaimplementować, ale które „kosztowałyby za dużo” pod względem rozmiaru kodu, wydajności lub zależności, a których społeczność woli nie mieć w GWT. W tej kategorii znajduje się na przykład odbicie Java ( java.lang.reflect ), które wymagałoby od transpilera przechowywania informacji o klasie dla każdego typu, co spowodowałoby zwiększenie rozmiaru skompilowanego JavaScriptu.

• Rzeczy, którymi nikt się nie interesował i dlatego nie zostały zrealizowane.

Jeśli zdarzy się, że Emulated JRE nie odpowiada Twoim potrzebom (np. potrzebujesz jakiejś klasy, której nie ma), GWT pozwala na napisanie własnej implementacji. Ten potężny mechanizm, dostępny za pośrednictwem tagu <super-source> , umożliwia obejście problemów podczas dostosowywania nowych bibliotek zewnętrznych, które używają części środowiska JRE, które nie są emulowane.

Zapewnienie pełnej implementacji niektórych części JRE może być zbyt skomplikowane, a nawet niemożliwe, więc w przypadku konkretnych zadań własne implementacje mogą nie być ściśle zgodne z semantyką JRE Javy, nawet jeśli działają w konkretnym przypadku. Rzeczywiście, jeśli rozważasz oddanie swoich klas z powrotem do projektu, pamiętaj, że dla emulowanego środowiska JRE niezwykle ważne jest, aby każda zawarta klasa była zgodna z tą samą semantyką oryginalnego środowiska Java JRE. Gwarantuje to, że każdy może przekompilować kod Java do JavaScript i ufać, że uzyska oczekiwane rezultaty. Zawsze upewnij się, że Twój kod jest dokładnie przetestowany, zanim oddasz go społeczności.

Warstwa interoperacyjności

Aby być skutecznym narzędziem do tworzenia rzeczywistych aplikacji internetowych, GWT musi umożliwiać programistom łatwą interakcję z podstawową platformą. Czyli przeglądarka i DOM.

Od samego początku GWT był budowany, aby wspierać taką interakcję poprzez JavaScript Native Interface (JSNI), który sprawia, że ​​dostęp do interfejsów API w przeglądarce jest dziecinnie prosty. Na przykład, używając funkcji składni unikalnych dla kompilatora GWT, możesz napisać następujący kod Java:

 public static native void nativeMethod(T1 a1, T2 a2, ...) /*-{ //place your JavaScript code here }-*/;

i możesz zaimplementować treść metody w JavaScript. Możesz nawet zawijać obiekty JavaScript w JavaScriptObject (JSO) i udostępniać je w kodzie Java.

Przykład, w którym ta warstwa wchodzi w grę, można znaleźć w kontekście kompozycji interfejsu użytkownika. Podstawowa Java zawsze używała standardowego zestawu narzędzi Widgets do tworzenia elementów interfejsu użytkownika, wykorzystując natywny interfejs Java do uzyskiwania dostępu do systemów okienkowych i wejściowych bazowego systemu operacyjnego. Warstwa interoperacyjności GWT robi to samo, dzięki czemu tradycyjne widżety działają bezproblemowo w przeglądarce. Jedyna różnica polega na tym, że w tym przypadku podstawowym systemem jest przeglądarka i DOM.

Jednak natywne frameworki front-end uległy w ostatnich latach szybkiej poprawie i obecnie oferują znaczną przewagę nad widżetami GWT. Ponieważ te struktury stały się bardziej wyrafinowane, próby ich implementacji w JSNI ujawniły niedociągnięcia w architekturze warstwy interoperacyjności. Począwszy od wersji 2.7, GWT wprowadził JsInterop, nowe podejście oparte na adnotacjach Java, które pozwala szybko i łatwo zintegrować klasy GWT z JavaScript. Nie jest już konieczne pisanie metod JSNI czy klas JSO. Zamiast tego możesz po prostu użyć adnotacji, takich jak @JSType lub @JSProperty , co pozwala pracować z natywnymi klasami JavaScript tak, jakby były Javą.

Pełna specyfikacja JsInterop jest wciąż w toku, a najnowsze aktualizacje można wypróbować jedynie poprzez kompilację źródła z repozytorium GWT. Ale już teraz jest jasne, że jest to nowy kierunek, który pozwoli GWT nadążyć za ewoluującymi platformami internetowymi.

Jednym z trwających projektów wykorzystujących JsInterop jest niedawno wydany gwt-polymer-elements, który udostępnia GWT wszystkie elementy Iron and Paper firmy Polymer. Co ciekawe w tej bibliotece programiści nie muszą ręcznie generować Java API. Projekt wykorzystuje narzędzie gwt-api-generator do bezpośredniego generowania większości interfejsów, analizując bibliotekę Polymer i adnotacje JSDoc. Ułatwia to aktualizowanie wiązań.

Ostatnie słowa

Dzięki ulepszeniom kompilatora, warstwie interoperacyjności oraz wydajności i rozmiarowi wygenerowanego kodu w ciągu ostatnich dwóch lat, jasne jest, że GWT nie jest tylko „kolejnym narzędziem do tworzenia stron internetowych”, ale jest na dobrej drodze, aby stać się głównym zestawem narzędzi referencyjnych dla tworzenie złożonych aplikacji internetowych na dużą skalę, a nawet może być doskonałym wyborem do tworzenia niesamowitych prostszych aplikacji.

Używam GWT na co dzień w mojej pracy jako programista i konsultant, ale przede wszystkim kocham GWT, ponieważ pozwala mi przekraczać granice możliwości przeglądarki i pokazać, że nowoczesne aplikacje internetowe mogą być równie potężne, jak aplikacje desktopowe.

Społeczność Projektu GWT jest bardzo aktywna i stale pojawiają się propozycje nowych bibliotek, projektów i aplikacji opartych na GWT. We Florencji społeczność GWTcon2015 spotka się 11 listopada. Jeśli jesteś w tym regionie, mam nadzieję, że przyjedziesz i spotkasz niektórych z głównych programistów i poznasz wszystkie możliwości bycia częścią ewolucji tego niesamowitego zestawu narzędzi.