Názory k článku
Java na webovém serveru: první web

Díky za článek. Jen co se týče formy, příště bych omezil použití tagů abbr s vyskakovacím title. Blbě se to čte.

Naopak, mě to text oživuje…

Jo, pokud máš prohlížeč, který to podporuje. Já bych na to pro Operu mini potřeboval nějaký šílený bookmarklet.

Yet another useful article …

Po předcházejícím článku jsem se pustil po prozkoumávání ostatních technologií. Našel jsem video, kde člověk píše všechny xml atp. pro JavuEE v emacsu (a že píše rychle). V Netbeans nebo Eclipse takové problémy až tak viditelné nejsou. A pochvaloval si Plone/Zope.
Je to už starší video (odkaz na stránkách plone.org). Po prozkoumání:
mají ear/war říkají tomu egg. Egg se může taky psát ručně, ale většinou se generuje. Mají viewlety, templaty, etc. kromě toho že obohacují tagy vlastními attributy proti samostatným v jsp je to hodně podobné.
Pro mně z toho vyplynulo, že Plone/Zope se přibližuje Javě a Java Zope.
Rails, TurboGrears, atp. bylo jaksi mezi těmito světy.
Asi není náhodou, že Python a Java jsou asi nejoblíbenější u Googlu.

Python má výhodu, že netáhne s sebou břemeno C/C++. Ale jako programátor v C++ musím příci, že mnoho věcí to se považuje za hype se ve větších týmech zakáže. Ono je totiž sranda napsat jednu web-aplikaci s pár stránka v málo lidech. Pokud to má aplikace mít life-cycle delší (i několik let) tak ukecanost a restrikce Javy se poměrně hodí.

I když „properties“ z Pythonu by byly skvělé. Už jenom proto, že psát triviální inline getry/setry je opravdu vopruz a alespoň má člověk možnost dostat se ke getru při dědění, pokud ho autor „zapoměl“. Bezpečnost tu nemá smysl, může vracet kopii (data jsou má).

No pravě že „už“ moc ne. Java a frameworky už jsou na úrovni Python a programovaní je už skoro myší.

To porovnání by lepší pokud by tam dal Zope vs Java EE app server.

Je jasné, že Emacs není IDE na úrovni Eclipse. Já jsem nenapsal SQL ani xml (web.xml atp.) už dlouhou dobu. Všechno zařídí IDE. Další věc je, že jsem ho neviděl udělat ani jeden test!

Reference se nepoužívají. Já jsem vůbec rád, že tyhle věci v Javě nejsou. Problém je s lidmi bez praxe. Asi si dokážete živě představit, jak by jejich commit vypadal.

Dekorátor – to samozřejmě je (třeba ve Springu se používá velmi hodně – deklarativní bezpečnost, transakce atd.). Např. vyhodím-li RuntimeException provede se rollback i na session.

Ale na druhou stranu, přemýšlím že pro start-up low/medium scale projekty začnu využívat více Plone. Teď jenom přijít na to, jak ho skinovat.

Jenomže v javě nic takového jako samostatná metoda neexistuje. Reference na metodu je tedy nesmysl, protože když chci volat metodu a nevím jakému objektu/třídě patří, tak se může dít skoro cokoliv(metoda může měnit atributy toho objektu/třídy). Reference na metodu se v javě implementuje jako rozhraní s jednou definovanou funkcí. Z toho důvodu se mi nelíbí ani ty delegáty v c#.

Delegáty nie sú, hej, rieši sa to cez implementáciu interfejsu, prípadne anonymné vnútorné triedy. Potom to v takom v Swingu to vyzerá dosť masakrálne.

Počkajte na Javu 7, budú closures, už je to schválené.

Dekoratory v Jave samozrejme existuji … rika se tomu AOP :-). Delaji se s tim presne ty same veci

Ale ucel se dostat z bodu A do bodu B bude stale stejny…

Ja teda nevim, dekorator – aspon pokud myslite ten navrhovy vzor – se da realizovat v jave a klidne i v javascriptu, nebo ne?

Tak po dvou dnech s Plone/Zope/Python končím. Ony legendární vlastnosti, s tím jak se požadavky posunují od konkrétního k obecnému, zanikli. Je to vlastně už jako v Javě. Akorát jde o ten směr vývoje: Konkrétní->Obecné Python
Obecné Java

Dokumentace je k =censored= Next skáče na další kapitolu a né sekci, takže se to ani nedá číst.

Celkově mám dojem, že té komunitě chybí směr a cíl. Na jedné straně je snaha nebýt bloated JavaEE, na druhé nabídnout dostatečnou obecnost. Jenže tam naráží Konvence oproti Konfiguraci.

