Otevřená Java 2: OpenJDK, IcedTea a Java wars

14. 12. 2010 | Michal Vyskočil | Různé | 4620×

Projekt OpenJDK se poměrně rychle etabloval u většiny distribucí. Něktěří možná zaslechli zmínku o projektu IcedTea - je to, či není fork OpenJDK? A co jsou to Java wars?

Obsah

• OpenJDK
  • Vztah OpenJDK a Oracle Java
• IcedTea
  • Překlad pomocí autotools
  • Java Web Start a Java plugin
  • Zero assembler a Shark JIT
  • Patche
• Válka (nejen) o svobodnou Javu
• Závěrem

OpenJDK

V roce 2006 došlo ve světě opensource Javy k revoluci, společnost Sun Microsystems oznámila vznik projektu OpenJDK. Tento projekt postupně zveřejnil zdrojové kódy platformy Java SE (JRE, JDK a později i standardní knihovnu) pod licencí GNU GPL 2 s Classpath výjimkou – ta umožňuje, aby standardní knihovny (pod GPL) mohly být použity i pro neGPL kód. Zveřejněny byly zdrojové kódy připravovaného JDK7.

V následujícím roce se do vývoje zapojila společnost Red Hat, byly postupně zveřejněny zbývající části platformy, došlo k založení Porters Group zabývající se portem OpenJDK na jiné platformy, zveřejnil se repositář systému pro správu verzí Mercurial, vydala se JDK6 pod názvem openJDK6 a založil se projekt IcedTea. Většina zmíněných projektů postupem času rovněž přešla z GNU Classpath na OpenJDK, protože je daleko kompletnější a podporuje JDK6 a připravovanou JDK7.

Vztah OpenJDK a Oracle Java

OpenJDK vychází ze stejných zdrojových kódů jako Oracle JDK SE (OpenJDK6 je kompatibilní s JDK6), tudíž je s ní prakticky 100% kompatibilní. Odlišnosti nicméně existují – pro správu barev používá OpenJDK LittleCMS, kdežto Oracle Java proprietární technologii. Některé části jako zvukový systém byly přepsány. Rovněž technologie Java Web Start a Java applet nebyly nikdy uvolněny jako open source. To je mimochodem nejčastější případ, kdy si uživatelé všimnou, že nepoužívají proprietární JRE. Další rozdíly mohou být velice nečekané a záludné – libjvm.so musí obsahovat ladící symboly, protože na tom závisejí nástroje jako jmap. Distributoři obvykle tyto symboly z binárních symbolů odstraňují a přesunují do speciálních balíčků, což musí být u této knihovny explicitně zakázáno.

IcedTea

Jak už bylo řečeno v úvodu, ne všechny části standardní knihovny byly od počátku k dispozici. Bylo tomu tak především proto, že Sun neměl autorská práva na všechny části JDK a nedohodl se s jejich vlastníky na uvolnění pod svobodnou licencí. Z toho důvodu byla zveřejněna i malá uzavřená část, aby byl výsledek 100% kompatibilní – samotné OpenJDK by takto nebylo většinou distribucí považováno za open source. Navíc jediné JDK schopné přeložit OpenJDK bylo to od Sunu.

Proto vývojáři společnosti Red Hat založili projekt IcedTea, který odstraňoval závislost právě na těchto proprietárních částech. Části chybějící standardní knihovny pocházely z projektu GNU Classpath: nahrazení věcí jako správa barev open source variantami a projekt rovněž poskytl standardní cestu pro překlad OpenJDK přes autotools, která byla nezbytná mimo jiné pro podporu pro bootstraping projektu pomocí gcj. Poté, co Red Hat podepsal Sun Contributor Agreement, otevřela se tím cesta pro patche z projektu IcedTea do projektu OpenJDK, což pomohlo k rychlejšímu nahrazení zbývajících proprietárních částí. Projekt IcedTea nicméně existuje dodnes, protože poskytuje mnoho užitečných vlastností.

Překlad pomocí autotools

Díky wrapperům nad existujícím Makefile je překlad OpenJDK pomocí IcedTea daleko flexibilnější. Navíc tento způsob usnadňuje aplikaci patchů IcedTea, zapínání různých vlastností a podobně.

Java Web Start a Java plugin

