Přejít k navigační liště

Zdroják » Různé » Java na serveru: úvod

Java na serveru: úvod

Články Různé

Java není jen skvělý objektově orientovaný jazyk. Je to i platforma, kterou můžeme použít pro tvorbu svých webových aplikací. Stejně jako ji můžeme použít pro vývoj aplikací pro desktop nebo mobilní telefony. Java je dospělá a léty prověřená technologie, přesto však moderní a stále se rozvíjející.

Přes tyto přednosti se mezi běžnými webovými vývojáři netěší takové oblibě a bývá považována za něco, co patří jen do bank a velkých podniků. Důvod je prostý – prakticky 100% hostingů nabízí obvyklý LAMP (Linux + Apache + MySQL + PHP). Zatímco sehnat hosting pro Javu je složitější nebo přinejmenším dražší. Naštěstí s rozmachem VPS hostingů se situace lepší. Také platí, že prakticky každá větší než malá aplikace dostane dedikovaný server nebo alespoň virtuální stroj. Takže prostor pro Javu tu je. Ale pak zase nejsou lidi, protože jsou všichni odkojení PHP a psaním webů pro LAMP. Proto vznikl tento seriál. Doufám tedy, že se řady českých javistů rozrostou o nové vývojáře.

Stručná historie a popis platformy Java EE

Práce na Javě jako takové začala už v roce 1991, tehdy se jazyk ještě jmenoval Oak. První veřejná verze – Java 1.0 spatřila světlo světa v roce 1995. Specifikace Java Server Pages (JSP) 1.0 byla uvolněna v roce 1999 jako odpověď na ASP a PHP. Dnes jsou aktuální tyto verze specifikací: Servlety 3.0, JSP 2.2, JSF 2.0.

Java EE zastřešuje bohatou škálu technologií. Aplikační server, v kterém „enterprise“ aplikace běží, za nás řeší věci jako např. správu databázových spojení (connection pooling), řízení práv a uživatelských rolí nebo třeba volání vzdálených služeb.

Komu je seriál určen

Předpokládám, že ovládáte Javu SE, proto se nebudu věnovat syntaxi jazyka jako takového. Pokud jste v Javě ještě nic nepsali, ale programujete v jiném jazyce, můžete se pokusit Javu doučit „za chodu“.

Seriál je určen začátečníkům – takže pokud pracujete na pozici Java EE vývojáře, pravděpodobně se tu nic nového nenaučíte.

Cílem seriálu je uvést čtenáře do problematiky Java EE, resp. její malé části, kterou je tvorba webových aplikací. Mějte to prosím na paměti, až budete chtít do diskuse psát o „kanónu na vrabce“ – opravdu to tak někdy bude, ale tématem není: „Vytváříme webovou stránku pomocí úžasného frameworku během 10 minut“. Také se příliš nebudeme zabývat vzhledem aplikace, takže bude, alespoň zpočátku, trochu ohavná, ale nastylování webové stránky pomocí CSS nezávisí na použitém programovacím jazyku a jistě to zvládnete lépe než já.

Aby se dosáhlo velkého, je třeba začít s menším“ – praví klasik, takže budeme zpočátku stavět pouze na standardních prostředcích platformy bez dodatečných frameworků – ty sice usnadní spoustu práce, ale zároveň zakrývají podstatu věci (kromě toho, že by každý z nich vydal na samostatný seriál).

Instalace potřebných programů

K vývoji javových aplikací budeme překvapivě potřebovat Javu, resp JDK. V Linuxu na bázi Debianu nebo Ubuntu si ji nainstalujeme příkazem:

# aptitude install sun-java6-jdk

Zkontrolujeme si nainstalovanou verzi:

$ java -version
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02, mixed mode)

V jiných distribucích je postup obdobný – např. OpenSuse, Mandriva.

Pokud používáte Windows, budete si muset stáhnou instalátor ze stránek Sunu a proklikat se jím.

Poznámka: kromě implementace Javy od Sunu existují i další – hlavně OpenJDK – ve kterých by vám aplikace měla fungovat stejně.

Emacs a VIM jsou skvělé editory, ale pro vývoj v Javě se daleko více hodí IDE. Nainstalujeme si tedy Netbeans. Aktuální verze je 6.8. Zvolíme edici Java nebo All.

Netbeans

Dále budeme potřebovat aplikační server na kterém náš program poběží. Použijeme GlassFish v3, obsažený v instalaci Netbeans IDE.

glassfish

Ukázková aplikace a zdrojové kódy

Během tohoto seriálu budeme společně vyvíjet webovou aplikaci. Ta je sice šitá na míru výukovým účelům, ale nakonec by měla i fungovat. Protože nerad chodím do zakouřených hospod, vytvoříme databázi nekuřáckých podniků. Není to nic originálního, takových stránek existuje spousta, ale pro potřeby seriálu toto téma postačí – je dostatečně jednoduché a snad i zajímavé.

Zdrojový kód si stáhnete tímto příkazem:

$ hg clone http://hg.vps.frantovo.cz/nekurak.net/
$ cd nekurak.net

Mercurial je distribuovaný verzovací systém a pokud chcete aktualizovat svoje (místní) úložiště na verzi, která je na serveru, použijte k tomu příkaz  pull:

$ hg pull

Pro každý díl seriálu vytvořím v úložišti verzi označenou příslušným štítkem. Na úroveň dnešní verze zdrojových kódů se dostanete pomocí příkazu:

$ hg up "1. díl"

Případně si můžete stáhnout danou verzi přes webové rozhraní mercurialu jako .bz2 archiv.

Dnešní díl byl trochu rozehřívací, ale tak to chodí na začátku každého projektu. Cílem je, nainstalovat si potřebné nástroje, zkompilovat aplikaci a nasadit („deploynout“) ji na svůj lokální server. Na http://localhost:8080/…rak.net-web/ byste měli vidět totéž, co na http://nekurak.net/. A příště už začneme vyvíjet.

Odkazy

Komentáře

Subscribe
Upozornit na
guest
117 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
boban

Doufám že se v tomto seriálu dočtu proč bych měl Javu upřednostnit před ostatníma jazykama při tvorbě webu.
Zatím se mi zdá že Java je zatím věc prestiže, pokud by nějaká banka měla internet banking napsanej v PHP,Perlu,Pythonu atp. tak se jí všichni vysmějou protože to neni dost cool a entrprajs soljůšn nad kterym by si mohli kravaťáci honit :)
Na desktopu má Java svoje místo, ale proč jí použít na webu ? Zatím jsem jí poznal jako něco nehorázně pomalýho a náročnýho na prostředky.

Děkuji za případné vysvětlení.

Milan

Naopak Java na desktopu neni moc popularni, pac spatne naprogramovana aplikace ve SWINGu se vetsinou chova line. Jinak je ale Java sakra rychla. PHP a ani Python se ji bohuzel zatim nemohou rovnat.

Na serveru se pouziva hlavne proto, ze vsichni velci hraci maji svuj kvalitni aplikacni server a tim padem garantuji support, nasazeni i na ne-windows platformy (typicky HPUX, Solaris, AIX) a hlavne bezproblemove napojeni na dalsi produkty (typicky Oracle a jine databaze atd.) V tomhle svetle je myslim jasne, proc si ji vybiraji, i kdyz nejake honeni tam urcite bude taky :)

Jara

Java se vam zda pomala a doporucujete Python? To nedava vubec smysl. Klicove slovo: JIT

Almad

Klíčové slovo: Jython! :)

(Souhlas, ten argument nedává smysl.)

Michal Kára

No, tyhle věci se designují většinou objektově a OOP v PHP a Perlu je spíš parodie na OOP (Python detailně neznám). Navíc pro Javu existují frameworky pro podporu clusteringu atp.

Kamil

use Moose;

Jiří Knesl

LOL, OOP v PHP (takovych zkratek?!) je pry parodie na OOP. Muzete uvest, ktera verze PHP ma tu parodii na OOP a jak se zapina? Ja ji tam marne hledam a nic. :)

Vebloud

Parodie na OOP v PHP je už jenom to, že muselo přijít něco jako late static binding. Což je věc v jiných jazycích naprosto samozřejmá. Nicméně od verze 5 už to s objekty vcelku jde, ale to oba moc dobře víme. Stejně tak víme, že na Javu to nemá což souvisí i s netypovostí PHP, ale to je věc jiná.

Ped

„internet banking napsanej v PHP,Perlu,Pythonu atp.“

