Dnes dopoledne jsem si hrál s Google App Enginem. Protože mám v plánu napsat víc než jen Hello Word, chtěl jsem do hry zapojit i Maven. Hlavně tedy proto, aby se mi staral o závislosti. Nějak jsem si už odvykl kopírovat ručně JARy a hledat jejich závislosti.
A narazil jsem na to, co mě na serverové Javě štve už dlouho, ale teprve dneska mi to tak nějak docvaklo. Dá se to shrnout ve dvou bodech.
- Pro jakoukoliv netriviální věc potřebujete hromadu volitelných knihoven a nástrojů.
- Je složité je dát dohromady tak, aby spolu fungovali.
Jak se to projevuje? Třeba tak, že strávíte několik krásných a zábavných hodin hledáním, které verze, kterých produktů spolu kamarádí. Já mám o Javovském světě docela přehled, s Mavenem si tykám, Eclipse znám jako své boty, ale i tak mi to zabralo skoro celé dopoledne. Jeden z nejpopulárnějších článků na mém blogu byl ten, kde jsem popisoval jak rozjet Hibernate jako JPA provider. Lidé děkovali, že jsem odhalil, které knihovny přidat, aby to všechno běželo.
Jsou dokonce kombinace, o kterých vím, že je dohromady spustit nedokážu. Traumatizující detaily už jsem vytěsnil z paměti, ale myslím že v tom byl zapletený Maven projekt složený z více podprojektů a Eclipse WTP.
A to nemluvím o tom, co se stane když člověk narazí na technologii s kterou nemá tolik zkušeností. Třeba vývojové prostředí, v kterém dokáži bez problému spustit test napsaný ve Scale jsem hledal také pěkných pár hodin. Nakonec jsem skončil u Idei, ale i tam jsem musel do projektu explicitně naimportovat závislost na Scale. Prostě hrůza. A teď si představte člověka, který s Javou jen začíná. Troufám si říci, že nemá šanci.
Nechce se mi končit tak negativně, tak se na tom pokusím najít i pár pozitiv. Hmm. Možnost volby je samozřejmě dobrá věc. Ale chtělo by to lepší podporu. Třeba Maven hodně pomáhá, ale i ten má i po letech pořád svoje dětské nemoci. Navíc jednotlivé projekty si také moc nedávají práci s definicí svých závislostí. To se naštěstí pomalu zlepšuje.
Ono ten problém obecně není jednoduchý. Zkoušíme zkombinovat tři vývojová prostředí, tucet možných aplikačních serverů, několik možných MVC frameworků, několik platformem na backend, několik ORM poskytovatelů a desítky možných databází. Do toho se nám začíná míchat Scala, Groovy, OSGi a Google App Engine, které to všechno komplikují ještě v jiné dimenzi. Skoro si začínám myslet, že se vyplatí být hodně konzervativní a nechat ostatní, ať si ty problémy vyžerou za mě. Ještě že máme ten Open Source a Google. Člověk po čase většinou nějaké to řešení najde. Nedovedu s představit něco podobného řešit na proprietárních platformách, které používá jen pár bohatých zákazníků. To musí být na mašli.
Teď jsme si jedno pozitivum uvědomil. Firmy prostě potřebují lidi, jako jsem já, kteří mají zkušenosti a hlavně žaludek na to se v tom všem brodit. Hurá. Dokonce si tu i přihřeji polívčičku. A to jsem to ani původně neměl v plánu:
Takže pokud máte podobné problémy a potřebujete je vyřešit, neváhejte mě kontaktovat. Desítky let zkušeností, stovky děkovných dopisů. Záruka vrácení peněz samozřejmostí. Bonbóny pro vaše vývojáře v ceně.
Zdravim,
tenhle clanek mi mulvi z duse. Zrovna pracuji na bakalarce kterou pisu v j2ee. Javu sice znam pomerne dobre, ale v j2ee jsem jeste nedelal a musim rict ze zkombinovat maven, jpa, hibernate, springframework a wicket pokud s tim clovek nema zkusenosti a uci se sam je docela brainf*ck :]. IntelliJ Idea s tim nastesti docela dost pomaha ale i tak…zlaty python! :] Jen tak pro zajimavost, zatim jsem napsal cca 1000 radku kodu a trvalo mi to asi 3 tydny :]
No, třeba takový Play framework vypadá celkem jednoduše a použitelně, ale v kombinaci s GAE to je taky ne vždy úplně hračka (vlastní zkušenost).
Taky mi přijde, že J2ME je strašně malá, J2SE je v pohodě a J2EE je taková rozsáhlá a složitá.
Jeden příklad za všechny http://stackoverflow.com/questions/2205648/cannot-use-external-libraries-for-google-app-engine-java-project
Lukáši, to, co píšeš, že tě štve na Javě není ve skutečnosti problém Javy, je to pouze důsledek toho, jak ji vývojáři používají.
Kdyby to bylo jen o psani biznis logiky, tak ma vyvojar mnohem mensi cenu. Mnoho komplikovanych veci uz jde dnes nejen v Jave jednoduse, kdyz se clovek podiva trochu zpatky. Ale diky tomu rostou taky naroky a pozadavky 🙂
Tenhle clanek mi prijde usmevny. Tady se place nad best practic a ze Java je ma dal nez nektere jine jazyky. Takze misto toho aby stahl zacatecnik GAE a zacal kodit vsechno vcetne parsovani XML rucne (coz PHP-kari donedavna delali) a zacatecnici to delaji dodnes, muze jit a najit knihovnu ktera to udela za neho. A samozrejme kdyz uz sezene knihovny a vsechno tak chce mit zaruceno ze mu nejaky nastroj to vsechno da dohromady a nasadi a pokud mozno aby zapis byl jednotny v jednom XML a vygenerovalo mu to i stranku o projektu atd.. A pak place nad tim ze mu to zabere cas, ze ma uzasne krasny kod a uzasne strukturovany projekt, ale samotne nastartovani projektu mu trvalo dyl, nez jeho naprogramovani. No tak proboha na takove projekty tohle nepouzivejte a proste trapne si nechte projekt vygenerovat GAE Wizrdem a nakopirujte knihonvy do war/WEB-INF/lib (kdyz uz teda nejake skutecne moc, moc chcete) napiste deset trid (ktere potrebujete udelat) a projekt nasadte.
Preci proto ze s motorovkou pokacite les, neni potreba si s ni zastrihvavat nechty.
P.S.: Zacatecnik to totiz takhle dela. Knihovny nezna a netravi s jejich hledanim hodiny. Je to neefektivni, je to spatne udrzovatelne, ale to zacatecnikovy zacne vadit az uz zacatecnikem nebude. Pak bude s nostalgii hledet do dob, kdy trema tlacitkama NEXT mel udelany v IDE projekt a mohl zcit kodovat, bez shaneni patricnych knihoven a psani deployment deskryptoru a najeky IoC deskryptoru.
@benzin: Dík za postřeh, takhle mě nenapadlo nad tím přemýšlet. Možná jsem si na tu motorovku moc zvyknul.
ja sa na to pozeram zrovna tak ako benzin 😉
Lukáši, to, co píšeš, že tě štve na Javě není ve skutečnosti problém Javy, je to pouze důsledek toho, jak ji vývojáři používají.