Komentáře k článku

Java na serveru: úvod

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í.

Zpět na článek

117 komentářů k článku Java na serveru: úvod:

  1. boban

    Prosím o vysvětlení

    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í.

    1. Milan

      Re: Prosím o vysvětlení

      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 :)

    2. Jara

      Re: Prosím o vysvětlení

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

    3. Michal Kára

      Re: Prosím o vysvětlení

      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.

      1. Jiří Knesl

        Re: Prosím o vysvětlení

        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. :)

        1. Vebloud

          Re: Prosím o vysvětlení

          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á.

    4. Ped

      Re: Prosím o vysvětlení

      „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++.

        1. honza

          Re: Prosím o vysvětlení

          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?

            1. honza

              Re: Prosím o vysvětlení

              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.

              1. .

                Re: Prosím o vysvětlení

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

                1. honza

                  Re: Prosím o vysvětlení

                  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:)

            2. Ped

              Re: Prosím o vysvětlení

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

              1. Martin Malý

                Re: Prosím o vysvětlení

                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?) :)

                1. alef0

                  Re: Prosím o vysvětlení

                  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.

    5. alef0

      Re: Prosím o vysvětlení

      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)

    6. logik

      Re: Prosím o vysvětlení

      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)

      1. alef0

        Re: Prosím o vysvětlení

        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.

        1. b*d

          Re: Prosím o vysvětlení

          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.

          1. pr.rybar

            Re: Prosím o vysvětlení

            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.

            1. b*d

              Re: Prosím o vysvětlení

              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.

              1. alef0

                Re: Prosím o vysvětlení

                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ý :-)

              2. pr.rybar

                Re: Prosím o vysvětlení

                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?

                1. b*d

                  Re: Prosím o vysvětlení

                  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?

                  1. pr.rybar

                    Re: Prosím o vysvětlení

                    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.

                    1. b*d

                      Re: Prosím o vysvětlení

                      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!

                      1. František KučeraAutor příspěvku

                        Školství

                        Já to vidím ve škole – ale neřekl bych, že je na vině až tak školství. Spousta lidí chce být manažery nebo analytiky a programování se štítí a jsou rádi, když prolezou základním kurzem.

                        Mně to třeba dělá radost, když napíšu kus kódu a pak vidím, co z toho je za webovou stránku nebo jiný program. Ale hodně lidí na to asi nemá tu trpělivost nebo já nevím… Nějaké návrhy jak zvýšit motivaci ke studiu programování?

                      2. alef0

                        Re: Prosím o vysvětlení

                        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ť.)

                        1. dc

                          Re: Prosím o vysvětlení

                          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 :-)

                        2. pr.rybar

                          Re: Prosím o vysvětlení

                          > 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.

                          1. alef

                            Re: Prosím o vysvětlení

                            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.

                            1. František KučeraAutor příspěvku

                              Re: Prosím o vysvětlení

                              Dnešní společnost mi přijde taková dekadentní. Před třiceti lety si základy programování museli projít i studenti filosofické fakulty. A dneska se člověk může setkat na fakultě informatiky s lidmi, kteří se diví, že po nich někdo nějaké programování chce (byť úplné základy).

                              „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.“

                              Ono to asi jinak nejde – většina předmětů má charakter „Úvod do XYZ“ (bez ohledu na obor) a prohloubit znalosti si musí už student sám. Tolik času není. Škola by asi neměla dopodrobna učit konkrétní technologii (nebo to aspoň není primární), ale spíš nějaké obecné principy (a konkrétní technologii použít jako příklad). Protože ta technologie velice brzy zastará – člověk se je musí učit celý život.

    7. František KučeraAutor příspěvku

      Re: Prosím o vysvětlení

      Důvodů už padlo hodně, za sebe jen doplním: je to hlavně Java jako jazyk – tedy statické a silné typování (mám rád pořádek) a java je celkem jednoduchý jazyk, obsahuje minimum záludností a číst cizí kód je relativně snadné. A zadruhé je to Java jako platforma a všechno kolem – IDE, knihovny, aplikační servery, frameworky.

    8. Láďa

      Re: Prosím o vysvětlení

      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.

  2. rooobertek

    novoročné predsavzatie

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

    1. K-Kamil

      Re: novoročné predsavzatie

      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é.

      1. rooobertek

        Re: novoročné predsavzatie

        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ť :)

      2. ahl

        Re: novoročné predsavzatie

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

        1. Láďa

          Re: novoročné predsavzatie

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

  3. multi

    pod poklickou

    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?

    1. rooobertek

      Re: pod poklickou

      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.

    2. MD

      Re: pod poklickou

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

    3. Melme

      Re: pod poklickou

      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.

        1. b*d

          Re: pod poklickou

          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.

    4. Mr.Dan

      Re: pod poklickou

      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

      1. ahl

        Re: pod poklickou

        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é.

        1. uf

          Re: pod poklickou

          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.

      2. ah01

        Re: pod poklickou

        > 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.

        1. pr.rybar

          Re: pod poklickou

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

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

          1. Vykook

            Re: pod poklickou

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

            1. pr.rybar

              Re: pod poklickou

              Cakam na ten dlhy zoznam.

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

              1. ah01

                Re: pod poklickou

                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.

                1. pr.rybar

                  Re: pod poklickou

                  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?

                    1. pr.rybar

                      Re: pod poklickou

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

                  1. František KučeraAutor příspěvku

                    Re: pod poklickou

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

                    Vždyť to EJB je nakonec taky .jar. Ale ‚deploynuté‘ EJB na serveru je služba/komponenta, zatímco v tom obyčejném .jaru (použitém jako knihovna) jsou jen „neživé“ třídy, které si člověk ručně instanciuje. Při použití EJB je velice snadné např. rozdělit aplikaci na dva servery (v podstatě jen konfigurací). Místo volání služby (EJB) v rámci jednoho aplikačního serveru se bude volat EJB odjinud, po síti. A i další kouzla se s tím dají dělat…

                    Na druhou stranu je dobré to s vrstvenou architekturou nepřehnat – neplatí, že čím víc vrstev, a čím víc „enterprise“, tím líp – vrstvenost by měla odpovídat potřebám aplikace (v nějakém rozumném časovém horizontu).

                    1. pr.rybar

                      Re: pod poklickou

                      > 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.

                2. alef0

                  Re: pod poklickou

                  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?

                  1. pr.rybar

                    Re: pod poklickou

                    > 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. :)

                    1. alef0

                      Re: pod poklickou

                      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.

                    2. Milan

                      Re: pod poklickou

                      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).

                  2. xtonda

                    Re: pod poklickou

                    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.

                  3. František KučeraAutor příspěvku

                    Re: pod poklickou

                    „Existuje nejaka oficialna definicia aplikacneho serveru?“

                    Ano.

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

                    Nic jako „přiměřeně dost“ neexistuje. :-) 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ší.

                  4. b*d

                    Re: pod poklickou

                    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.

                    1. alef0

                      Re: pod poklickou

                      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).

                      1. b*d

                        Re: pod poklickou

                        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č.

                3. pr.rybar

                  Re: pod poklickou

                  > 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.

    5. xtonda

      Re: pod poklickou

      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á.

      1. alef0

        Re: pod poklickou

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

          1. alef0

            Re: pod poklickou

            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).

  4. Richard

    Má význam tento seriál ?

    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.

    1. ornyx

      Re: Má význam tento seriál ?

      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ě ;)

      1. b*d

        Re: Má význam tento seriál ?

        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…

        1. Almad

          Re: Má význam tento seriál ?

          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..).

  5. Kakihara

    spusteni

    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?

    1. Martin Malý

      Re: spusteni

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

    2. HFechs

      Re: spusteni

      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.

  6. Alternate

    Aplikační server

    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:)

    1. alef0

      Re: Aplikační server

      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.

        1. alef0

          Re: Aplikační server

          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“.

    2. ah01

      Re: Aplikační server

      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“.

      1. Alternate

        Re: Aplikační server

        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.

    3. b*d

      Re: Aplikační server

      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í.

  7. ktv

    Jenom k rychlosti

    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)

    1. ktv

      Re: Jenom k rychlosti

      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.

    2. František KučeraAutor příspěvku

      Drupal – PHP nad Javou

      Ony ty testy nemusí být jen syntetické. Dost zajímavé je např. tohle:
      Resin backed PHP drives 4×.

      Quercus (od Resinu) je implementace jazyka PHP napsaná v Javě. Díky ní je možné provozovat PHP aplikace v Javovém aplikačním serveru, což by mělo být (překvapivě) výkonnější než nativní implementace PHP, a další výhody (např. volání Javových metod z PHP programů, DB „connection pooling“ atd.).

      Ovšem když jsem Quercus zkoušel posledně, bylo dost utrpení vůbec rozchodit připojení k DB a pak byly ještě problémy s kódováním češtiny – ne z databáze, ale v některých PHP funkcích. Možná je na čase se podívat, kam se to od té doby posunulo :-)

      1. ktv

        Re: Drupal – PHP nad Javou

        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 :)

        1. František KučeraAutor příspěvku

          Re: Drupal – PHP nad Javou

          V tomto případě byl k testu použit Drupal – toho snad nikdo nemůže podezřívat, že je psaný tak, aby nadržoval jedné nebo druhé implementaci, ne?

          1. ktv

            Re: Drupal – PHP nad Javou

            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)

    1. alef0

      Re: aplikacni server?

      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.

      1. pr.rybar

        Re: aplikacni server?

        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“

        1. alef0

          Re: aplikacni server?

          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.

          1. pr.rybar

            Re: aplikacni server?

            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.

            1. alef0

              Re: aplikacni server?

              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 ;-)).

      2. opicak

        Re: aplikacni server?

        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… :)

        1. František KučeraAutor příspěvku

          Re: aplikacni server?

          Zvládá to aplikační server – ten funguje zároveň jako webový server. Obvykle naslouchá na portu 8080 (http). Glassfish ještě na portu 8181 (https) a 4848 (administrace) a 4949 (administrace-https).

          Pro testování a vývoj tedy stačí samotný glassfish*, ale v ostrém provozu potřebujeme web provozovat na normálním HTTP portu (80) – je několik způsobů, jak toho dosáhnout – chci se tomu věnovat v jedné z příštích kapitol…

          *) případně jiný AS a v našem případě by na většinu věcí stačil i webový kontejner.

    1. František KučeraAutor příspěvku

      Re: supr

      jj, může to být i tlustý klient. Také pěkná technologie – klient se stahuje ze serveru pomocí Java Web Start, komunikuje přes CORBA/IIOP… můžu o tom taky napsat (až probereme ty základní věci), pokud by byl zájem.

      1. uf

        Re: supr

        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.

  8. Honza

    Nefunkční odkazy
    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.

      1. Milan

        Re: Zdrojové kódy
        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ěď ;)

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3147