Ve zmíněném videu je totož vynecháno, že část IDE je vlastně zahrnuta v app serveru / Plone. Takže se něco dělá tady, něco tam…

Btw. v soutěži o jednoduchý publikační systém vyhrál WordPress a co se týče dalšího mid sized, tak se bude psát v Jetty₊Hiber­nate+Spring(Web­flow, JPA, IceFaces). Je to rychlejší v tom, že se to dá na 90% naklikat v dobrém IDE (MyEclipseIDE v kombinaci s MDA toolem).

Zájemcům o webové programování v Javě doporučuji prohlédnout projekt
http://www.playframework.org . Je to odlišný přístup, než jsou klasické ‚servlet based‘ javovské frameworky, hodně inspirováno systémy je např. Django . A je vidět, že to vyvíjí někdo, kdo to taky sám používá :-)

David

Hmm, pěkný, ale Groovy jako jazyk pro šablony asi bude znamenat nemalý slowdown, možná třeba Scala by byla vhodnější. Platforma Java prostě nebyla určena pro dynamicky typované jazyky. A hlavně, pro komfort programátora je důležité, že tím ztrácí statickou typovou kontrolu.

Play framework je jiste krok zajimavym smerem, treba pro mensi dynamicke weby. Ad rychlost groovy v sablonach – urcite i v Play existuje moznost zkompilovanou sablonu dat do kese ; jinak, nemylim-li se, Django dnes uz spustite pod Jython 2.5 , chcete-li ho provozovat nad JVM.

No dokonce bych se i divil, kdyby ten bytecode nebyl cacheován. Pro dobrý výkon je důležité nejen cacheovat bytecode, ale i v paměti načtené třídy (verifikace bytecode, optimalizace jako třeba inlineování virtuálních metod, JIT cache apod.).

Jenže u dynamicky typovaného jazyka se řádově hůře optimalizuje. Virtuální metody ve staticky typovaných jazycích bývají v Javě volány přes invokevirtual. Jak jsou volány metody u dynamicky typovaných jazyků? Nevím, ale nabízí se mi tu dvě možnosti:
* Reflection, IMHO celkem slowdown
* invokedynamic (mám pocit, že přibude v Javě 7)
V obou případech jsou optimalizace zřejmě mnohem složitější.
Navíc se podívej na různé benchmarky: http://www.google.cz/search?q=java+groovy+preformance&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:cs:official&client=firefox-a

Super článek!

Docela bych uvítal nějaký slovníček pro ASP.NET vývojáře (jako jsem já), protože mám pocit, že tu existuje mapování téměř 1:1. Rovnou můžu začít (v Javě jsem web nikdy nedělal, takže to je jen nástřel a klidně mě opravte):

• Servlet = HTTP Handler
• JSP = ASPX
• Filtr = HTTP Module
• JavaBean = POCO splňující určité konvence, instance obhospodařované nějakým kontejnerem
• <jsp:scriptlet> == <script runat=„server“>
• web.xml = web.config

Trochu vysvětlení:

• Servlet = HTTPHandler ± OK
• JSP = ASPX už pokulhává. ASP.NET je hlavně komponentová technologie. JSP je hlavně šablonovací technologie. JSP vám nedefinuje ani nemapuje žádné komponentní třídy na pozadí. Spíš JSP = staré ASP :-)
• Filtr = HTTP Module ± OK
• JavaBean (označované také jako POJO) = POCO sedí
• <jsp:scriptlet> == <script runat=„server“> ± OK:
  V ASP.NETu uvnitř scripletu definujete tělo třídy která vzniká překladem ASPX souboru (tedy metody a property třídy výsledné stránky). Kdy se co volá je pak dáno lifecyklem (děsný slovo) třídy Page od které výsledná třída stránky dědí.
  JSP soubor se přeloží – vytvoří pouze jednu metodu výsledné třídy a tedy scriplet se vkládá právě do toho místa výsledné metody kde je uvedený. Umístění scripletu v JSP definuje kdy se jeho kód volá (častý zdroj mučivých nocí JSP začátečníků :-D).
• web.xml = web.config sedí

Kdyz uz, tak spis JSF ~ ASPX…

A jsf tady máme proto, aby jsme mohli používat IceFaces (icefaces.org)

ASP.NET MVC = Treba Struts nebo Spring MVC
ASP.NET WebForms = JSF