Krome pythonu jste prave vyjmenoval veci ktere jsou tak v prumeru 100× pomalejsi nez Java, python je taky pomalejsi, ale uz to neni tak hrozne.
Presto pokud se jedna o velkou aplikaci s mnozstvim online klientu, tak i rozdil python vs java muze znamenat znacne uspory na HW.
I ja osobne myslim ze python by teoreticky bankovnictvi zvladl, i na enterprise urovni.
Prakticky nema sanci, Java je standart a vetsina firem ktera dela „enterprise“ (velikosti a cenou) reseni ma spoustu Java inzenyru, metodiky nastavene na Jave EE v propojeni na jine „enterprise“ technologie a jeste si nad tim kravataci muzou honit. Python by zvladli leda hodne nadane a sikovne mlade stiky a museli by prave udelat spoustu prace i na sladeni se zbytkem „enterprise“ sveta (napsat samotnou aplikaci v pythonu by urcite nebyl ten zasadni problem).

Java neni nehorazne pomala. Na desktopu JVM startuje nehorazne pomalu a v jeji GUI je vetsinou linejsi nez nativni aplikace, ale kdyz treba udelate v java aplikaci nejake narocne matematicke vypocty nad udaji z DB, tak se rychlost vypoctu proti nativni C++ nebude nijak zasadne lisit (+20% max bych tipoval, ve specialnich pripadech je Java rychlejsi). Zkuste to same v PHP a jste minimalne na 50ti nasobku nativni C++.

.

Java neni zadny standart nikde na svete. Co jste napsal, je totalni nesmysl.

Vykook

Standart urcite neni, ale standard de facto je.

Vykook

Pardon, nevsiml jsem se ze uz vy s tim standarTem rejpete, jsem blb :)

honza

To je jen narážka na chybu t/d nebo se za Vaším příspěvkem skrývá nějaká hlubší myšlenka, kterou jesm nepochopil?

.

Co jste delal na zakladni skole?

honza

Tak různě. Můžete mi prosím odpovedět? Já to opravdu nechápu, protože jádro sdělení p. Helcmanovskeho mi připadá rozumné. Dík.

.

Malo asi vas ucili v te skole, kdyz nevite, ze slovo standart v cestine neexistuje. Maximalne tak standarta, ale to uz je neco jineho…

honza

Vždyť jsem se na tu chybu v ‚t‘ ptal hned na začátku. Takže to chápu dobře, že tím „Java neni zadny standart nikde na svete. Co jste napsal, je totalni nesmysl.“ jste myslel to, že má chybu ve slově standard? BTW todle poučování sedí od člověka, co se ještě nenaučil používat nabodeníčka:)

Ped

Ucil som sa po Slovensky. Az vasa Slovencina bude na urovni mojej Cestiny, dajte mi prosim vas vediet. Dakujem za pochopenie.

Martin Malý

Nie som nijaký taký komentárový bitkár, no som si celkom istý, že aj po slovensky je to „štandard“ a nie „štandart“. (Môže byť takto? Hádam že moja Slovenčina je na rovnakej úrovni ako vaša Čeština, len s diakritikou. Ja som sa učil po Česky a verte mi: V tom to naozaj nie je… „Standart“ je chybne v obidvoch jazykoch. Nabudúce dajte dajakú lepšiu výhovorku, áno?) :)

alef0

V slovenčine je spisovne <b>štandard</b> v zmysle

,,bežná (dobrá) úroveň, ustálená miera: (mať) vysoký, nízky štandard, životný štandard, dosiahnuť štandard“.

A bokom :-): V slovenčine sa ,,slovenčina“ i čeština píšu malými písmenami.

,
alef0

Java ma medzi prostym ludom povedomie „vsak to je pomale, v zivote by som v tom nevyvijal, jak v tom mozete robit portaly“ a medzi normalnymi a triezvymi vyvojarmi skor „je to stabilny jazyk s tonou kniznic, ktory ma perspektivu, po vyvojaroch je dopyt, a tak skoro nezmizne z povrchu zeme“

Zmyslanie ,,kravataci honia“ je asi take relevantne ako „php je pre lama userov, ktori po mesiaci netusia co naprasili, a udrziavat ich kod je nemozne.“

Moje vyhody:

1) povedomie. Mate stabilnu uzivatelstku zakladnu, mate zakaznikov, ktori platia, mate tisicpatsto serverov a pat ton priruciek.
2) stabilita-konzervativnost. Ono ta striktnost, ukecanost, a silne typovanie sa vyplaca, lebo sice stracate cas pri pisani kodu, ale ziskavate cas pri jeho udrziavani. Platforma je stabilna, az konzervativna a zmeny medzi verziami su len malokedy kriticke. V zakladnej platforme sa veci aktualizuju az extremne pomaly, na druhej strane je vyvoj pomerne premysleny a rozhodne nie v duchu chaotickeho ,,toto sa nam paci, tak to tam kydneme“.
3) kniznice. Mate kniznice na vsetko mozne i nemozne, miestami az tolko, ze si neviete vybrat. Tie kniznice su velmi casto precizne vymyslene a na spici vyvoja a programovaco navrharskych technik.
4) nastroje. (zdoraznil by som). Mate na vyber tri vyvojove prostredia (IDE), ktore su miestami najlepsie bez ohladu na jazyk. Ladiace nastroje, ktore funguju, unit testovacie nastroje.

(Inak toto prepletene plati aj pre .NET)

logik

Jeden z důležitejch důvodů, který nezazněly, je, že zatímco php je skriptovací jazyk, zatímco JAVA je aplikační server. Zatimco PHP vytváří konzistenci pomocí
serializace do textovejch souborů (která nejde rozumně použít pro zachování celýho stavu velký aplikace), tak JAVA umožňuje mezi dotazama si uchovávat
kompletně celej stav aplikace.

PS: Píšu v PHP :-) takže to neni plyvání na php, ale uznaní jeho omezení (a trochu frustrace z nich)

alef0

Java nie je aplikačný server. Java je platforma, teda virtuálny stroj + jazyk.

Realita sa má tak, že v prípade webových aplikácií je model vykonávania rozdielny.

Zjednodušene povedané:

PHP vezme skript, požuje ho, a vypľuje výsledné HTML. S každým behom sa skript načíta a vykonáva nanovo. Stav medzi spusteniami skriptu sa musí uchovávať inde.

V prípade Javy beží v aplikačnom serveri servlet (čo je nič iné než inštancia preddefinovanej triedy), ktorý obsluhuje požiadavky. Servletu sa typicky vytvorí raz pri spustení aplikačného serveru a príslušnej webovej aplikácie. Uchovávanie stavu je potom jednoduchšie.

b*d

více méně máte pravdu, jenom je potřeba dodat kterého stavu. Protože ani u PHP neudáváte zachování stavu mezi klientem a serverem (session) nelze Vám nic vytknout.
Jde o to, že instance servletové třídy nemusí být přesně jedna (nemusí být vytvořena vůbec, nebo několikrát). Pokud uchováváte stav aplikace v servletu – což je opravdová výhoda Javy (Správněji webového kontejneru). (Web/HTTP) Session je naproti tomu uchování stavu clienta, nikoliv serveru.
A také je to past! Je potřeba tzv. synchronizovat přístup k tomuto stavu!

Možná vysvětlit na příkladu:
každý stý dotaz chci, aby barva pozadí byla červená. V aplikačním serveru jednoduché, v PHP které existuje tak dlouho, jak se vyřizuje request se většinou volá db/subor atp., která právě zařizuje ono udržování stavu.

pr.rybar

K tomu prikladu.
Ak restartnete aplikaciu, asi tym resetnete stav pocitadla. Ak Vam to nevadi, vyuzili ste vyhodu Java servletu v svoj prospech. Ale takyto pripad je pomerne zriedkavy v realnych aplikaciach.
Inak suhlasim.

b*d

Tak mně šlo o to, nějak ukázat co mám na mysli. Mohl bych dát příklad, kdy se aplikace „skoro sama“ konfigure podle toho, kde je deploynutá. Ale to zní moc magicky.

Teď mně napadlo jedno bezva vypíchnutí Web Container + Java Mail knihovna versus App Server:

Odeslání registračního emailu behem registrace uživatele (requestu) může poměrně dlouhou dobu trvat (třeba řádově sekundy) s nejistým výsledkem.
Ve web containeru buď ona stránka trvá o něco déle a chyba se ohlásí uživateli (thread je v block režimu), nebo udělám paralerní frontu a budu programovat zámky.
Oba přístupy mají problém: 1) blokuje se thread a zdroje 2) pokud server spadne při plné frontě

V applikačním serveru si vytvořím message beanu (JMS) návrat je okamžitý, email je odeslán do fronty JMS a poslán, až když na něj příjde řada. V budoucnu můžu velice jednoduše přehodit SMTP server někam jinam, nebo jich mít třeba 100 (na každý přihodím applikační server jenom s listenerem a jeho logikou dané queue). Díky managementu applikačního serveru (Java Management Extension) to můžu provést online.

