Vlákno názorů k článku
Java na webovém serveru: porovnání Javy a PHP

Jsem zvědav na porovnání výkonnosti, potřeby systémových prostředků atd. Bohužel my s Javou máme ohledně provozu jen ty nejčernější zkušenosti. Jakmile s aplikacemi pracuje více uživatelů, rychlost klesá limitně k nule. Problém s verzemi Javy je skoro stejný jako u PHP, takže pak už porovnáváme objektový model, štábní kulturu atd. V tom je PHP silně propadající, nicméně to neznamená, že pokud si na to zvyknete, že to není celkem dobrý sluha a těžko hledat lepšího (pro web)…

Podělte se o jaké aplikace se jedná, jaké je nastavení systémových prostředků, verze Javy apod. Protože to jak to popisujete není nutně chyba jazyka.

no dejme tomu aplikace typu spisová služba, oběh dokumentů či GIS aplikace. Problém je v tom, že podobně napsané aplikace v PHP či .NET nevyžadují tak nabušený server. Jakmile je to řešení v Javě, tak požadavky na paměť výrazně narostou. Je to logické vzhledm k filozofii Javy, ale občas je to enormní, pokud s aplikací pracuje několk stovek uživatelů najednou. Nebudu asi zabíhat do detailů, jestli je to aplikačním serverem, způsobem komunikace s persistentním uložištěm atd.
Java je prostě super, logická a přehledná, trochu ukecanější než PHP, nutí vás víc domýšlet každý krok a nutí vás k objektovému modelu. PHP je jednoduchý nenáročný (na naučení i na prostředky) scriptovací jazyk, který se už trochu zlepšil a můžete v ně programovat jak úplně prasárny, tak klasicky sturkturálně nebo celkem slušně objektově a na 99% aplikací vám to bude stačit. howg a pěkný večer

V čem se principiálně liší filozofie .NET a Javy?
Požadavky na paměť u Javy určitě jsou, už jen kvůli JIT, což je ale v tomto případě vyváženo optimalizacemi. Je teda taky možné zvolit např. AOT JVM.

nelisi sa prakticky v nicom. C# a v podstate starsia .NET platforma bola opajcnuta od javi. Dokonca aj niektore nazvy metod maju rovnake ;)

Právěže je to s trochou nadsázky taky můj názor.

Ad problem s verzemi: Pokud se dobre pamatuji, PHP nekolikrat vydalo novou verzi v citelne mire zpetne nekompatibilni. U Javy mozna nejake drobne zpetne nekompatibility byly (nejsem az tak dobry historik), ale rozhodne je na tom v tomto ohledu lepe, nez PHP.

Např. když v Javě 5 zavedli enum, některým lidem přestaly fungovat jejich dosavadní zdrojáky, protože tohle nové klíčové slovo v nich používali třeba jako název proměnné. Ale takováhle nekompatibilita je dost výjimečná a obecně je Java hodně konservativní. Za enum jsou všichni rádi a nová funkcionalita bohatě vyváží tu nutnost přepsat trochu ten starý kód (pokud měl člověk fakt smůlu a tohle slovo pro název proměnných používal).

Soudit, jestli je i v PHP nekompatibilita vždy vyvážena novými užitečnými funkcemi, nechám raději na ostatních (osobně mi přijde, že často ne, soudě alespoň podle reakcí PHP vývojářů).

enum je asi tak nejzbytečnější rozšíření, co se do Javy 5 dostalo. Je to prakticky převod vzoru „typesafe enum“ do jazyka s minimální úsporou kódu, asi největší přínos je ve správně implementované serializaci. Ale enum-singleton prostě žeru :-)

Do té doby ale většina vývojářů používala textové nebo celočíselné konstanty, jejichž problém je jednosměrnost a fakt, že nejsou nijak seskupené. Zjistit zpětně z hodnoty (třeba 1, 0, 5, „blabla“) o jakou konstantu se jedná je prakticky nemožné (leda pomocí relfexe procházet a porovnávat, ale to musím vědět aspoň třídu, ve které hledám). Taky když nějaká hodnota má jako parametr int/String musím se dívat do dokumentace, kde hledat příslušné konstanty – kdežto v případě enumu vím i bez dokumentace, co tam patří a nemůžu tam zadat úplnou blbost (jako třeba natvrdo zadané číslo, které nepochází z žádné konstanty), protože jinak by se mi program ani nepřeložil. Takže IMHO enumy v Javě užitečné jsou.

„typesafe enum“ jde sice použít, ale kdo ho skutečně používal? Většinou jsem totiž viděl kód zaneřáděný těmi textovými/číselnými konstantami.

To asi nebude chyba jazyka ani frameworkov. Java sa pouziva na velke enterprise aplikacie. My prevadzkujeme viacvrstvove Java clustre pre velke organizacie. Ziadny problem ktore zle napisaneho kodu neexistuje. A to niektore dostavaju pekne do tela. Importy 10MB XML suborov radovo 10.000 denne popri beznej webovej pravadzke nad databazou. Tisice uzivatelov/session online.