Asi nejvetsi rozdil mezi .NET a Javou je v tom, ze vam nikdo nerika, jaky framework nebo databazi mate pouzit. Kdysi jsem cetl knizku o tvrobe webu pomoci .NET 1.1 a trochu me vydesilo treba to, jak se lisila uroven podpory databazi pro MS SQL Server a ty ostatni. Treba pojmenovane parametry SQL dotazu byly podporovany jen pro MS SQL a rozdil vykonu dle autoru pry cinil 20%, coz mi prisel vendor-lockin jako prase.

K vasi otazce – V Jave si muzete vybrat z mnoha technologii pro generovani frontendu a ty muzete dale doplnit dalsimi knihovnami pro generovani konkretnich prvku HTML. Treba standard JSF ma implementace od Sunu (Mojara) i Apache (MyFaces) a obe muzete doplnit temito velkymi knihovnami: http://www.jsfmatrix.net/, plus tuny dalsich – mensich. Nutno dodat, ze na JSF se muzete uplne vykaslat a pouzit treba Struts, Spring MVC, Wicket nebo Tapestry. Prave tohle je opravdova sila Javy – naprosta svoboda, naprogramujte si to, v cem chcete :-))

JSP bych snad ani nezminoval, to je mrtva technologie, nahrazena Facelety, jez jsou nyni primo soucasti standardu JEE 6. Nekde v diskusi zaznelo, ze JSP jsou pro sablonovani, coz je blbost, protoze sablonovani v JSP je spise parodie, vykonove je to take bida.

No plne ekvivalentni technologie jako takove asi neexistuji. Spis nektere frameworky jsou postavene na podobne filosofii, ale dost se lisi pristupem.

Napr JSF je puvodne klasicka MVC technologie, ale pomoci ruznych dalsich frameworku se pouziva typicky jako komponentova (protoze JSF je soucast JEE specifikace ktera je koncipovana jako komponentova). Z toho u predchozich verzi vznikalo hodne averze vuci JSF protoze takovyhle ohnuti se podepisovalo na vykonu a kompikovanosti programovani. Aktualni verze JSF + JSP uz tohle resi, ale je moc brzo hodnotit jak dobre :-)

Ono vubec mi prijde ze nejaky striktni deleni MVC, MVP a komponentove frameworky je hodne umele. V predchozim zamestnani jsme napriklad jeli MVC i ve starem APS.NETu 2.0. Jednoduse jsme ignorovali cast toho co MS do .NETu cpe, napsali par knihoven a byla to klasicka ukazka MVC (odesel jsem akorat, kdyz se zacalo pro model vrstvu integrovat NHibernate).

Me osobne nejvic vyhovuje Apache Wicket jako komponentova technologie. Hodne lidi kteri programovali v ASP.NET WebForms presli prave na Wicket, protoze ma podobne principy skladani a programovani komponent. Na druhou stranu Wicket se da pouzit jako klasicky MVC framework :-). Je navrzeny tak, ze AJAX a REST aplikace se v nem tvori uplne prirozene.

Mozna srovnani s .NETem jako takovym je Spring. Resi priblizne stejny rozsah funkcionality (vcetne webovych aplikaci), ale hodne se lisi pristupem. .NET ma tradicnejsi imperativni pristup (ne striktne ale spis principialne) a Spring spis jde deklarativnim pristupem (dependecy injection, AOP, COC)

JavaBean se neoznačují POJO.

http://en.wikipedia.org/…_Java_Object

Tož pěkný článek, už se těším na pokračování ;]

Pokud nastane nějaká přípustná chyba (= se kterou bylo počítáno) způsobená uživatelem, třeba 404, pak ji co nejlépe popsat.
Pokud nastane vnitřní chyba, pak:
Jsem-li ve vývojovém prostředí, pak klidně popsat pokud možno co nejlépe.
Jsem-li v produkčním prostředí, pak se slušně omluvit a popsat co nejobecněji. Uživatele přece nezajímá, co se stalo. Tomu stačí, že to nefunguje a že on za to nemůže. Jestli je problém s databází nebo nastal NullPointerEx­ception může být uživateli úplně fuk. Komu to naopak fuk být nemusí je útočník.
Tolik k mému přístupu.

Vito – chvalim te za tvuj pristup – jen tak dal! Takovy utocnik kdyz dostane do ruky takovou NPE – tak pak nastava skutecne peklo!

Tak konkrétně NPE bez stacktrace je zpravidla na nic. (BTW: už jsem viděl blíže nespoecifikovanou banku jak ukázala něco podobného i se stacktrace :D)

Ale třeba info o problému s DB může inspirovat náhodného kolemjdoucího po zadání apostrofu k SQL injekci. A to si necucám jen tak z prstu.