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

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