Implementace Java Web Start a Java plugin – tyto technologie nejsou součástí Java SE a nebyly nikdy uvolněny. IcedTea tedy má vlastní implementaci, původně založenou na gcjwebplugin a od té doby několikrát přepsanou. Není bez zajímavosti, že právě IcedTea plugin přinesl nativní 64bit verzi dříve než Sun.

Zero assembler a Shark JIT

Samotný HotSpot, jako nejdůležitější část JVM, je psaný ve směsici assembleru a C++. Takový kód se nedá jednoduše portovat na jiné platformy. V rámci projektu IcedTea byl vytvořen tzv. Zero assembler, který odstraňuje nutnost používat assembler a umožňuje přeložit OpenJDK na jiných než původně podporovaných architekturách. Shark JIT je potom LLVM Just in time compiler pro Zero, který řeší výkonovou stránku problému. Jak Zero assembler, tak i Shark byly postupně začleněny do JDK7 a 6.

Mimochodem IcedTea podporuje překlad OpenJDK s jiným JVM, například CACAO.

Patche

Značná část IcedTea se točí kolem dodatečných patchů – příkladem může být odstranění podpory pro Motif, podpora pro PulseAudio nebo systemtap. Další, už poněkud méně vzrušující část, pokud nejste distributor, jsou backporty oprav bezpečnostních a kritických chyb nacházející se v dané verzi OpenJDK.

Válka (nejen) o svobodnou Javu

Jak bylo řečeno v úvodu, pojem Java je rovněž ochranná známka společnosti Oracle. Ta vyžaduje, aby se tento termín (respektive Java SE) vztahoval pouze na software, který projde přísným regresním testováním: Java Compatibility Test. Tato „maličkost“, tak nedůležitá pro běžné linuxové hackery, je životně důležitá, pokud hovoříme o enterprise nasazení. V dobách před OpenJDK existovala pouze read-only verze testů, jejichž licence nedávala právo je přeložit a spustit. Společnosti hodlající distribuovat Java (SE) implementaci si musely patřičné právo zakoupit.

V roce 2007 požádala Apache Software Foundation společnost Sun o poskytnutí testů kompatibility pro Java SE 5, které jsou specifikací této platformy vyžadovány – každá implementace tvrdící, že je Java SE 5, musí těmito testy projít. Zakoupení licence by situaci nijak nevyřešilo, protože by se ASF dostala ke staré známé závislosti otevřeného software na uzavřeném. Reakce Sunu byla, že se společnost snaží především o uvolnění zdrojových kódů JDK pod GPL, tak i příslušných testů. Mezi členy JCP, které kritizovaly Sun za neuvolnění licenčních podmínek, byly mimo jiné společnosti IBM a Oracle.

Zdrojové kódy JDK zveřejněny byly a pro JCK testy byla vydána doplňující licence, která umožňuje použití testů pro pro GPL implementace vycházející z OpenJDK. Tímto krokem Sun vyšachoval Apache Harmony z enterprise světa. V roce 2010 už pod taktovkou Oracle došlo k další ráně pro Apache Harmony. Společnost IBM, jakožto největší přispěvatel projektu, oznámila přesun svého zájmu od Apache Harmony k projektu OpenJDK. A důvod? Právě uzavřené TCK testy, které z Harmony činí v praxi nepoužitelnou implementaci.

Pozornosti společnosti Oracle neušel ani Google se svým Dalvik VM a Java API. Přestože byl Google opatrný a všude prohlašoval, že Andorid/Dalvik není v žádném případě Java a že se jedná o clean-room implementaci, čelí nyní žalobě za porušení bezpočtu patentů, copyrightu a intelektuálního vlastnictví, které Oracle momentálně vlastní. Jedním z argumentů je například skutečnost, že Eric Schmidt se přesunul do společnosti Google ze společnosti Sun, kde vedl Java tým. Není bez zajímavosti, že jedním z argumentů společnosti Google je, že použili zdrojové kódy projektu Harmony právě proto, že ASF nedokáže získat TCK testy, tudíž se o Javu nejedná.

Závěrem

OpenJDK splňuje všechny náležitosti otevřeného projektu: k dispozici jsou zdrojové kódy a dokonce i verzovací systém. Podepsání contributor agreement vyžaduje mimo Oracle i takové FSF, anebo Cannonical. Potud je to otevřený (dokonce svobodný) software. Můžete psát patche, portovat na nejrůznější platformy, studovat kód a podobně.