O message beanech spojených s asynchroním AJAXem a JSF, popřípadě Cometd.

alef0

Bez JMS by ste mohli INSERTovať do tabuľky a nejakým paralelným skriptom mimo aplikácie posielať tie maily.

Ale presne to je na Jave krásne, že vhodnú implementáciu schováte za interfejs a idete, celú ju vyskladáte pomocou dependency injection a prípadne v extréme konfiguráciu prehadzujete dynamicky.

Inak ten príklad s mailami je nádherný :-)

pr.rybar

Ine riesenie toho odosielania mailu:

Odosielanie mailu bude volanie REST web sluzby. Zmenou jej URL (hoci za jazdy) mozem presunut odosielanie kamkolvek. Skalovanie tej mailovej sluzby je hracka.

A co som potreboval na to aby moja web aplikacie vykonne a jednoducho odosielala maily? No iba nejake to JAR s HTTP client lib.

Vyhodou REST riesenia je ze mailova REST sluzba moze byt v lubovolnej technologii (php, python, Java, kludne aj Google App Engine).

Dalsou vyhodou je ze takato web aplikacia potrebuje pre beh iba servletovy kontajner.

Dalsou vyhodou je trivialna implementacia.

Naco je mi obrovsky kontajner s mohutnym stackom technologii v ktorych sa pomaly nikdo nevyzna a koli ktoremu ako firma potrebujem zaplatit drahych EE „konzultantov“, kupit kopu zbytocneho HW?
Presne o tomto je REST. Google to vie, enterprise ludom to este nedoslo?

b*d

došlo, proto by nebyl spring aj. Jde ale o refactoring kódu. Sice vám bude stačit ze začátku jedna http knihovna, ale pak začnete řešit serializaci atd.

V EJB můžete použít i REST, Webservices cokoliv, ale z pohledu vaší aplikace je to kód v javě nikoliv text.

Na okraj v JMS proti službám jde o messaging, takže se udělá lokální broker ten se napojí do sítě brokerů a příjemce poslouchá na svém lokálním brokeru. Pak tu jsou ještě věci jako doručení v FIFO atd. atd. A všechno pěkně od jednoho vendora třeba Red Hatu (ten ještě umí i OS takže máte total coverage).

V entreprise světě vybíráte implementace/služ­by/OS/HW nikoliv co je technologicky cutting edge, ale co Vám pokreje zadek tím, že odpovědnost delegujete třeba na RedHat.

Tedy nediskutujete s IT oddělení, ale s právním oddělením! Když google služby spadnou je to tragédie, ale pokud Vaše enterprise služby spadnou může to být otázka života a smrti (pro vaši firmu).

Ono je hezké říkat používá to ten Google to musí být super-duper. Jenže jakou má Google s váma smlouvu?

A vlatně tenhle tutoriál ukazuje proč má EE/Aplikační server důvod žít. Pokud se vezme pouze kontainer, noob pustí demo a stránka se načte za pár sekund. Řekne si „dobře, fajn, zahřívací kolo!“. Dá refresh a stane se to samé. Napíše někam (do diskuze) a zeptají se ho a čím děláš pooling db spojení? A noob se vrátí k PHP.
Aplikační server má už pool v sobě, není třeba dodávat extra.
Další výhoda je opravdová znovupoužitelnost kódu na základě konfigurace, příklad: mám aplikaci běžící v Čechách, na Slovensku a Maďarsku – jsou !podobné! 90% stejného kódu, 10% jiného. Pokud progamuju service, vytáhnu si DB spojení z JNDI přes stejné jméno. Teprve na každém serveru si upravím vlastní db. Ale Slovensko a Česko běžím na stejném app. serveru (u hostingu je Slovensko lepší tarif)
Použiju přejmenovaní v deploy descriptoru a ear beží beze změny.

Jiný příklad – vy programujete, hosting dělá 3 strana (stará se o servery atd.) Teď udělejte applikaci tak, aby ji vzali a přes rozhraní ji zkonfigurovali.
V app serveru díky JNDI a JMX poměrně hračka!

Teď mi namítnete: Ano i tohle všechno můžu udělat „pouze v containeru“!
Ale až to doplníte logiku a zobecníte ji, nestane se z vašeho kontaineru aplikační server?

pr.rybar

Zvacsa s Vami suhlasim. Nejde mi ale do hlavy, preco pouzuvat EE ked to nepotrebujeme.
Preco si v seriali najskor nevysvetlime ako funguje servletovy kontajner, ako sa s nim pracuje a potom si nepovieme nieco o tom Java EE. Takto ti, ktori si preciteju tento serial budu z celeho Java EE totalny magori, ktori nerozlisuju servletovy kontajner od aplikacneho kontajnera.
Taketo vysledky potom vidiet v praxi.

Priklady z mojej praxe:
1) novo prijaty abrsolvent MFFI UK, prijaty ako Java junior, mi na 3 den po tom ako sa do neho snazim natlasit zaklady prace so servletovym kontajnerom na moju ziadost o kompilaciu projektu s uzmevom na tvari prezradi, ze java je interpretovana a ze kde som to videl aby sa kompilovala. Na moju otazku ako doteraz spustal co v jave naprogramoval odpovedal stroho „klikol na tlacitko run v eclipse“ (podobne zacina nas serial). :(
Keby ho tu javu ucili na zaciatku v prikazovom riadku a z textovym editorom, asi by tomu aj rozumel.
2) novoprijaty absolvent FIIT STU, prijaty ako Java junior a expert na JSF a JavaEE mi po dvoch dnoch trapenia prezradil, ze ta JSF „hello world“ stranka sa mu stale nedari. Po tom ako som mu do Tomcatu nahodi JSF (ktore tam nemal a asi o tom ani nevedel napriek chybovym hlaskam) mi po dalsich 3 dnoch prezradil ze to nefunguje. Netusil, ze JSP je iba prezentacna vstva a ze tam je najaky zivotny cyklus, …
Ako robil (ak ju vobec robil) tu aplikaciu, ktorou sa chvalin na prijimacom konani managerovi som s neho uz nedostal. :(

Neviem ako u Vas, ale u nas takto koncia 2/3 novych ludi.
Mimochodom vyrazne najlepsi co sa tyka znalosti webu a IT u nas za posledne roky je clovek, ktory vystudoval fyziku.

b*d

Bohužel musím Vaše slova jenom potvrdit. Bohužel, ze zadaných projektů nováčkům za posledních 4 roky se nenasadil ani jeden! A to nejde o nějaké EE a kde si co si na to stačilo SE a více méně výstup do konzole.

Školství dost težce selhává. Jen tak mimochodem, já jsem studoval taky fyziku a ne IT. Za těch nedávných dob se ITáci učili svařovat!

alef0

Nie som si istý, či je úlohou univerzity tlačiť do absolventov všetky technológie – často na to neexistuje priestor. Plus, mnohokrát sa čaká, že škola zadarmo vyškolí absolventa zadarmo, pričom inde sú za pokročilé kurzy netriviálne peniaze. V extrémnych prípadoch sa čaká, že zo školy vyjde človek s certifikátmi zo Cisca, Javy, .NETu, SAPu a Windowsu, ktorý navyše produkuje vedecké výsledky.

Navyše, školiť môže typicky len človek, ktorý má dosť skúseností a vôľu to robiť, resp. ho niekto za to zaplatí – a tým niekým škola obvykle nie je. Pri univerzitných platoch to je možné len u povestných fanatikov.

Treba si urobiť prieskum, kto z pokročilých znalcov IT sa naučil práskať technológie v škole – trúfam si povedať, že tí najšikovnejší to dosiahli samostatným sitzfleischom. (Určite aj vy, keďže vedomosti o zváraní v IT technológiách využijete azda len nepriamo a deficit ste museli nejak dohnať.)

dc

S tymto suhlasim. Nehovoriac ze uz aj u nas sa zacina prejavovat specializacia a aj samotne technologie zacinaju byt tak rozsiahle ze sa to neda vsetko zvladnut.Napriklad co by mala skola vybrat na vyuku? Javu alebo .NET ? V podstate su to porovnatelne technologie ale obe su pomerne rozsiahle, zvlast ked sa postupne zahrnie cela platforma a popripade aj nejake to majoritne portfolio aplikacii a frameworkov na nich postavene. Alebo pri webe Javascrip vs Silverlight vs Flash/Flax ? Zase su to technologie ktore riesie ten isty problem ale kazda inak. Ale to uz je OT.
Inak serial vyzera fajn uvidime co sa z toho vyvrbi :-)

pr.rybar

