V pondělí jsem se zúčastnil CZJUGu. Obě přednášky byly zajímavé, ale při druhé, týkající se nového Glassfishe, se mi do mysli neodbytně vkrádala zkratka NIH. Pro ty, kteří nevědí co to NIH je doporučuji pěkný Dagiho článek.
Zkratka NIH znamená Not Invented Here, česky by se dalo snad říci „nevymyšleno u nás“. Používá se, když někdo vymýšlí něco co už bylo dávno vymyšleno, jenom proto, že to nevymyslel on. Přesně v tomto duchu se nesla prezentace Glassfishe. Potřebovali modulární systém, tak si ho naimplementovali. Potřebovali IoC kontejner, tak si ho naimplementovali. Potřebovali jezdit do práce, tak si sestrojili něco na čtyřech kolech s motorem. (I když, teď si nejsem jistý, jestli to poslední zmiňovali). Vůbec nevadí, že už existují funkční vyzkoušené modulární systémy. Vůbec nevadí, že existuje hromada IoC frameworků. Napíšeme si to znovu a mnohem lépe.
Domnívám se, že v tomto případě nešlo o hloupost nebo neznalost. Myslím, že za tím stojí politika. Asi si myslí, že by vypadalo hloupě, kdyby používali Spring. Co by tomu řekli lidi. Vynálezci EJB, autoři přehršle skvělých a bezchybných JSR používají něco co není posvěceno JCP! Nebo nedejbože používat OSGi. Fuj.
U toho OSGi bych se chvíli zdržel. Je to standard, se kterým se budeme setkávat stále více a více. Slouží k implementaci modulárních systémů, umožňuje nadefinovat moduly, které mezi sebou komunikují pomocí daného rozhraní, definuje životní cyklus a mnoho dalšího. První verze spatřila světlo světa v roce 2000, teď je ve verzi 4. Existuje několik implementací. Používá se v automobilech, stojí na něm Eclipse, začíná ho používat BEA, jede na něm WebSphere 6.1 a další. Člověk by řekl, že to je věc, která by stála zato, aby ji vzal na vědomí i Sun.
Chyba lávky, Sun rozjel vlastní specifikaci JSR 277 (Java Module systém), která obsahuje jakousi nekompatibilní podmnožinou možností OSGi (mimochodem OSGi najdete pod JSR 291). Jelikož za JSR 277 stojí Sun, má velkou šanci se dostat do Java EE 6. Že neexistuje žádná vyzkoušená implementace? Nevadí. Že se nepoučili z chyb ostatních? Nevadí. Peter Kriens, jeden s klíčových lidí OSGi, popisuje, jak se snažil dostat do skupiny, která na JSR 277 pracuji. Prý ho odmítli s tím, že už jich je tam moc. Proč myslíte, že se Sun takto chová? Já si myslím, že je za tím NIH.
Poznámka: Dnes jsem se nechal trochu unést. Proto jsem článek prošpikoval odkazy, abyste si mohli udělat vlastní obrázek. Budu rád, když mě někdo vyvede z omylu. Zajímavou diskuzi najdete také na InfoQ
S tim IoC containrem jsem take nedal. Vysvetleni, ze potrebovali komponenty nahravat on demand a to zadny z existujicich frameworku neda mi prislo minimalne usmevne. Dobre, chapal bych to u Springu, ktery se jim mohl pro jejich ucely znat prilis tezkopadny, ale proc nevzali Guice, ktery nepridava zadny overhead? Kdyz jsem tam videl ty ukazky, tak mi to prislo jak druhy Guice. Ohledne JSR 277 bych rekl, ze to neni tak jiste, ze se nakonec prosadi. Podle toho co se deje kolem OSGi a ruznych zakulisnich informaci, ktere prosakuji, bych to nakonec tipoval, ze se OSGi podari protlacit.
Co jsem slysel jsou za tim politicke duvody, Sun proste nemuze udelat soucasti Javy neco nad cim nema kontrolu.
Sun uz jeden modularni system ma v Netbeans. Je starsi nez OSGi a ma obdobne featury. Takze neodzkousene implementace bych se nebal 🙂
Ten system v NetBeans rozhodne neni tak siroce pouzivan a proveren jako OSGi, ke kteremu existuje nekolik komercnich i open source implementaci. Kazdopadne “kdo chce psa biti, hul si vzdy najde”…
Ahoj, mam k tomu par komentaru:
1. Vsichni se navazi do Sunu, ze dela NIH ale temer nikdo se nenavazel do Google kdyz prisel s Guice. Cim to? 🙂
2. Sun puvodne zalozil OSGi alianci a nyni se k ni opet pridal, existuji dobre duvody proc nelze OSGi pouzit v Glassfish. Bohuzel je nemuzu rozebirat, je to confidential informace. Ale veci nejsou tak cernobile.
3. Prijde mi, ze se v CR zacina rozsirovat trochu sport “navazeni se do Sunu”. Ne vse co delame se vyvede (napr. puvodni EJB byly spatne, JCP neni idealni, atp.), takze chapu duvody. Na druhou stranu bych chtel rict, ze me to dost demotivuje k tomu, abych se snazil shanet zajimave speakery ze Sunu pro CZJUG, kdyz pak muzu ocekavat takoveto reakce.
ad 3.) Nerozumim tomu proc se certis Roumene. Sun dela samozrejme mnoho dobrych veci pro komunitu, Javu atd. Tebe by naopak melo motivovat shanet ty speakry, kteri by tyhle kontroverzni rozhodnuti vysvetlili. Musis to brat tak, ze jsou rozhodbuti se ktereymi vzdy nekdo souhlasi a nekdo ne. Vzdycky tu musi byt opozice, ktera to pokud mozno konstruktivne tlaci vpred. Pokud by tu nebyla, stale bychom meli takove odstrasujici priklady jako EJB.
ad 1.) Do Googlu jsme se navazeli, kdyz defacto forknul Javu pro mobilni zarizeni viz Gavlik, Android etc. Guice je opravdu jenom IoC framework nic vic nic min. Nevim jaka byla situace pred jeho vznikem, ale zda se mi, ze tu nic tak lehkotonazniho nebylo.
ad 2.) To ze by byl problem prepsat GLassFish na OSGi chapu, ale nerozumim tomu proc to michas s IoC. Krome toho plno AS ted ohlasilo , ze migruji jejich komponentovou architekturu na OSGi. Jak rikam, tohle bych GlassFishy nevycital. Kazdopadne pro Javu mi prijde OSGi jakodostatecne provereny model oproti JSR-277, kterou defacto vymyslite na koleni
Jeste me trochu zarazi, ze jsou nejake confidental informace, ktere ovlivnuji architekturu open source produktu jako je GlassFish. Nemeli by to byti spise tak, ze pokud je to open source, tak jsou vsechny tyhle architektonicke informace nekde zverejneny. Nemelo by se o nich diskutovat v GlassFish komunite misto nejakeho adhoc diskusniho krouzku uvnitr Sunu. Nevim jak to funguje v pripade GlassFishe, takze to jsou jenom spekulace, ale pokud to tak je, tak me to trochu desi ;-).
Pro Romana Štrobla: Sport navážení se do kohokoliv není módní jenom v ČR. Uznávám, že můj příspěvek byl hodně jednostranný. Ale je pochopitelné, že jsou lidé citliví na kroky Sunu. Sun stojí za Javou a lidé si o to více všímají toho, když dělá kontroverzní kroky. Já se opravdu bojím toho, že Sun procpe do Javy nevyzkoušenou technologii. Opravdu z toho mám strach, to je krok, který může Javu potopit a já se Ruby učit nechci.
Vztah k open sourcu je podobná věc. Sun tvrdí, že je pro open source, ale často se podle toho nechová. Chápu, že se může narazit na nekompatibilitu licencí, ale to se dá řešit. Souhlasím s Dagim, že mít confidential informace není moc open.
I když si myslím, že EJB a JCP mají hodně daleko k ideálu, neznamená to, že nemám rád Sun. Kde by Java bez něj byla. Takže tě prosím, dál sháněj lidi na CZJUG, trocha diskuze nikoho nezabije.
Zaujimavy nazor, skoda len, ze nie je v anglictine… Takto si to Kohsuke nemoze precitat.
@Dagi:
> Nerozumim tomu proc se certis Roumene.
Snazim se privadet na CZJUG speakery ze Sunu a diky reakcim v blogach nasi komunity se mi to tak akorat vymsti (nejen Kohsuke, ale i reakce na Laurie Tolson, reakce na Sun tech days, pripadne na prezentace NetBeans, atd.). Takze uz me prestava bavit se snazit, kdyz pak z toho jsou tak caste negativni reakce. Navic tyhle diskuse v cestine jsou stejne dost bezpredmetny, protoze si to stejne vetsina vyvojaru Glassfishe neprecte.
Dobře napíšu to i anglicky (a asi trochu míň pichlavě).
Na příslušné přednášce jsem sice nebyl, přesto si ale dovolím v něčem nesouhlasit. Je pravda, že znova implementovat MVC framework nebo ORM není dobrý nápad pro programátora enterprise aplikací, na druhou stranu ale pokud by to nikdo nikdy nedělal, měli bychom třeba jenom Hibernate a řada dalších, zajímavých knihoven se stejnou funkcí by neexistovala (nechme teď stranou, která z nich je nejstarší a přežila by).
Vývoj aplikačního server považuji za dostatečně nízkoúrovňové programování k tomu, aby bylo možné vyvíjet třeba vlastní IoC knihovnu. OSGi je možná něco trochu jiného, ale snad i to je možné odpustit v implementaci AS – zůstává otázkou, jestli je třeba mít i to JSR jako odlišný standard od OSGi.