Na straně druhé Sun i Oracle poměrně aktivně vystupují proti ostatním svobodným implementacím, protože jejich největší zbraně – TCK a označení Java – jsou schovány za hradbou duševního vlastnictví, patentů a copyrightů.

       

Komentáře

[zde]

Eeeeh, k čemu to? Java zůstane stejně blbej jazyk ať už jsou ty tanečky vokolo zavřený nebo votevřený.. Ad "Java wars": kdo teda vyhrává?

[xkucf03]

„blbej jazyk“? Kolik jsi toho v něm napsal?

[Jardík]

Já jsem v něm pár věcí napsal. Není to úplně nejblbější jazyk, ale dobrý mi taky nepřijde. Mně by se java líbila, pokud by konečně dostala neznaménkové typy (vždyť je to sakra nutnost, jak se bez toho může někdo obejít!), bylo by zaručeno, že long bude mít atomický přístup, pro indexaci polí by se nepoužíval int, měla něco jako ukazatel na funkci, do kolekcí šli ukládat obyčejný inty, longy, ...

[Ladicek]

Jenom pár drobností.

bylo by zaručeno, že long bude mít atomický přístup

JMM. long deklarovaný volatile (a taky double) je atomický. Ale pokud přemýšlíš, že bys to začal dělat pokaždé, tak upozorňuju, že to nechceš.

pro indexaci polí by se nepoužíval int

To jako aby šel namapovat soubor do pole a nemusela se na to používat speciální třída? Ale je fakt, že pořádná "numerical tower" chybí.

měla něco jako ukazatel na funkci

MethodHandle od Javy 7 a uzávěry od Javy 8.

Není to úplně nejblbější jazyk

Já mám v Javě pár let a pár set tisíc řádků odprogramováno a řekl bych, že je to dost blbý jazyk

[Jardík]

long deklarovaný volatile (a taky double) je atomický

Ono je volatile v javě, to jsem nevěděl. Dík za tip.

Ale pokud přemýšlíš, že bys to začal dělat pokaždé, tak upozorňuju, že to nechceš.

Kdybych to nepotřeboval ve vícevláknových aplikací, tak by mi atomičnost byla na 2 věci (když nebudu počítat posixový signály, které asi java nevede)

[Ladicek]

No jo, ale on modifikátor volatile dělá taky to, že každé čtení a každý zápis znamená bariéru, což bude na tvůj vkus strašlivě zpomalovat Poohlídni se v java.util.concurrent, dost možná tam najdeš něco, co se snažíš naprogramovat sám. Pokud ti opravdu jde čistě o atomický long, bez atomického CAS apod., tak volatile long je trochu lepší volba než AtomicLong, ale tím to tak končí.

Mimochodem, signály se dají použít taky, sun.misc.Signal a sun.misc.SignalHandler.

[Stan Svec]

Jestli jsi neznal klíčové slovo volatile, což patří k těm nejzákladnějším vědomostem potřebných k vývoji paralelních aplikací v Javě, tak být tebou bych se do tvorby vícevláknových aplikací bez potřebné studie (jako třeba Java Concurrency in Practice) raději moc nepouštěl. Navíc jak už tu někdo uvedl, podle tvých požadavků to vypadá, že se snažíš používat Javu na něco, kde by se hodil úplně jiný jazyk. Já píšu v Javě především podnikové aplikace a to, co's vypsal, je asi to poslední, co by mi v Javě chybělo.

[Ladicek]

Java Concurrency in Practice je voňavá a vymazlená knížka, must read pro všechny javisty.

[stativ]

Já mám v Javě pár let a pár set tisíc řádků odprogramováno a řekl bych, že je to dost blbý jazyk

Řekl bych, že to platí skoro o každém jazyku. Ze začátku se mi zdálo C++ super, teď už ho považuji za blbý jazyk (přesto můj nejoblíbenější). To samé o Javě. Teď zrovna jsem ve stavu, kdy se mi zdá jako docela slušný jazyk C#, ale předpokládám, že ve chvíli, kdy v něm něco víc napíšu tak se taky přesune do kategorie blbý jazyk.

[Heron]

A je to o jazyku (tedy syntaxe, výrazové prostředky) nebo o těch věcech okolo (kompiler, standardní knihovna, ...).