> Nie som si istý, či je úlohou univerzity tlačiť do absolventov všetky technológie.

Mate pravdu to ulohou skoly nie je. Ulohou skoly je aby abslovent informatiky mal dobre teoreticke vedomosti aspon zakladne prakticke. Ak sa skola rozhodne ucit nejake pokrocilejsie technologie, nech to robi poriadne.
Casto sa v praxi stava, ze s novym clovekom zaciname vetou „Zabudni na to co ta v skole ucili, naucili ta to zle“. A zaciname pekne od zakladov.

Spomeniem citat byvaleho kolegu, absolventa FMFI: „Ja som teoreticky informatik, ja nemusim vediet programovat.“ Skutocne bol velmi slaby.
To je ako keby teoreticky fyzyk povedal: „Ja nemusim vediet pocitat“.

V zvysku s Vami suhlasim.

alef

Informatik v praxi, čo nevie programovať, je smutný praktický informatik. (Mám na mysli aspoň základy štruktúrovaného programovania, OOP, plus azda prehľad v paradigmách iného programovania.)

Teoretický informatik si uplatnenie v súkromnom sektore nenájde, ale zase môže skúmať ;-)

Osobne mám ešte skúsenosť s jedným javom: technológie sa učia, ale len spôsobom letom svetom (,,toto existuje, bližšie info nájdete tam“) a je potom na študentovi, čo si z toho odnesie, resp. naštuduje.

Skúsenosti, že sa niečo explicitne učí zle (teda že sa učia bludy), nemám. Ak, tak zážitok, že časom sa ukáže, že sa vec dá učiť iným, prínosnejším, spôsobom.

Láďa

Na tvorbu webu se opravdu dají najít lepší nástroje než Java, ale to je první a poslední správný názor – zbytek jsou nesmysly.

rooobertek

A ja som si dal novoročné predsavzatie, že sa dostanom zo spárov PHP a naučím sa Javu :) Díky moc

K-Kamil

Java ako taká je dosť low-level jazyk, čo po čase človek zistí tým, že vela píše a málo tvorí. Ale má dobrú virtuálnu mašinu JVM, ktorá sa dá využiť cez jazyky ako je Groovy, JRuby, Scala a iné.

rooobertek

Je mi jedno, aký jazyk to je, ale keď si pozriem inzeráty a porovnám „hľadáme phpčkara“ a „hľadáme javistu“, vyhráva java, o peniazoch ani nehovorím
Asi je to dosť krátkozraký pohľad, ale nechajte ma snívať :)

ahl

>Java ako taká je dosť low-level jazyk
To bych nevěřil, že si někdy něco takového přečtu:)

Láďa

Tipuju že 95% lidí, kteří mají možnost srovnat Java vs. Pyhon/Ruby, bude souhlasit :-)

Satai

Pletete si high-levelnost s expresivitou.

multi

To vypada na fakt nadupany serial.

Me osobne by zajmal i pohled pod poklicku – ne jen ve stylu tady se klikne a ono to pak je na serveru.

Take by me zajmalo pouziti i jineho aplikacniho serveru a IDE (navic NetBeans nemusim), ale mam dojem ze Glasfish a NetBeans jsou asi v JavaEE v cele vyvoje?

rooobertek

Ja som na PHP používal eclipse aj netbeans. Eclipse je síce fajn, ale keď si zmyslí, že zatuhne, to môžem ísť na kávu. A keďže kávu nepijem, prešiel som na netbeans.

MD

Ano, taky by me zajimala i jina konfigurace nez netbeans na linuxu. Neco obecnejsiho, toho je moc konkretni (?)

Melme

No vcele vyvoje nejsou. Jde o produkty preferovane Sunem. A jednak pokud si stahnes jeden balik z netbeans.org tak mas vse pohromade. DB, IDE pro vyvoj i Glassfish. Popripadne jednoduzsi Apache Tomcat. Tim padem pro nauceni se zakladu je to dobra volba nemusis nic konfugurovat.

xtonda

tomcat je ale jen servlet container, ne plnohodnotný JavaEE server.

b*d

takové rýpnutí: doplň openEJB a je to?

Franta to umí, četl jsem od něj pár tutoriálů a jsou velmi dobré.

Pro začátečníky nemohl udělat lepší volbu. JDE o to, že je všechno pohromadě. Pro jednoduché příklady nedocenitelné.

Otázkou je, kam chce směřovat dál.
Druhou otázkou je, jestli by nebylo lepší pro přechod PHP2Java zvolit JBoss Seam nebo jiný CRUD framework.

Mr.Dan

Jine IDE pro Javu je treba Eclipse.
Mezi uzivateli Eclipse a Netbeans je urcite rivalita, jako mezi uzivateli KDE nebo Gnome, ale v zasade je to vsechno hlavne o zvyku. Takze neposlouchej nikoho, kdo kritizuje/vychva­luje jedno, protoze stejny pocet lidi kritizuje/vychva­luje zase to druhe :-) a pritom je to prast jak uhod.

Pokud jde o aplikacni servery pro JEE, tak treba Tomcat, Jboss, WebSphere (to uz je pro jednotlivce kanon na vrabce)

ze by bylo neco v cele vyvoje, si nemyslim. ja osobne jsem si zvyknul na Eclipse (v tomhle si snad vyvojari vetsinou voli sami) a aplikac se ruzni projekt od projektu

ahl

Já bych rozdíl mezi eclipse a netbeans viděl, tak že netbeans se nainstalují a prostě fungují, kdežto eclipse jsou spíš taková skládačka. Pro netbeans existuje celkem málo pluginů a jsou skoro všechny vytvářené autory netbeans. Eclipse je více rozšířený a spousta vývojových nástrojů je distribuovaná jako plugin do eclipse. Hlavní výhodou netbeans je tedy kompaktnost, kdežto u eclipse je to modulárnost a možnost přizpůsobení. Svojí funkčností jsou ± stejné.

uf

NetBeans je take slozen z pluginu. Na prednasce to pekne porovnali a zjistilo se, ze se resi stejne veci podobnym zpusobem a jsou jen jinak pojmenovane.

NetBeans ma vsechno (volitelne) v instalaci, je intuitivni a prirozeny. Eclipse se musi neprirozene zadrit. Kdo si zvykne, uz nechce nic jineho. Z podobneho duvodu jako Eclipse se mi nelibila vyvojova prostredi Borlandu. Mam pocit, ze delfaci presli na Eclipse. Eclipse mel driv silnou podporu editace.

Radsi stahnu instalaci, vyhazim, co nepotrebuju nebo zvolim mensi instalaci pro stazeni, nez abych si natahl IDE a pak po vsech certech shanel, jak se jmenuji a kde jsou moduly. Ty do NB taky dodavam z update centra.

No flame please. Jen aby tady nezustal hloupy nazor, ze NB neni skladacka. Timhle zpusobem se drzi povera, ze je java pomala – protoze to pro 1.1.x byla pravda.

ah01

> Pokud jde o aplikacni servery pro JEE, tak treba Tomcat

Nevím jestli to bude pro tento seriál důležité, každopádně, Tomcat není plnohodnotný aplikační server, ale pouze webový kontejner (implementuje jen část JEE nutnou pro web – Servlety, JSP). Servery jako GlassFish nebo jBoss toho umí mnohem víc.

pr.rybar

> Servery jako GlassFish nebo jBoss toho umí mnohem víc.

A co z toho „mnohem víc“ potrebujeme pre webovu aplikaciu?

Vykook

Pro webovou aplikaci tutorialovy slozitosti asi nic, ale jinak z te mnoziny „mnohen vic“ vyuzijes pomerne mnoho.

pr.rybar

Cakam na ten dlhy zoznam.

Ti co robili Google AppEngine si asi nemyslia to iste co vy :(

ah01

ad aplikační server:
Docela pěkně to myslím shrnuje článek: Tomcat Today, GlassFish Tomorrow?

Pár příkladů z toho balíku „mnohem víc“, které užijete i na menších aplikacích:

  • EJB (pomůže vám oddělit business vrstvu od prezentační vrstvy),
  • JPA (persistence dat),
  • JSF (komponentový přístup k tvorbě webového rozhraní),
  • máte přímo k dispozici všechny knihovny z JEE (např. JavaMail pro práci s e-mailem).

ad Google App Engine
GAE není zrovna typický příklad Javy na serveru. S trochou nadsázky se dá říci, že je to Java ohnutá tak, aby se dala použít nad Googlí infrastrukturou. Z toho důvodu prostě ani nejde, aby GAE podporoval celé JEE. Ale třeba JPA (persistenci dat) tam najdete. Viz sekce JEE na Will it play in App Engine.

pr.rybar

http://java.dzone.com/articles /glassfish-and-tomcat-whats-the
Page not found

– Aplikacna logika moze byt vo forme JAR ma to vela vyhod.

– JPA sa neda len tak pridat do aplikacie v Tomcate?

– JSF? :) Aku verziu toho humusu mate na mysli?

