GWT Web Toolkit , aiemmin tunnettu nimellä Google Web Toolkit, on joukko kehitystyökaluja monimutkaisten selainpohjaisten sovellusten rakentamiseen ja optimointiin Java-ohjelmointikielellä.
Mikä tekee GWT: stä 'ei vielä yhden Java-työkalun verkkosovellusten kirjoittamiseen', on se, että työkalupaketin sydän on kääntäjä, joka muuntaa Java osaksi JavaScript (sekä HTML ja CSS), joiden avulla kehittäjät voivat kirjoittaa etupään verkkosovelluksia hyödyntämällä samalla kaikkia Java-vahvuuksia.
Javan ja JavaScriptin yhdistelmän käyttö on jopa helppoa, koska GWT sisältää vankan yhteentoimivuusarkkitehtuurin verkkoyhteyden muodostamiseen. Aivan kuten Java Native Interface (JNI), antaa Java Virtual Machine (JVM) -palvelun kutsua alustakohtaisia rutiineja (esimerkiksi käyttää tiettyjä laitteisto-ominaisuuksia tai käyttää ulkoisia kirjastoja muilta kieliltä), GWT antaa meille mahdollisuuden kirjoittaa suurimman osan sovelluksen Java-sovelluksessa ja tarvittaessa käyttää tiettyä web-sovellusliittymää tai hyödyntämään olemassa olevia JavaScript-kirjastoja 'siirtymään natiiviksi' ja siirtymään JavaScriptiin.
GWT syntyi Google-tuotteena, mutta valmistui avoimen lähdekoodin käyttöön vuoden 2011 lopulla ja julkaistaan nykyään Apache-lisenssillä (versio 2) nimellä GWT: n avoimen lähdekoodin projekti . Sitä hallinnoi a ohjauskomitea edustajien kanssa useista yrityksistä, mukaan lukien Google , Punainen hattu , ArcBees , Vaadin ja Sencha , samoin kuin yhteisön itsenäiset kehittäjät.
Google Web Toolkit julkaistiin ensimmäisen kerran vuonna 2006. Se luotiin työkaluna auttamaan Google-insinöörejä kehittämään monimutkaisia selainpohjaisia sovelluksiaan, kuten AdWords, Google Wallet ja Google Flights, ja viime aikoina sitä käytetään Google Sheets- ja Inbox-sovellukset.
Vuonna 2006 selaimet (ja JavaScript-tulkit) olivat kaukana standardoiduista. Etupään koodi oli hidas, buginen ja sitä oli vaikea käyttää luotettavasti. Laadukkaita kirjastoja ja kehyksiä web-kehitykseen puuttui melkein kokonaan. Esimerkiksi jQueryä ei ollut edes olemassa vasta tänä vuonna. Joten voidakseen kehittää laajamittaisia verkkosovelluksia Googlen insinöörit päättivät hyödyntää olemassa olevia työkaluja ja osaamista. Java oli parhaiten sopiva kieli heidän tarpeisiinsa, se oli hyvin tunnettu ja integroitu täydellisesti IDE: iin, kuten Eclipse, ja niin Google Web Toolkit aloitti elämänsä.
Tavoitteena oli enemmän tai vähemmän piilottaa selainten väliset erot ja sisällyttää tehokkaan JavaScriptin kirjoittamiseen tarvittavat temput Java-kääntäjän sisälle, jättäen kehittäjät vapaiksi selaintekniikan tyranniasta.
Tietenkin verkko on muuttunut viime vuosikymmenen aikana; selaimet ovat nopeutuneet ja ovat lähentyneet toteutusstandardeja, ja on kehitetty paljon mahtavia käyttöliittymän kehyksiä ja kirjastoja, mukaan lukien jQuery, Angular, Polymer ja React. Joten ensimmäinen kysymys, jonka saatat luonnollisesti kysyä, on: 'Onko GWT edelleen hyödyllinen?'
Sanassa: Joo .
Nykyaikaisessa verkkokehityksessä selainten kohdistaminen on väistämätöntä ja JavaScriptistä on tullut lingua franca käyttöliittymän sovelluksista. Eri työkalut ja kielet sopivat tietysti paremmin eri tehtäviin. GWT sekä kourallinen vastaavia hankkeita tavoitteena on kohdistaa selaimet rajoittamatta kehittäjiä käyttämään JavaScriptiä.
GWT: n kaltaisten 'compile-to-the-web' -työkalujen kehittämistä ja työllistämistä helpottaa lähitulevaisuudessa ns. WebAss kokoonpano World Wide Web Consortiumin ryhmä. JavaScript-järjestelmään kääntyville työkaluille ei ole vain paljon tilaa, mutta tämä lähestymistapa voi täyttää todellisen tarpeen konteksteissa, jotka vaihtelevat laskennan osan purkamisesta selaimiin, olemassa olevan koodin ja kirjastojen uudelleenkäyttöön, koodin jakamiseen käyttöliittymän ja käyttöliittymän välillä , hyödyntämällä olemassa olevia taitoja ja työnkulkuja ja hyödyntämällä eri kielten ominaisuuksia (esimerkiksi staattinen kirjoittaminen GWT: n tapauksessa).
GWT-projektin odotetaan julkaisevan version 2.8 pian, ja versiota 3.0 on kehitteillä, ja töihin on tehty huomattavia parannuksia:
Itse asiassa suurin osa GWT 3.0: n ominaisuuksista on jo saatavilla julkisessa Git-arkistossa. Katso vain tavaratila, tässä ja koota GWT dokumentaation mukaisesti tässä .
Siitä lähtien, kun GWT otettiin avoimen lähdekoodin käyttöön vuonna 2011, yhteisö on ottanut keskeisen roolin projektin kehityksessä.
Kaikki kehitys tapahtuu isännöidyssä Git-arkistossa gwt.googlesource.com , ja kaikki koodiarvostelut tehdään gwt-review.googlesource.com . Näillä sivuilla kuka tahansa, joka on kiinnostunut työkalupaketin kehittämisestä, voi antaa panoksensa ja nähdä, mitä yhteisö tekee. Muutaman viime vuoden aikana muiden kuin Googlen työntekijöiden uusien korjaustiedostojen osuus on noussut noin 5 prosentista vuonna 2012 noin 25 prosenttiin viime vuonna, mikä vahvistaa kasvavaa osallistumista.
Tänä vuonna yhteisö on kokoontunut muutamaan isoon kokoukseen Yhdysvalloissa ja Euroopassa. GWT. Luo Vaadinin järjestämä, pidettiin tammikuussa sekä Münchenissä Saksassa että Mountain View'ssä Kaliforniassa, ja siihen osallistui yli 600 osallistujaa kymmenistä maista. Pidämme 11. marraskuuta Firenzessä, Italiassa, toisen painoksen GWTcon , yhteisövetoinen GWT-konferenssi, jonka järjestämisessä autan.
Vaadin julkaisi vuosittaisen kyselyn GWT-työkalupakista, jossa keskustellaan GWT: n kehityksestä, siitä, miten kehittäjät suhtautuvat työkalupakettiin, hyvään, pahaan ja niin edelleen. Tämän kyselyn avulla voimme myös ymmärtää, mihin Toolkitia käytetään, miten käyttäjien yhteisö muuttuu ja mitä kehittäjät odottavat työkalupakin tulevaisuudesta.
GWT-raportin tulevaisuus vuodelta 2015 löytyy tässä , ja se tekee selväksi, että GWT on erittäin suosittu laajamittaisten verkkosovellusten rakentamisessa. Esimerkiksi sivulla 14 sanotaan: 'Suurin osa sovelluksista on yrityspalveluja, jotka ovat paljon dataa ja joiden kanssa työskennellään useita tunteja päivässä.'
Kuten on odotettua, on helppo päätellä, että GWT: n luonnollinen ympäristö on laajamittaisten verkkosovellusten kenttä, jossa koodin ylläpidettävyys on tärkeää ja että suuret tiimit hyötyvät Java-kielen rakenteesta.
Toisaalta tarkastelemalla GWT: n luoman koodin vertailuarvoja (esimerkiksi viime vuoden GWT.create-konferenssin pääesittely , sivuilla 7, 8 ja 11) on helppo nähdä, että käännetty JavaScript on suorituskyvyn ja koodikoon suhteen hämmästyttävän mahtava. Oikein käytettynä saavutettu suorituskyky on verrattavissa parhaisiin käsin kirjoitettuihin JavaScript-tiedostoihin. Tämän seurauksena on todella mahdollista käyttää GWT: tä Java-kirjastojen siirtämiseen verkkoon.
Tämä valaisee toisen ihanteellisen skenaarion GWT: lle. Java-ekosysteemi on täynnä korkealaatuisia kirjastoja, joilla ei ole käyttövalmiita vastaavia JavaScriptiä. GWT-kääntäjää voidaan käyttää tällaisten kirjastojen mukauttamiseen verkkoon. Toisin sanoen GWT antaa meille mahdollisuuden sekoittaa sekä Java- että JavaScript-kirjastoja ja suorittaa ne selaimessa.
Tämä lähestymistapa voidaan nähdä PicShare , jossa näytetään kuinka useita Java-kirjastoja ei yleensä oteta huomioon verkossa ( TheARToolkit Esimerkiksi) voidaan portoida selaimeen GWT: n avulla ja yhdistää web-sovellusliittymiin, mukaan lukien WebRTC ja WebGL, täysin verkkopohjaisen Augmented Reality -työkalun saamiseksi. Olin ylpeä voidessani esitellä PicSharea vuoden 2015 GWT.create-konferenssissa viime tammikuussa.
JavaScript-käyttöliittymät Java-sovellusten voimalla? Kyllä, sinäkin voit saada kaiken GWT: n avulla! TweetGWT Toolkit on kohtalaisen monimutkainen työkalusarja, mutta kuka tahansa voi alkaa käyttää sitä hetkessä, kiitos yllättävän helppokäyttöinen integrointi Eclipseen .
Yksinkertaisen sovelluksen luominen GWT: n avulla on suhteellisen helppoa kaikille, joilla on tausta Java-kehitysprojektit . Mutta ymmärtääksemme, mitä 'todella tapahtuu', kannattaa analysoida työkalupaketin pääkomponentit:
Perusteellisesta kuvauksesta kääntäjän toiminnasta tulee erittäin tekninen melko varhaisessa vaiheessa, eikä meidän tarvitse kaivaa sitä syvälle, mutta joitain yleisiä käsitteitä kannattaa tarkastella.
Ensinnäkin on ymmärrettävä, että GWT kääntää Java Java-koodiksi kääntämällä lähdekooditasolla. Eli Java-lähde käännetään ( siirretty on tekninen termi) JavaScriptiksi. Tämä on toisin kuin jonkinlainen Java-virtuaalikone, joka on kirjoitettu JavaScript-muodossa, joka suorittaa Java-tavukoodin. (Tämä on todella mahdollista, ja sitä lähestymistapaa käyttää Kaksinkertainen , mutta GWT ei toimi näin.)
Sen sijaan Java-koodi on jaettu abstrakti syntaksipuu (AST) joka edustaa koodin syntaktisia elementtejä. Sitten se kartoitetaan vastaavaan (ja optimoituun) Javascript AST: hen, joka lopulta muunnetaan takaisin todelliseksi JavaScript-koodiksi.
Transpilaation etujen ja haittojen punnitseminen on kaukana tämän viestin kohteesta, mutta haluan huomata, että tällä menetelmällä GWT voi hyödyntää suoraan JavaScripti-tulkin roskienkeräyspalveluja sekä muita selaimelle ominaisia ominaisuuksia.
On tietysti joitain hankalia osia. Esimerkiksi JavaScriptillä on vain yksi numeerinen tyyppi, joka ei voi sisältää Javan 64-bittistä long
kokonaislukutyyppi, joten long
tyypit vaativat kääntäjän erityiskäsittelyä. Lisäksi Java-staattisella kirjoittamisella ei ole suoraa merkitystä JavaScripteissä, joten on kiinnitettävä erityistä huomiota esimerkiksi kirjoitusoperaatioiden vastaavuuteen siirron jälkeen.
Toisaalta helposti ymmärrettävä transpilaation etu on, että GWT pystyy suorittamaan optimointeja (sekä koon että suorituskyvyn suhteen) Java-tasolla ja JavaScript-tasolla. Tuloksena oleva vakio JavaScript-koodi voidaan jopa käsitellä edelleen käyttöönottoputkessa. Esimerkiksi tavanomainen käytäntö, joka on nyt integroitu GWT-standardijakeluun, tarkoittaa sitä, että transpilaattori optimoi JavaScript-tuotoksen käyttämällä erittäin erikoistunutta JavaScript-to-JavaScript-ohjelmaa Sulkemisen kääntäjä (toinen lahja Googlen jumalilta).
GWT-kääntäjän perusteellisin kuvaus, jonka tiedän, löytyy tämä liukukansi , ja alkuperäinen puhe, josta se tulee . Täältä löydät tietoja muista kokoamisprosessin hienoista ominaisuuksista, kuten GWT: n kyvystä tehdä koodin jakaminen , luoda useita erillisiä komentotiedostoja, jotka selain lataa itsenäisesti.
Java-JavaScript-kääntäjä olisi vain uutuus, ellei sitä täydennettäisi Java Runtime Environment (JRE) -toteutuksella, joka tarjoaa melkein minkä tahansa Java-sovelluksen käyttämät ydinkirjastot. Karkeasti sanottuna Java-työskentely ilman esimerkiksi kokoelmia tai merkkijonomenetelmiä olisi turhauttavaa, ja tietysti näiden kirjastojen siirtäminen on titaanista työtä. GWT täyttää tämän aukon ns Emuloitu JRE .
Emuloitu JRE ei ole missään nimessä Java JRE: n täydellinen uudelleentoteutus, vaan pikemminkin eräänlainen valikoima luokkia ja menetelmiä, jotka voivat olla hyödyllisiä (ja käyttökelpoisia) asiakaspuolia. Java JRE: ssä olevat toiminnot, joita et löydä emuloidussa JRE: ssä, jaetaan kolmeen luokkaan:
Asioita, joita ei voi siirtää asiakaspuolelle. Esimerkiksi java.lang.Thread
tai java.io.File
ei voida toteuttaa selaimessa, jolla on sama Java-semantiikka. Selainsivu on yksisäikeinen, eikä sillä ole suoraa pääsyä tiedostojärjestelmään.
Asiat, jotka voitaisiin toteuttaa, mutta jotka 'maksavat liikaa' koodin koon, suorituskyvyn tai riippuvuuksien suhteen ja joita yhteisö ei siis halua olla GWT: n sisällä. Tähän luokkaan kuuluu esimerkiksi Java-heijastus (java.lang.reflect
), joka vaatisi transpileria pitämään luokkatiedot kullekin tyypille ja joka saisi käännetyn JavaScriptin koon kasvamaan.
Asiat, joista kukaan ei ollut kiinnostunut, ja siksi niitä ei ole pantu täytäntöön.
Jos tapahtuu, että emuloitu JRE ei sovi tarpeisiisi (esim. Tarvitset luokkaa, jota ei tarjota), GWT antaa sinun kirjoittaa oman toteutuksesi. Tämä tehokas mekanismi, joka on saatavilla tagin kautta, mahdollistaa ongelmien kiertämisen mukautettaessa uusia ulkoisia kirjastoja, jotka käyttävät JRE: n osia, joita ei ole jäljitelty.
JRE: n joidenkin osien täydellinen toteutus voi olla liian monimutkaista tai jopa mahdotonta, joten tietyissä tehtävissä omat toteutuksesi eivät välttämättä noudata tarkasti Java: n JRE: n sematiikkaa, vaikka ne toimivat sinun tapauksessasi. Jos harkitset luokkien palauttamista takaisin projektiin, muista, että emuloidun JRE: n kannalta on ensiarvoisen tärkeää, että jokainen mukana oleva luokka noudattaa samaa alkuperäisen Java JRE: n semantiikkaa. Tämä varmistaa, että kuka tahansa voi kääntää Java-koodin uudelleen JavaScriptiin ja luottaa siihen, että hän saa odotetut tulokset. Varmista aina, että koodisi on testattu perusteellisesti, ennen kuin annat sen takaisin yhteisölle.
Voidakseen olla tehokas työkalu todellisten verkkosovellusten tuottamiseen, GWT: n on annettava kehittäjille mahdollisuus olla helposti vuorovaikutuksessa taustalla olevan alustan kanssa. Eli selain ja DOM.
Alusta alkaen GWT rakennettiin tukemaan tällaista vuorovaikutusta JavaScriptin alkuperäinen käyttöliittymä (JSNI) , mikä tekee selaimen sisäisten sovellusliittymien käyttämisestä helppoa. Esimerkiksi GWT-kääntäjälle ainutlaatuisten syntaksitoimintojen avulla voit kirjoittaa seuraavan Java-koodin:
public static native void nativeMethod(T1 a1, T2 a2, ...) /*-{ //place your JavaScript code here }-*/;
ja voit vapaasti toteuttaa menetelmän rungon JavaScriptissä. Voit jopa kääri JavaScript-objektit a JavaScriptObject (JSO) ja tee se saataville Java-koodissasi.
Esimerkki tämän kerroksen esiintymisestä löytyy käyttöliittymän koostumuksen yhteydessä. Java-valtavirta on aina käyttänyt käyttöliittymäelementtien luomiseen tavallista Widgets-työkalupakettia hyödyntämällä Java Native Interface -käyttöliittymää pääsyn taustalla olevaan käyttöjärjestelmään. GWT: n yhteentoimivuuskerros tekee saman, joten perinteiset widgetit toimivat saumattomasti selaimessa. Ainoa ero on, että tässä tapauksessa taustalla oleva järjestelmä on selain ja DOM.
Natiivi käyttöliittymän kehys on kuitenkin parantunut nopeasti viime vuosina, ja nykyään ne tarjoavat merkittäviä etuja GWT: n widgeteihin verrattuna. Kun nämä kehykset ovat kasvaneet hienostuneisuutena, yritykset toteuttaa ne JSNI: ssä ovat paljastaneet puutteita yhteentoimivuuskerroksen arkkitehtuurissa. Versiosta 2.7 alkaen GWT esitteli JsInteropin, uuden lähestymistavan, joka perustuu Java-merkintöihin, jonka avulla voit integroida GWT-luokkasi nopeasti ja helposti JavaScriptin kanssa. JSNI-menetelmiä tai JSO-luokkia ei enää tarvitse kirjoittaa. Sen sijaan voit käyttää yksinkertaisesti merkintöjä, kuten @JSType
tai @JSProperty
, jolloin voit työskennellä natiivien JavaScript-luokkien kanssa kuin ne olisivat Java.
JsInteropin täysi määrittely on vielä kesken, ja viimeisimmät päivitykset voidaan kokeilla vain kokoamalla lähde GWT-arkistosta. Mutta on jo selvää, että tämä on uusi suunta, jonka avulla GWT pystyy pysymään mukana kehittyvissä web-alustoissa.
Yksi käynnissä oleva projekti, jossa hyödynnetään JsInteropia, on äskettäin julkaistu gwt-polymeeri-elementit , joka tekee kaikista rauta- ja paperielementeistä Polymeeri GWT: n käytettävissä. Mielenkiintoinen tässä kirjastossa on, että kehittäjien ei tarvitse luoda Java-sovellusliittymää käsin. Projekti käyttää gwt-api-generaattori luoda suurin osa rajapinnoista jäsentämällä Polymer-kirjasto ja JSDoc-merkinnät. Tämän avulla on helppo pitää sidokset ajan tasalla.
Kääntäjän, yhteentoimivuuskerroksen sekä generoidun koodin suorituskyvyn ja koon parannusten ansiosta kahden viime vuoden aikana on selvää, että GWT ei ole vain 'toinen web-kehitystyökalu', vaan siitä on tulossa merkittävä viitetyökalupaketti laajamittaisten, monimutkaisten verkkosovellusten kehittäminen, ja se voi olla jopa erinomainen valinta yksinkertaisempien sovellusten tekemiseen mahtavaksi.
Käytän GWT: tä päivittäin työssäni kehittäjänä ja konsulttina, mutta enimmäkseen rakastan GWT: tä, koska sen avulla voin ylittää selaimen ominaisuuksien rajat ja osoittaa, että modernit verkkosovellukset voivat olla yhtä tehokkaita kuin työpöytäsovellukset.
GWT-projektin yhteisö on todella aktiivinen, ja uusia GWT-pohjaisia kirjastoja, projekteja ja sovelluksia ehdotetaan jatkuvasti. Firenzessä, yhteisölähtöinen GWTcon2015 kokoontuu 11. marraskuuta. Jos olet alueella, toivon, että tulet tapaamaan joitain ydinkehittäjiä ja tutustumaan kaikkiin mahdollisuuksiin olla osa tämän hämmästyttävän työkalupakin kehitystä.