Já már rád Javu pro to okolo (standardní knihovna, jdbc, skvělá dokumentace, moduly internetu lze najít snad všechno), ale čím dál tím méně se mi líbí jazyk jako takový (nemám rád, když se zavádí spec syntaxe pro věci, které lze udělat už s dosud platnými konstrukcemi jazyka).

Jako jazyk se mi líbí čisté C, ale psaní v něm je na rozdíl o Javy poněkud složitější.

[Ladicek]

Všechny případné účastníky diskuse neobeznámené do detailů s ekosystémem okolo Javy bych rád upozornil, že JDBC je bezkonkurenčně jedna z nejhorších existujících knihoven v celém softwarovém světě, a člověk, který ji prezentuje jako jednu z dobrých věcí na Javě, by měl být inherentně nedůvěryhodný.

Mimochodem, až takovíhle lidi začnou používat ARM bloky (jedna z novinek Javy 7), mám pro ně jednu dobrou zprávu: Konečně uzavíráte svoje ResultSety, Statementy a Connectiony správně. Nemusí pršet, stačí když kape.

[podlesh]

JDBC je v podstatě "céčková" knihovna (asi je zřejmé co bylo vzorem), takže podle toho vypadá. Na druhou stranu, když člověk vychytá všechny záludnosti, provede požadované rituály a přinese předepsané obětiny, tak svou práci odvede velmi dobře, a dokonce i výkon lze poladit. No prostě klasická C knihovna.

[stativ]

Myslel jsem jazyk jako takový. Ve chvíli, kdy ho dokonale zvládneš tak si uvědomíš kdy jsou jeho vyjadřovací schopnosti nedostačující.

[jehovista]

Ty mi pripadas jako traktorista, ktery nadava pod clankem o skodovce, ze se s ni blbe ora pole.

[Jiří Svoboda]

Jojo, neznaménkové typy. Nebo kdyby byl aspoň typ pro byte. Tohle mě taky neskutečně se*e...

Zlatý Céčkový char...

[petr_p]

Který ovšem může být větší než jeden byte.

[Filip Jirsák]

Pořád jsem nepochopil, k čemu by v Javě neznaménkové typy byly. Jaký program v Javě potřebuje s daty pracovat jako s číslem a zároveň ho zajímají nějaké bajty?

[Ladicek]

Jakýkoliv, který potřebuje načítat data v nějakém binárním formátu, nejlíp vytvořená programem v jiném jazyce? Jde to samozřejmě obejít, ale je to opruz.

[Filip Jirsák]

Takový program načte 8 bitů do proměnné typu byte, 32 bitů do proměnné typu int – pořád tam nevidím ten problém.

[podlesh]

byte je znaménkový. Na první pohled to vypadá jako drobnost, ale už třeba pokud o porovnání hodnot znamená tvrdý náraz (130 < 100).

[Filip Jirsák]

Jenže to porovnání a převod do jiné soustavy jsou právě ty jediné případy, kdy na znaménkovosti záleží. A zároveň je to operace, se kterou se při čtení nějakého binárního formátu setkáte jen velmi zřídka. Takže mám pořád pocit, že absence neznaménkových typů v Javě se hodí akorát tak do teoretických diskusí, a ve skutečnosti při programování s tím ještě nikdy nikdo žádný problém neměl.

[podlesh]

Takže mám pořád pocit, že absence neznaménkových typů v Javě se hodí akorát tak do teoretických diskusí, a ve skutečnosti při programování s tím ještě nikdy nikdo žádný problém neměl.

Pocit chápu, ale v realitě je to zcela naopak: v teoretických diskusí je to úplně jedno a neznaménkové typy můžeme klidně zahodit jako zbytečné, v realitě se pak problémy (ve formě bugů) objeví překvapivě často.

[Filip Jirsák]

Pocit chápu, ale v realitě je to zcela naopak: v teoretických diskusí je to úplně jedno a neznaménkové typy můžeme klidně zahodit jako zbytečné, v realitě se pak problémy (ve formě bugů) objeví překvapivě často.

Zvláštní je, že to „překvapivě často“ se zatím v několika diskusích nepřetavilo do nějakého konkrétního příkladu „tady jsem s tím měl problém“. Místo toho pokaždé někdo vymýšlí, kde by to asi mohlo problém způsobit.