– JavaMail je tiez iba JARko a teda kniznica, alebo nie?

Co mi teda dava aplikacny server navyse?
Iba to ze tam mam nahadzane veci ktore nikdy nevyuzijem?

xtonda

EJB, JMS, JTS, JNDI. to že to nedokážeš využít není chyba těch technologií.

pr.rybar

Mam to chapat tak ze ako dobry JavaEE vyvojar sa v kazdej web aplikacii snazite vyuzit co najviac (idealne vsetky) z vami menovanych technologii?

pr.rybar

> Vždyť to EJB je nakonec taky .jar

Mal som pod pojmom JAR na mysli java archiv pouzitelny ako kniznicu a nie archiv nasaditelnej aplikacie.

Dalsie nedorozumenie je asi ze nemame dobre definovane pojmy.

Webovou aplikaciou rozumiem aplikaciu, ktora je v servletovom/we­bovom kontajneri. Ak mame webovu aplikaciu, ktora ma biznis logiku v aplikacnom kontajneri, nic to nemeni na skutocnosti ze pre jej beh staci servletovy kontajner. To, ze je jej logika v aplikacnom kontajneri beziacom v tom istom, alebo inom servletovom kontajneri nez ona sama je vec druha.

Inak s Vami plne suhlasim.

alef0

Existuje nejaka oficialna definicia aplikacneho serveru?

Samozrejme, mozno argumentovat, ,,ze aplikacny server je ten, ktory podporuje primerane dost velku cast JEE)“,

ale namiesto EJB vezmete Spring, namiesto JSF Spring-MVC, namiesto JPA Hibernate a mate rovnaku funkcionalitu… ibaze to uz nebude aplikacny server?

pr.rybar

> Existuje nejaka oficialna definicia aplikacneho serveru?

Dobra otazka.
Nie je to tak, ze niekto vezme servletovy kontajner, nastrka tam kadeco a potom to vola aplikacny server?

Servletovy kontajner ma jasne definovane rozhranie, ktore mi umoznuje prenositelnost aplikacii na inu implementaciu servletoveho kontajnera. Dolezite je, ze ma referencnu implemntaciu (Tomcat), aby bol nejaky etalon, aby sa tak predislo pochybnostiam a divergentnym vykladom funkcionality.

Ma aplikacny server taketo dobre definovane rozhranie?
Ak nema, nehovorme o aplikacnom serveri ale o servletovom kontajneri a tom, co je na nom nainstalovane a budeme si rozumiet. :)

alef0

Neviem, to podľa mňa nevie nik, súdim, že ,,aplikačný server“ je pojem, ktorý má buď mnoho významov, alebo sa používa v zmysle ,,aplikačný server JEE“ alebo ako synonymum ,,kontajnera“, resp. v zmysle ,,aplikačný server je niečo v čom bežia aplikácie.“

Ale to je môj tip.

Ale samozrejme, hádka o tom, či je Tomcat aplikačný server alebo nie, je zbytočná a v oku pozorovateľa. Tomcat je nepopierateľne servletový kontajner, a rozhodne nie je JEE aplikačný server.

Ono je aj tak vo väčšine prípadov jasné, že keď je reč o Tomcate, tak všetci vedia, čo to je, a netreba mlžiť vzletnými ,,overloaded“ pojmami.

Milan

Jak webovy container, tak enterprise container musi implementovat danou specifikaci, aby vubec dostali certifikaci.

Hlavni rozdil je v podstate ten, ze enterprise server muze slouzit take jako container pro EJB + umi asynchroni zpravy pres JMS.

Vetsinu ostatnich veci, jako transakcni manager, connection pooly, JNDI adresar atd. atd. lze v nejake podobe dostat ci emulovat i v obycejnem webovem containeru.

Jak napsal kolega vyse, tak v dnesni dobe opravdu staci Spring a muzete delat enterprise aplikace i bez aplikacnich serveru klidne na tom tomcatu (i kdyz ja spise preferuju jetty).

xtonda

Je JavaEE specifikace a certifikace aplikačních serverů vůči této specifikaci, aplikace naspaná podle této specifikace pak poběží, na libovolném AS splňujícím specifikaci.

b*d

No takhle vlastně vzniknul Spring (Java EE bez EJB). Více méně se oba názory střetly a výsledný produkt je JavaEE/5 a 6.

Není pravda, že EJB = Spring. Spring v základu je jenom injection container. Vůbec nemá ponětí o EJB, JNDI, Remotingu.

Stejně JSF != Spring MVC. To je hodně o něčem jiném.
JPA je spec. Např. hibernate lze použít pro JPA (Jboss).

Právě přemýšlím jestli je správná cesta začínat od spodu:

@Entity
public class Uzivatel
{
@Basic
String jmeno;

@Basic
String prijmeni;


}

Není jednodušší než nastavování Hibernate v čisté web containeru. Ale Franta vzal App Server! Ten už to má vyřešené.

Valná většina věcí má nějakou specifikaci (třeba JSR) a o to jde. A některé i obecně závazné certifikace.

Například Sun Java má FIPS certifikace a to ve vývoji/prodeji např. pro banky tak důležité, že každý kravaťák třikrát vystříkne.

FIPS dává NIST, americká organizace, která mezi jiným kontroluje kvalitu implementace šifrovacích algoritmů – jestli kód který se tváří jako SHA-512 odpovídá normě SHA-512.

Jako firma se na to často odvoláváme. PHP jsem mezi certifikovanými dodavateli neviděl, Python jak by smet.

alef0

Samozrejme, že je mnoho situácií, kde certifikácia, dohodnuté technológie, a argumentácia štandardmi zavážia, to je bez debaty – to je tá stabilita čo som spomínal vyššie.

Ide o to, že mnohokrát (a hlavne v prostrediach, kde je väčšia miera voľnosti
môžete získať rovnakú funkcionalitu aj inak než v JEE.

Videl by som hrubú analógiu v podobe ,,kúpite si PC zostavu“ vs „vyskladáte si PC zostavu“ kde musíte investovať čas, ale zase získate lepší výkon či vyššiu pohodlnosť vývoja.

Nechcel som porovnávať bod po bode jednotlivé súčasti, lebo v mnohých ohľadoch sú ekvivalentné len zďaleka alebo jedno vzniklo abstrakciou druhého alebo riešia ten istý problém, ale totálne odlišne (Spring MVC vs JSF sú dva vcelku odlišné svety, JPA vzniklo sčasti abstrahovaním Hibernatu atď, JDNI sa často dá nahradiť dependency injection, remoting je urobený inak).

b*d

Ano dá se to nahradit a springem to runtime slepit dohromady a mavenem při buildu. Jenom jak aplikace roste, aby jste nedal přednost Java App serveru, kde to máte od někoho jiného už vše v jednom. Třeba to zase naopak zlepší vývoj tím, že je přístup obdobný, je tam management (JMX) atd.

Ale bavíme se o minimálně Jave EE 5! Před tím mělo lepení opravdový smysl. Container managed persitency, EJB-QL, java1.4.2 ještě, že jsou tyhle časy dávno pryč.

pr.rybar

> ad Google App Engine
> GAE není zrovna typický příklad Javy na serveru

Teda ako som povedal, Google App Engine JE standardny servletovy/webovy kontajner! Navyse je tam par rozhrani navyse, ako Java Data Objects (JDO), Java Persistence API (JPA), JavaMail API.

http://code.google.com/…pengine.html
You can develop your application for the Java runtime environment using common Java web development tools and API standards. Your app interacts with the environment using the Java Servlet standard, and can use common web application technologies such as JavaServer Pages (JSPs).

Neplette si webovu aplikaciu a enterprice web aplikaciu ako vacsina diskutujucich.
Uvedomte si prosim, ze enterprice web aplikacia je zlozena z webovej aplikacie, ktora pre svoj beh vazne potrebuje IBA servletovy/webovy kontajner a z casti beziacej v aplikacnom kontajneri.
Ak sa vo webovej aplikacii, teda v jej logike, rozhodnete vyuzit nejake ine API, alebo JavaEE komponenty, je jasne, ze musite zabezpecit aby vo webovom kontajneri boli pritomne tieto API, alebo nasadeny aplikacny kontajner.
Mnohi vyvojari vyvyjajuci JavaEE aplikacie si neuvedomuje vyssie uvedenu skutocnost.

Vykook

Presne tak, nehlede na to ze zrovna ten GlassFish obsahuje i Tomcat ;-)

xtonda

Výborné IDE je IntelliJ IDEA (komerční), korporace často používají aplikační server Oracle (dříve BEA) Weblogic. V tomhle dělám já.

alef0

IntelliJ IDEA má po novom community edition, ktorá je zadarmo, a na vývoj v základnej Jave asi stačí.

xtonda

Community ale podporuje jen JavaSE, což je vzhledem k tématu článku nezajímavé.

alef0

Otázka je, čo pre vás znamená ,,podporuje“. Podpora často znamená ,,prívetivé používateľské rozhranie“, resp. ,,to, čo iný spúšťa z príkazového riadku / konfiguruje manuálne, vy naklikáte“.

Na vývoj normálnej webovej aplikácie pokojne stačí samostatne bežiaci Tomcat v debug režime, ktorý periodicky kontroluje, či sa daná aplikácia zmenila alebo nie a v prípade potreby ju znovu nasadí. Do projektu som si zatiahol JARy s API pre servlety a nebol problém.

IDE vám to môže uľahčiť – môže mať v sebe už zabudovaný servletový kontajner (Tomcat), spúšťanie sa rieši jedným tlačidlom, triedy sa automaticky reloadujú, máte priamo nakonfigurovaný debugger, servlety pridávate cez sprievodcu.

Rozdiel medzi JEE a JSE je v sade knižníc ktoré si pridáte do projektu, v ničom inom. Vyvíjať JEE môžete v hocičom (webovú aplikáciu pre diplomku som vyvinul v Geli, čo bolo IDE na úrovni lepšieho Notepadu, niežeby som to chcel robiť naďalej).

Richard

1. Existuje asi 100 spôsobov ako v Jave vyvíjať web. Skoro vždy sa použije nejaký framework, ktorý významne mení spôsob prácu na vývoji. Niektoré frameworky dokonca ani nepoužívajú JSP stránky. Priamo pre Javu existujú aj framewroky, kde sa v podstate neprogramuje v Jave ale v niektorom inom scriptovacom jazyku. Dokonca aj weby čito urobené vo Flashi (Silverlighte, JavaScripte) majú často na serveri Javu.

2. V poslednom čase boli vyvinuté nové technológie, ktoré umožňujú vyvinúť web rýchlejšie ako v Jave. Napríklad projekt Basecamp bol vyvinutý v Ruby on Rails.

Ja robím webové projekty v Jave od roku 2000 a myslím, že ak by chcel niekto kto nepozná Javu začať robiť nejaký web, tak by sa mal poobzerať po niečom inom.

ornyx

Já programuju pro server aktuálně v Pythonu+Django, předtím jsem dělal s PHP, ale teď jsem se hodně ponořil do programování v ActionScriptu 3 (Flash, Flex) a začínám oceňovat výhody staticky typovaného jazyka a uvažuju o vyzkoušení Javy, protože to je asi jediný používaný staticky typovaný jazyk pro Web (samozřejmě znám C#, ale to bez Win serveru je k ničemu a tohle omezení nezkousnu, jinak jazyk je to pěkný ;).

Dynamicky typované jazyky jsou prima, dělá se v nich dobře (znám i Ruby, zkusil jsem ho asi na 3 projekty), ale je to příliš mnoho koleček editace a zkoušení, jestli to funguje, v Javě podle mě na spoustu chyb přijdete ještě při editaci a omezí se většina překlepů.

Může někdo kdo má zkušenost jak s Javou tak s jinými jazyky k tomuhle pohledu něco přidat? Myslím, že by to zajímalo nejen mě ;)

Almad

Jj, psaní v dynamických jazycích bez testů je peklo ,)

b*d

Sylně typovaný vs. dynamický má svoje výhody i nevýhody. Říká se, že se v něm rychleji píše. Otázkou je jak vhodně nebo nevhodně spustí automatické konverze z typu na typ.
Na druhou stranu pokud člověk použije inteligentní IDE (Eclipse, IdeaJ)
řekl bych, že odpadá tolik bušení do různých písmen – protože např. ví jaká instance kterého objektu je proměnná inteligentě napoví pouze dané metody nebo viditelné proměnné. Metody se můžou lišit, takže můžete zkrátit jejich jména a vyhnout se všem různým berličkám jako funcX_TStr atp.

Pak můžete pomocí doslová 2 kliknutí měnit metody a změny se projeví všude! Třeba já to hodně to využívám, že si nejdřív pojmenuju všechny věci jedním dvě písmeny „x = a(y);“ a ve finále je přejmenuju tak, aby se kod dal číst jako věty „Vec[] setridenePoleVeci = triditPole(po­leVeci[]);
Ale celkově je spíš rozdíl v OOP vs Skript.
Třeba uživatelé můžou být:
User:
← IndividialUser implements PaymentAware
← CompanyUser (companUser [*] – [1] Company) kde Company implements PaymentAware

a pak zavoláte něco jako shoppingCart.pa­y(User.resolve­PaymentAware( currentUser.prin­cipal ));

Celkově shrnuto a podtrženo: je o to minimalizovat udržování globálních stavů a šílených if elseif elseif elseif a switch větví.

viz na příkladě místo:

((A))
if(user is Individual)
 return basePrice * vatMultiplier; /* osoba vzdy platí dph */
if (user is Company)
 if(user.company.payVat)
  return basePrice * vatMultiplier;
 else
  return basePrice;

nahradíte:

((B))
Interface VatPaymentAware { Money calculatePrice(Money price); }


class Individual implements VatPaymentAware
{
     Money calculatePrice(Money price) { return basePrice * vatMultiplier; }
}

class Company implements  VatPaymentAware
{
     Money calculatePrice(Money price) { return basePrice * vatMultiplier; }
}

class VatPayerCompany extends Company
{
String euVatId;
Money calculatePrice(Money price) { return basePrice; }
}

a ted:
class PayerResolver {
 protected static final PayerResolver singleton = new ...;

 PaymentAware resolvePaymentAware(Individual ...);
 PaymentAware resolvePaymentAware(CompanyUser ...);
}

a ((A)) se nahradi>
PayerResolver.resolvePaymentAware(
pravePrihlasenyUzivatel).calculatePrice();

Výhody:
a) nikde nemám konstrukci isVatPayer nebo boolean paysVat
b) PayerResolver­.resolvePaymen­tAware(
pravePrihlase­nyUzivatel).cal­culatePrice(); použiju všude kde potřebuju cenu

Takže to vypadá, že je lepší to napsat všude jako if ..

Pokud nemáte vyřešeno oddělení business logic a view tak if nebude nikde stejný (to znamená např. otestovat znova x stránek v PHP jestli jsem si nezavedl chybu někde jinde).

A pak je tu další rozšiřitelnost: zákazník běží aplikaci nějaký pátek a příjde že chce, aby jeho účetní měl cenu = 0.
Přidáse BookKeeperUser s OurCompany kde cena bude nula, ale jinak všude jinde se chová stejně, takže implementace ShoppingCart se vůbec nezmění a vy zůstane ušetřen mnoha možných chyb.

Ono na web* se to špatně vysvětluje, proč je to tak lepší. Lepší příklad je na počítačové hře.
Ty se sice dělají v C (a předělávají v jisté fázi do C++)

Vemte si třeba