[Luboš Doležel (Doli)]

Třeba já jsem s tím problém měl, i když měl jednoduché řešení. Potřeboval jsem ošetřit situaci, kdy se hodnota prvního znaku v ByteBufferu rovnala něčemu. Než jsem přišel na to, proč mi to triviální porovnání nefunguje... Stačilo přepsat hodnotu, proti které se porovnávalo, na záporné číslo (a u byte mi to přijde opravdu na hlavu).

Tedy nezpůsobuje to neřešitelné problémy, ale očekával bych, že to člověku, kdo se s tím moc nesetkal, problémy udělá.

[Filip Jirsák]

To je ten převod mezi číselnými soustavami – a problém je v tom, že někde (třeba v dokumentaci) jsou ty bity interpretovány (bez explicitního upozornění) jako bezznaménkové číslo a java je interpretuje znaménkově. Nazval bych to spíš nepříjemností, a u někoho, kdo potřebuje takhle zpracovávat binární data, předpokládám, že si s tím poradí.

[deda.jabko]

nejlepsi je nacist byte a pak to hned prevest na int. beztak to VM na ten int interne prevede.

[Ladicek]

Já vím, ale je to opruz. Nebo možná až zápis se dá kvalifikovat jako opruz, nevím, už jsem to naštěstí dlouho nedělal

[Pavel Tisnovsky]

"pro indexaci polí by se nepoužíval int"

Myslis jako, ze int ma na indexaci poli maly rozsah? To mozna v nekterych pripadech muze mit, ale na 32bitovych platformach, kde Java vznikla, stejne nemuze heap presahnout 4 GB (ani pro pouziti PAE a dalsich obezlicek), takze to nebylo problemem a rekl bych, ze ani dnes (64bitu) to v realnych pripadech neprekrocis. Nebo je takova realna aplikace, co potrebuje vetsi _jednorozmerna_ pole?

[deda.jabko]

uvedu to do kontextu. jardik potrebuje indexovat pres vetsi typ, protoze potrebuje do pameti namapovat 4GB soubor a v jave mu to proto nejde. a jsou i jedinci, kteri si mysli, ze je potreba namapovat do pameti rovnou 80GB dat.

[Pavel Tisnovsky]

Aha no chapu, ale popravde jsem se s takovym pozadavkem jeste NIKDY nesetkal, protoze ten soubor prece byva nejak strukturovany ne?

Takze pokud je to textak, tak pole ci lepe seznam stringu to resi (i kdyz - skutecne je potreba to cely napraskat do RAM?), pokud neco jako databazova tabulka, tak pole/seznam objektu (radku databaze - recordu) a pokud nejakej binarni bazmek (treba me ted napadlo 3ds nebo stare dobre FLI , tak pole/seznam/strom/whatever jednotlivych bloku.

Ale pozadavek na to mit silene velke jednorozmerne pole bajtu, to je IMHO na hodne nizke urovni a asi bych do toho nesel ani v cecku spis je to na hlubsi analyzu reseneho problemu.

btw: uz jsem videl par skriptu (v Perlu), ktere resily nejakou obdobu vyhledavani/grepovani v logu takovym zpusobem, ze nejprve nacetly celej soubor do pameti a potom iterovaly pres jednotlive radky. No panu programatorovi to na testovacich nekolikakilobajtovych souborech zajiste fungovalo skvele, v praxi s realnymi logy (treba z mesicniho provozu systemu, nekolik zalogovanych operaci za sekunud) to bylo jaxi horsi :)

[deda.jabko]

Aha no chapu, ale popravde jsem se s takovym pozadavkem jeste NIKDY nesetkal, protoze ten soubor prece byva nejak strukturovany ne?

ja to chapu a poprve jsem se s necim takovym setkal az tady. osobne, kdybych mel pracovat s necim tak velkym, tak si to stejne mapuju do pameti po castech, vzdy podle toho s cim pracuju nebo, podle toho, co dava logicky smysl. jeste by me teda zajimalo, jak velkou rezii bude mit sprava tak velkych mapovanych useku z pohledu jadra.

[Šangala]