function double armorDefenseRate(TStrelaTyp strela, TJednotka cil)
{

switch(cil)
{
case TANK: switch(strela->typ()) case RAKETA_Z_RPG: return -10;
case SOLDA: switch(strela->typ()) case RAKETA_Z_RPG: return -1000;
...
}

naproti tomu:

cil.dostalZasah(Strela strela)

P>
class T80 implements Tank {

double hp;

dostalZasah(Strela strela) {
strela.doDamage(this); /* Pomocí tohoto vzoru se dostanu na volaní konkretní střely s konkrétním jednotkou, tady tank a přitom nepoužiji explicitní přetypování */
}

Uplný závěr: překlepy nejsou díky IDE (skoro) možné. Vývoj je více stabilní (znovu-použití, zakrývání stavů), silně podporované Unit testování (i tzv. reflexe), za cenu poměrně pomalého vývoje. JBoss se dá alespoň verze 4 rozeběhat pro pár uživatelů (desítky) na ráz na 128MB paměti a 200MHz počítači (to k té nenažranosti Javy, nejsme sami, kdo má takhle devel a test mašiny postavené na VPS)

Zkuste se podívat na frameworky jako je JBoss Seam ( http://www.jboss.com/products/seam/ , http://java.cz/…czpodcast-21 ) je to skoro klikací framework!

Nebo na Google Widget Toolkit: http://code.google.com/…verview.html

Nevýhody: Pokud nemáte alespoň vlastní VPS (virtuální server) dost těžko se projekt někde vystavuje a zadarmo hodně težko. Vývoj může být delší (závisí jestli si vyberete správný framework a jaké máte znalosti best practices).
Komunita pro opensource projekt (free etc.) je menší u Javy…

Almad

Zrovna s tím if elseif mi přijde že jste si trochu naběhl – tam bych řek, že vede pattern matching (Erlang) na plné čáře.

Krom toho v tom příkladu (prvním) nevidím moc nic, co by se týkalo static vs. dynamic nebo weak vs. strong typing, to je prostě o tom, jak má být navržená architektura.

funcX_TStr je proboha co? Kdo dělá v dynamických jazycích tohle, tak si myslim, že ho ani Java nezachrání…

JBoss Seam už jsem viděl před nějakou dobou, takže nebudu kritizovat dokud si neprojdu novou verzi (a jakože na to asi nedojde).

Ale když se podivám třeba hned na tutorial, tak


public String register() {
List existing = em.createQuery("select username from User where username=:username")
.setParameter("username", user.getUsername())
.getResultList();
if (existing.size()==0)
{
em.persist(user);
log.info("Registered new user #{user.username}"); return "/registered.jsp"; }
else
{
FacesMessages.instance().add("User #{user.username} already exists"); return null;
}
}

neni rozhodně nic, co by mě přesvědčilo. return „/registered.jsp“; se používá i normálně? A vždycky, když vidim jak nějaká takováhle funkce vrací return null, tak si vzpomenu na své dlouhé noci strávené nad NPE (u kterých jsem se vždycky smál nad tím, jak je to povinné odchytávání výjimek…ehm, super).

GWT je fajn projekt, jsem zvědavej, kam se ještě potáhne. Ale taky se přiznám, že jsem si spíš hrál s implementacema stejného principu v jiných jazycích.

„Pokud nemáte vyřešeno oddělení business logic a view tak if nebude nikde stejný (to znamená např. otestovat znova x stránek v PHP jestli jsem si nezavedl chybu někde jinde).“ – já myslim že tohle vyjadřuje ducha celého Vašeho příspěvku. Ale prostě věřte, že ne pro všechny programátory platí, že dynamický jazyk == PHP == zprasená archiektura a MVC nikdy nepoznali (nenapsal jste to tak, ale trochu mi to z toho vyplývá…argumen­tujete na věci, na které to fakt není potřeba :))).

„Uplný závěr: překlepy nejsou díky IDE (skoro) možné. Vývoj je více stabilní (znovu-použití, zakrývání stavů), silně podporované Unit testování (i tzv. reflexe), za cenu poměrně pomalého vývoje.“

A tady bych se právě ptal. Jak je silně podporované unit testování ve stylu TDD? U toho jsem vždycky nadával jak špaček, protože AFAIK je podpora jenom pro vygenerování unittestů pro existující interfaces, což saje. Pokud je nějaký nástroj pro TDD, sem s ním!

K IDE, i pro dynamické jazyky je už dost solidní podpora pro intellisense, na to, abych překlepy opravdu neřešil.

A závěrem, já nemám nic extra proti silnému statickému typování. Ale zrovna Java je ukázka toho, jak mi to opravdu nevyhovuje. V jiných jazycích sem opravdu neměl tendenci tak nadávat (a to jsem zrovna dělal drobné appky pro desktop, ne weby..).

Kakihara

serial vypada nadejne.
akorat neni popsane, jak z netbeans deploynout projekt na glassfish server a podobne.
mam se s tim poprat sam, nebo to bude v nasledujicich dilech?

Martin Malý

Snad neprozradím moc, když řeknu, že tématem příštího dílu bude mj. i „deploy“.

HFechs

Nikdy jsem nic v jave nedělal, jen jsem to nainstaloval, otevřel projekt, klikl na zelenou šipku a kupodivu to fakt na té adrese běží ;-). Třeba se ze mě stane java programátor :D.

Alternate

Chtěl bych se zeptat, jaké má výhody provozovat java aplikaci na aplikačním serveru oproti třeba NT službě, poskytuje aplikační server nějakou extra funkcionalitu?. V práci programujeme intranet aplikace v C# systémem SQL->standardní Windows NT služba s WCF->klient a třeba update serverové části aplikace je dost problematický kvůli nutnosti službu restartovat. Pokud by něco takového uměl java aplikační server za běhu, tak bych snad i uvažoval o přechodu na javu:)

Richard

Update aplikácie za behu vie dokonca aj obyčajný Tomcat.

alef0

Webové aplikácie v Jave musia bežať v rámci nejakého servletového kontajnera (resp. JEE aplikačného servera, čo je servletový kontajner + podpora ďalších služieb). Ono je to istým spôsobom požiadavka, pokiaľ si samozrejme nechce programovať nízkoúrovňové otváranie socketov, manažovanie vlákien, vlastné sessiony atď. nanovo.

Servletový kontajner to všetko dáva k dispozícii automaticky a umožňuje elegantne nasadzovať aplikácie, často štýlom klik-klik-deploy.

Vo Windowse obvykle beží servletový kontajner ako služba (takto funguje Tomcat, ale i WebSphere).

Mnoho servletových kontajnerov dokáže znovunasadiť aplikáciu tak, že dokonca zachovajú i existujúce sessny (vie to Tomcat, vie to Glassfish).

A servletový kontajner si netreba predstavovať ako nejaký mega-moloch, taký Jetty v základnej konfigurácii má tuším 2MB.

Alternate

Díky za vysvětlení.

alef0

Inak vo svete Javy existuje aj táto možnosť: postavíte klasickú SOAPovú webovú službu (špecifikácia JAX-WS) a spustíte ju. Od Javy 6 je k dispozícii zabudovaný jednoduchý HTTP server, ktorý vie obsluhovať požiadavky na túto službu a teda nepotrebujete ani servletový kontajner. (Samozrejme, prichádzate o možnosť nasadzovania servletov)

Ale neviem, ako je to s praktickou výkonnosťou, plus prídete o všetky tie horeuvedené výhody (reload, redeploy atď).

Kdesi som to používal ako ukážkový príklad ,,nasaďte si webovú službu na päť riadkov“.

ah01

Nepomohlo by provozovat WCF v IIS a ne jako samostatnou službu? Tedy v podstatě .net obdoba toho: „provozovat java aplikaci na aplikačním serveru“.

Alternate

Asi máte pravdu, s IIS nemám moc velké zkušenosti a ani mi není moc sympatický. Navíc máme bohužel jen servery s IIS5–6 kde, pokud se nemýlím, nejede net.tcp binding pro WCF.

b*d

Popřípadě se dá spustit poměrně jednoduše cluster :-)

Problém v Javě je, že přesně neexistuje ta fascinující univerzalní geniální cesta. Je x alternativ, což ale u začátečníku vede k zoufalství.

ktv

Probihala tu debata na tema rychlost Java X PHP X Ruby atd… tenhle clanek se o nejaky takovy porovnani pokousi. Jasne kazdy ted muze namitnout ze je to synteticky/ne­realny/nevyva­zeny test blablabla. Ano, je. ale to sou vsechny – a pokud nechcete vasi aplikaci psat 5× v ruznych jazycich jenom abyste zkusili ktera verze je nejrychlejsi muze vam tohle pomoci ve volbe.

http://blog.dhananjaynene.com/…ruby-groovy/

vysledky:
Java(SunJRE 1.6) – 1.6ms
C++(gcc 4.1.3) – 3ms
C++(gcc 4.2.3) – 0ms
Ruby (1.9.0) – 89ms
ruby (1.8.6) – 380ms
jruby – 80ms
Python(2.5.1) – 192ms
Python(2.5.1 with psyco) – 33ms
Jython(2.2.1 on JRE 1.6.0.03) – 632ms
Groovy(Uncomplied) – 363ms
Groovy(Bytecode) – 360ms
Groovy(1.6-beta-1) – 104ms
PHP(5.2.3) – 593ms

Kod je hodne o iteracich, zakladni prace s objekty (chybi dedicnost, virtualni metody, interface metody – coz je zrovna vec ktera neni v jave uplne nejrychlejsi, ikdyz na posledni Java One sem byl na nejaky prednasce na tema vnitrnosti JVM a rikali ze s tim nejak pohnou tak uvidime, adresace v poli – coz nepovazuju za nijak zasadni v dnesni dobe, prace s hash tabulkama/aso­ciativnima polema – povazuju za zasadni na druhou stranu nemyslim ze by implementace mohly bejt nejak dramaticky rozdilne vykonny, ale myslet je jedna vec mit to podlozeny realnejma casama je vec druha)

ktv

este doplnim – tu adresaci v poli nepovazuju za zasadni ne proto ze by se to nepouzivalo, ale proto ze se to dela vsude stejne a myslim ze nema moc cenu to merit. kazdopadne v tomhle testu to neni a pro uplnost by to tam asi byt melo.

ktv

no nemusi byt synteticky ale pak se to zas posouva do roviny – ok v tomhle pripade to fungovalo ale bejvalem to slo v PHP/Ruby/Gro­ovy/C# napsat takhle a jak to bylo napsany je neefektivni atd atd… starej dobrej priklad je asi 3 roky stara medialni masaz s petstore v J2EE vs .NET – ta v J2EE byla napsana se strasnym overkillem aby se ukazaly vsechny mozny i nemozny featury J2EE protoze to mel bejt tutorial, .NET byla samozrejme napsana s ohledem na maximalni vykon takze byla rychlejsi a MS se pak chlubil jak jim to pekne funguje :)

ktv

to urcite ne a tak jsem to ani nemyslel :) ja sem se bavil v obecnejsi rovine – vy jste napsal „nemusi byt synteticky“ a ja sem na to odpovedel (nebo chtel odpovedet ale mozna jsem se spatne vyjadril) ve smyslu ze testy jsou bud synteticky a neplni zadnou uzitecnou ulohu ale spis se zameri na otestovani rychlosti nejakyho aspektu jazyka (jako napr. vyhledavani virtualnich metod, dereference atd…) ale potom je jim vycitano ze nemaji dostatecnou vazbu k realite, nebo jsou to testy ktery maji nejakou pozorovatelnou funkcnost, ale zase jim je vycitano ze to nahodou vyslo ve prospech/neprospech toho nebo toho protoze zrovna se tam casto pouziva neco co je pomaly/rychly, nebo ze se to v tom a nebo onom jazyce dalo naimplementovat ji­nak.

Co se tyce toho odkazu co jste posilal to bych rekl ze je este trochu jina kategorie a sice nativni implementace PHP a implementace PHP bezici v JVM coz je imho kombinace vykonu virtualniho stroje a kvality tech dvou implementaci jako takovejch. (ale opravte me jestli sem ten clanek spatne pochopil)

opicak

Zdravim,
k cemu je aplikacni server? jsou i jine alternativy k GlassFish?

alef0

JEE (Java Enterprise Edition) aplikačný server slúži ako kontajner pre webové aplikácie (veľmi veľmi voľne ho možno prirovnať k ,,operačnému systému, v ktorom bežia webové aplikácie“).

Webové aplikácie bežia odlišným spôsobonm: kým v PHP sa s každou požiadavkou načítava a spracováva skript nanovo, v Jave sa webaplikácia naštartuje raz (obvykle pri štarte servera) a ďalej už len beží a obsluhuje požiadavky. Aplikačný server je ten, kto je zodpovedný za manažovanie bežiacich aplikácií

Ďalej webaplikáciám elegantne využívať pokročilú funkcionalitu – za všetky len centrálny prístup k zdrojom dát, autentifikáciu a autorizáciu, webové služby (JAX-WS), transakcie, fronty správ (JMS). Funkcionalita je štandardizovaná, a teda pri dodržiavaný špecifikácie máte zaistené, že webaplikácia pobeží bez zmien v aplikačných serveroch od rôznych výrobcov.

JEE aplikačných serverov je množstvo, ich počet závisí od verzie JEE, ktorú oficiálne podporujú.

Čerstvo vydanú JEE 6 podporuje zatiaľ len voľne dostupný Glassfish (plus jeden komerčný produkt).

Predošlú verziu JEE 5 podporuje množstvo výrobcov – z voľne dostupných JBoss, Apache Geronimo.

Ak nechcete využívat plný repertoár JEE možností, pre jednoduché aplikácie si vystačíte aj so malým servletovým kontajnerom – napr. Tomcat, či Jetty.

pr.rybar

Z wikipedie:

Application server is a software framework dedicated to the efficient execution of procedures (scripts, routines, programs, …) for supporting the construction of applications. The term was created in the context of web applications.

Web application is an application that is accessed via a web browser over a network such as the Internet or an intranet.

Otazka:

Mozno povazovat server, v ktorom je aplikacia komunikujuca protokolom SOAP, za aplikacny server vyhovujuci definicii z wikipedie?
Ja totiz nepoznam vebovy prehliadac, ktory by komunikoval protokolom SOAP. SOAP totiz napriek tomu, ze moze byt nad HTTP (webovy aplikacny protokol) nie je webovy protokol.

ps: mam rad jasno v pojmoch, je to dolezite aby sme nekomunikovali stylom „ja o koze, ty o voze“

alef0

Celkom mi nie je jasné, čo nie je jasné :-)

Franta Kučera vyššie napísal:
<i>
Požadavky na AS jsou jasné a striktní. Pro Javu EE 6 jsou certifikované aplikační servery Glassfish 3 a TMAX JEUS 7. Pro Javu EE 5 je jich víc: JBoss 5, Glassfish 2, Apache Geronimo, IBM WebSphere a další.
</i>

<i>JEE aplikačný server</i> je softvérový framework, ktorý spĺňa špecifikáciu JEE. (V predošlom príspevku som sa vyhýbal samostatnému pojmu ,,aplikačný server“, vždy som ho uvádzal v súvislosti s JEE)

Ono taká trieda javax.xml.ws.En­dpoint, do ktorej môžete nasadiť JAX-WS webovú službu (ktorú môžete považovať za jednotriedovú aplikáciu) spĺňa vaše požiadavky na server (obsluhuje SOAP požiadavky klientov), ale JEE aplikačný server to nie je, i keď by jeho autor mohol hrdo tvrdiť, že ,,nasaďte službu do aplikačného servera“, hoci by to bol prehnaný pojem.

pr.rybar

Nerozumieme sa.
To co pan Kučera napisal je v poriadku.

Ja poukazujem na to, ze JEE aplikačný server akosi nezodpoveda definiciam z wiki.
To je to, co som tu v diskusii uz spominal. Je jasne ze je nejaka definicia pre JavaEE aplikačný server, ale akosi tie rozne definicie nesedia.

Podla jenych je AS, nejaka zbierka technologii napchana do servletoveho kontajnera a pomenovana JavaEE aplikacny server.
Podla druhych (wiki) je aplikacny server, nieco, co komunikuje webovo (HTTP, nie SOAP alebo RMI)

ps: Majme definiciu bicykla. Bude bicykel bicyklom aj ked mu primontujeme motor? Lebo to uz je ina definicia – motorka.

alef0

O tomto preťažení pojmov som písal niekde hore v debate.

Kladiem si otázku, za akých podmienok je v tom chaos.

Osobne by som zvolil stratégiu, že v Jave používam len pojem ,,JEE aplikačný server“ (v zmysle ,,zbierka technológii…“)

Zvyšok je zrejme nerelevantný. (mohli by sme upadnúť do debaty, či je definícia vo wikipedii správna ;-)).

pr.rybar

Teraz sa uz rozumieme, dakujem.

opicak

A prosím Vás, ještě otázku:
K tomo abych mohl nasadit Javu na web, potřebuji web server, který se postará o obsluhu HTTP požadavků, nebo to zvládá aplikační server, třeba už zmíněný GlassFish?

Tohle bohužel v článku chybí a příjde mi důležite to zmínit… :)

em

supr clanek, pojedu podle nej.

Poznamka – aplikace nejsou jen webove, i kdyz si to nekteri mysli

uf

Dobry den, me by to taky zajimalo. Chci pro novou technologickou verzi aplikace pouzit NetBeans platformu a jeste nevim, jak budu komunikovat s databazi a sluzbami na aplikacnim serveru.

Honza

Zdravím,
vím, že seriál je už zastaralý (2010, takže nic hrozného), ale „nmercurial linky“ jsou již mrtvé (zřejmě, nefunguje webové prostředí, ani hg clo). Nebylo by možné díly pro jednotlivé kódy na uvedených odkazech zveřejnit?
Nebo může být chyba jinde?
Díky.

František Kučera

VPS je opět v provozu: https://hg.vps.frantovo.cz/nekurak.net/ také je možno stahovat z primárního serveru https://hg.frantovo.cz/nekurak.net/ (který běžel celou dobu).

Milan

Zdravím,
můžu se autora zeptat, jak přes „web“ inzerovaný v návodech (resp. Mercurial) stáhnout kódy v bz2 (jak je inzerováno)…prošel jsem to celé několikrát ale způsob jak tyto zdrojové kódy stáhnout přímo ve zmíněném archivu jsem nenašel.
Předem děkuji za odpověď ;)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.