Trošku pozdě si pročítám tuto diskuzi (holt to tak někdy dělám)
Já jsem na tento problém narazil, ne sice v Jave, ale obecně ve widlých, kde in na 64bit platfomrě je long 32bitový (model LLP64).
Aplikace pracující s mrakem bodů či polygonovou sítí, potřebují mít všechno v paměti a někdy je toho opravdu hodně.
Na patřičném hardware lze alokovat i více než 24GB (3×float XYZ * 2^31). A protože platforma dovoluje alokovat tyto bloky ale pro indexaci se „někde“ použil long, tak to vede k nepříjemnostem nemluvím již o tom, že vytvoříte jen index 8GB (int * 2^31).
Stejně tak komerční software na strojích s opravdu hodně paměti (fčul to bylo 96GB) narazí na tyto limity, protože si pro indexace používá 32bit integer a vývojáři si prostě říkají „tolik paměti jenom na indexi, kde by se to vzalo“
Samozřejmě u vývoje takové aplikace, je někdy složité se správně rozhodnou, někdy se pro indexaci použije 32integer, protože ukazatel má 64bit a to by ten index už bral 2× více paměti, takže Vám nezbude než se nějak rozhodnout, nebo nechat rozhodnutí na uživateli - něco ve smyslu použij small or huge model. :)
Ony nahlížet nějak strukturovaně na ohromný počet nestrukturovaných dat rychle, lze jedině tak že je opravdu máte v paměti, bo z toho disku to fakt nejde, proto se to pak dělá na strojích z nesmyslnou pamětí (v kontaktu jsem byl zatím jen se zmiňovanými 96GB RAM, nebo respektive stále můžu být, ale s čím přicházím do styku já, je na platformě Win, a díky zmiňovaným problémům cokoliv na cca. 16GB je zbytečné, kolegové pracující na linuxu říkají, „na 48GB“ už to nezpracujeme - je to málo, chtělo byt to i více než těch 96GB, ale zatím není možné více poskládat na jednom PC x86-64 /i tak tam musí být dva procesory, bo na jednom je max 48GB/).
Argument udělat pole indexů nebo to rozdělit na více bloků je někdy bezva, ale potom v algoritmech musíte mít další režije s tímto rozdělením, někdy dokonce žádoucí (snazší multithreadové zpracování), ale někdy nežádoucí.
Tím celým jsem jen chtěl naznačit, že zmiňovaní limita může být i v praxi opravdu limitou.

[vulgární Nick]

uz jsem videl par skriptu (v Perlu), ktere resily nejakou obdobu vyhledavani/grepovani v logu takovym zpusobem, ze nejprve nacetly celej soubor do pameti a potom iterovaly pres jednotlive radky

Ale to nemusí být nutně špatné řešení. Např. ve chvíli, kdy je načítání souboru náročné (jako log na vzdáleném počítači), kdy je soubor použit několikrát (jako několik hledání) atd.

Záleží, co člověk potřebuje, záleží, co člověk má za počítač atd.

[multi]

Mezi členy JCP, které kritizovaly Sun za neuvolnění licenčních podmínek, byly mimo jiné společnosti IBM a Oracle.

Zmenila se situace, tak se zmenil postoj firmy (zde Oracl) ... nic prekvapujiciho :D , ale

Jak tak ctu, co je v pozadi javy a hl. od te doby co mam ARM a na nem zkusenosti s javou a vykonem napr pythonu, tak si rikam, ze je na case se zase kounout na jazyk Vala.

[Stan Svec]

Díky za dobrý článek. Jenom nevím, jestli v tom mám úplně jasno. To, že OpenJDK je pod GPL licencí znamená, že kdokoliv může kód OpenJDK libovolně upravovat a následně dále pod GPL licenci šířit třeba pod jiným jménem? Pokud by taková implementace splnila TCK, tak by se dokonce mohla prohlašovat za Javu? Nebo to chápu blbě?

[vulgární Nick]

Ano, OpenJDK je možné upravovat a šířit v souladu s jeho licencí.

TCK (JCK) je jednoznačnou podmínkou, ale osobně si myslím, že nebude jedinou, viděl bych tam i nějakou administrativní podmínku. Ale nevím, nezkoumal jsem to.

[Trained.Monkey]

OpenJDK nelze svobodne upravovat a sirit pod GPL licenci. Po uprave musi projit TCK testy, a ty maji dost restriktivni licenci. OpenJKD nejde napriklad pouzit v mobilni platforme (konkurence J2ME) nebo v embedded zarizenich.

Viz http://skife.org/java/jcp/2010/12/07/the-tck-trap.html

[Stan Svec]

Super odkaz. Díky.

[Ladicek]

Ten článek je nádherně napsaný, paráda! Díky za link.

[xkucf03]

jj, akorát tam zapomíná na třetí možnost: žít ve svobodnější zemi (tzn. kde neplatí SW patenty).

[JoHnY2]

To je ti platny jen pokud vis, ze nikdy nebudes muset svoje dila prodavat i v zemi, ktera tak svobodna neni.

[Michal Vyskočil]

Ten článek svoje tvrzení nijak nedokazuje, takže pro mě je to spíš snůška osobních, nijak nepodložených a nepravdivých názorů.

Například z "OpenJDK community TCK license agreement" nijak neplyne, že by bylo spuštění testů nezbytné, nebo dokonce dávalo právo redistribuovat IP Oracle. A na openjdk.java.net/legal/ jsem nenašel nic, co by jeho tvrzení podporovalo. V zásadě jediné, na co jsou JCK testy skutečně nezbytné je mít možnost tvrdit, že distribuuje Java 6 SE platform, nebo tak něco.

Tvrdit, že GPLv2 nemá žádnou patentovou ochranu může jenom někdo, kdo tu licenci asi nikdy nečetl. Sekce 7 GPLv2+CE říká jasně - pokud nedokážete zajistit, aby uživatelé vašeho kódu měli možnost používat patenty v něm obsažené, pak jediným způsobem jak dodržet GPL je ukončení distribuce programu. A protože Oracle je ten, který GPLv2 kód primárně distribuuje, je to v první řadě on, který musí zajistit práva pro uživatele. Nebo přestat s projektem OpenJDK.

Ta část s mobilními telefony je potom už tak moc mimo mísu, že nemám sílu na ni reagovat.

[Stan Svec]

Tak teď nevím no. Ale třeba tady Apache ten článek potvrzuje. Navíc, kdyby s těmi patenty a omezením pro mobilní zařízení nebyl problém, tak proč pak Google pro Android nezvolil bezpečněji OpenJDK místo Harmony?

[Michal Vyskočil]

Tak teď nevím no. Ale třeba tady Apache ten článek potvrzuje.

V čem konkrétně? Například odkazovat se na licenci binárního JDK je v kontextu celého článku nesmysl. Bez splnění TCK testů nemůžeš říkat svojí implementaci Java (SE Platform). A používáním alternativních implementací se vystavuješ riziku žaloby Oracle za používání svého IP, jako se to stalo společnosti Google.

Navíc, kdyby s těmi patenty a omezením pro mobilní zařízení nebyl problém, tak proč pak Google pro Android nezvolil bezpečněji OpenJDK místo Harmony?

Netuším, proč Google zvolil Harmony a ne OpenJDK. Pravděpodobně proto, že je pod méně restriktivní licencí a nevyžaduje podepsání Copyright Assigment, jako OpenJDK.

Nicméně technicky tam žádné problémy nejsou, protože ani Harmony nebyl nikdy zamýšlen jako implementace J2ME, ale Java SE. Proto jsou veškeré stížnosti na TCK a mobilní telefony nesmysl, protože k tomu ty testy nikdy nebyly určeny.

Jádrem celého sporu Oracle versus Google je podle mě to, že Oracle chce fakticky zabít Apache Harmony a i budoucí alternativní implementace svojí platformy a ponechat OpenJDK, jako jedinou možnost.

[xvasek]

Já zase nechápu, jak projití TCK ovlivní, že výsledná distribuce bude patentově "čistá" a neabsolvování TCK a následná distribuce pod jiným jménem bude patentově "nečistá". To někde říká Oracle?

[Trained.Monkey]

Ale Oracle ti pouziti patentu dokaze zajistit, proste mu zaplatis za licenci...

[Michal Vyskočil]

Viz bod 7 GPLv2 - je to včetně požadavku na "royalty-free redistribution" včetně práva na používání patentů.

[Lukáš Zapletal]

Hodnocení: 100 %

[Michal Vyskočil]

Doplněk k Java wars:

Apache Software Foundation rezignovalo na místo ve výkonné radě JCP - tedy organizace, která se podílí na tvorbě nových vlastností této platformy.