Hlavní navigace

Vlákno názorů k článku Novinky v Javě aneb Tygří spáry od Milan - Jako člověk, který programoval v ledasčems se obávám,...

Článek je starý, nové názory již nelze přidávat.

  • 7. 11. 2003 10:50

    Milan (neregistrovaný)

    Jako člověk, který programoval v ledasčems se obávám, že zaváděním takovýchto novinek bude kód opět více nečitelnější (pro lidi, kteří dělají v 1.4 a níž). No uvidíme. Holt zase něco nového, čeme se bude muset Java programátor učit.....(=čas=náklady...)

  • 7. 11. 2003 11:42

    Martin (neregistrovaný)

    Souhlasim, ze kod se stane necitelnejsim a taky se mi to nelibi. Jeste bych pochopil zalozeni "generickych typu" i kdyz se obavam zpetne kompatibility.

    Rozsireny cyklus for, Static import a Metadata povazuji za velmi nestastne a zbytecne.

    Trocha nebezpecne se mi zdaji byt Generické datové typy. I kdyz neco velmi podobneho celkem dobre funguje v C# a nejsou s tim problemy. Ale bude se na to spatne zvykat.

    Naopak vitam Proměnný počet parametrů a Vyctive typy.

  • 7. 11. 2003 12:07

    astar (neregistrovaný)

    precti si clanek jeste jednou nebo se jen zamysli - se zpetnou kompatibilitou rozhodne zadny problem pri pouziti generickych datovych typu nastat nemuze. a v cem by to melo byt nebezpecne??? presunuje to velkou cast typovych kontrol pri pouziti kolekci do compile-time a to je opravdu dulezity krok spravnym smerem - zrovna absence tohoto mechanismu byla jednim z hlavnich nedostatku javy a zpusobovala velke mnozstvi obtizne dohledatelnych chyb.

  • 7. 11. 2003 12:42

    petr (neregistrovaný)

    Blbost, v Javě dělám už kolem čtyř let a mám za sebou pěknou řádku projektů a systémů. Chyby si způsobují sami programátoři a né nějaká absence mechanismu v jazyku. Z vlastní skušenosti vím, že pokud člověk nemá tuchy o tom, jak provést typovou kontrolu, tak ani v případě že to bude nějaký mechanismus dělat za něj, nebude kód takového člověka bezchybný a stále bude tápat. Takhle to nutí se zamyslet co to tam do toho editoru píšu.
    A o dohledatelnosti chyb: využitím exceptions a logů lze přesně zjistit kde která chyba je a opravit ji. Pro příště skus přemýšlet dříve než něco plácneš do fóra. Dík.

  • 7. 11. 2003 12:59

    Sickboy (neregistrovaný)

    No na druhou stranu s filozofii "chyby zpusobuji programatori" neni naprosto potreba existence vyssich programovacich jazyku.

  • 7. 11. 2003 13:08

    Jarda (neregistrovaný)

    Samozrejme, ze chyby zpusobuji programatori, na druhou stranu typovane kolekce skutecne zabrani vzniku nekterych z nich a usetri potrebu vpisovat kontroly do kodu rucne, nevim co se vam na tom nezda.. Samozrejme, ze to nezabrani vsem chybam, ale to neni duvod proti pouzivani takovychto mechanismu. To uz muzeme rovnou zrusit staticke kontroly typu a vychutnat si to ladeni prez vyjimky a log se vsim vsudy. Ale to uz pak nebude java ale python, ruby nebo neco podobneho..

  • 7. 11. 2003 13:39

    astar (neregistrovaný)

    asi nechapes ze je vyhodnejsi najit stejnou chybu pri prekladu nez za behu, coz je dost smutne. toho kdo "nema tuchy o tom jak se provadi typova kontrola" nepovazuju za programatora v jave a jak se ho dotknou pripravovane zmeny je mi uplne jedno, skutecnym programatorum to pomuze protoze budou moci vynutit volani metod s korektnimy parametry ve vice pripadech nez nyni UZ ZA PREKLADU. tobe nepripada vyhodne kdyz muzes rict, ze tvoje metoda pracuje napriklad s retezci, na urovni jazykove konstrukce a ne jen v nejakem komentari? obtiznou dohledatelnosti mam na mysli to ze misto kde se stala chyba (napriklad vlozeni objektu spatneho typu do kolekce) muze byt uplne jinde nez se chyba projevila (klidne v kodu nekoho jineho), navic program je chybny ale muze dlouho fungovat spravne.

  • 7. 11. 2003 13:50

    Bilbo (neregistrovaný)

    No, z exception a logu sice zjistim, ze chybu zpusobil napr. nejaky objekt v nejakem zasobniku na radce te a te, ale ze ten chybny objekt tam vlozila jina funkce uplne nekde jinde uz nemusi byt tak snadne zjistit ... to pak clovek obvykle musi nejakou dobu premejslet kde se to tam vzalo ... takze tak snadne to neni .... snad ve vsech progrtamovacich jazycich se muzou vyskytovat takove chyby, ktere se projevi jinde nez kde je programatr napsal (napr. memory leaky - i kdyz ty se v Jave obvykle nevyskytuji...., obvykle typu 'tady neco nastavim a o kus dal mi to na tom sleti')

  • 10. 11. 2003 11:12

    B-at (neregistrovaný)

    Preji pekne stravene chvile pri debugovani, breakpointovani a krokovani rozsahlych projektu! Pokud mi to odchyti prekladac budu jen rad. Nejde o to ze si to odzkousim na nejakych datech, nikdy nevim co predlozi aplikaci realne prostredi ruznych systemu, databazi atd.

  • 7. 11. 2003 12:44

    Snehulda (neregistrovaný)

    Staticke importy jsou asi opravdu spatne, nicmene prave metadata jsem povazoval za nejlepsi vlastnost C#, takze jejich zahrnuti do Javy je podle me velice dobrym pocinem ...

  • 7. 11. 2003 13:16

    Zdenek (neregistrovaný)

    Nesouhlasim. Vyhody prevazi nevyhody. Citelnost bude jiste vetsi. Prikladem muze byt prave pretypovani, zkracena sekvence 'for' (obdoba 'foreach' z jinych jazyku) a generickych typu. Jejich kombinaci je program nejen kratsi a prehlednejsi, ale vyhnete se take mnohym chybam a prekladac ma lechci praci pri obtimalizaci. Syntaxe techto zmen nejsou tak velke, aby je programator nevstrebal do jednoho tydne (maximum).

    Kdo programuje v C++, tak mu nebude delat problem ani genericke typy, ktere jsou na pochopeni pro zacatecnika asi nejslozitejsi.

    Generickymi primitivnimy typy myslite asi autoboxing primitvnich typu. Na tuto vlastnost ceka mnoho programatoru jake na smylovani. Predstavte si, ze je to jen zkraceni zapisu a lehce to pochopite. Stejne jako nepremyslite nad zapisem:

    "Ahoj".equals("Ahoj")

    pak stejne zapis:

    3.doubleValue()

    se rychle vzije do krve.


    Stejne jako zapis:

    (new String("Ahoj")).equals(new String("Ahoj"))

    je neprehlednejsi i zapis:

    new Integer(3).doubleValue()


    Hlavne pri vkladani do poli, map a mnozin mi to dost vadilo. Pro me je prece jedno jestli je to primitivni typ nebo jeho objektove zapouzdreni. No neni to prehlednejsi

    Map<Integer, Integer> map = new Map<Integer, Integer>();

    map.put(3, 15);
    int i = map.get(3);

    nez

    Map map = new Map();

    map.put(new Integer(3), new Integer(15));
    int i = ((Integer) map.get(new Integer(3)).intValue()

    Static import je vec, z ktere mam rozporuplne dojmy. Predstavil jsem si situace kdy je to vyhodne, ale i ty, kdy to kod zneprehledni.

    U metadat ukaze az cas, jake najdou vyvojari vyuziti. Ocekavam neco ve stylu C# u WebMethod a dalsi napr. jiz zminovane snadnejsi modifikaci rozhrani. Rozhodne to neni neprekonatelny problem pro programatora to pochopit. Nikdo Vas nenuti je pouzivat, ale pouzitim muzete zkratit cas uprav casti kodu a celych knihoven atd.

    Veskere upravy by meli byt spetne kompatibylni ve smyslu, ze kod vytvoreny pro 1.4 pujde bez uprav pouzit v 1.5 (krome noveho slova enum - kdo ho pouziva pro promenne muze vyuzit nejaky prepinac pri kompilaci). Mozna asi nepujde spustit kazda aplikace zkompilovana pod 1.5 se starsi JRE, opravdu nevim.

  • 7. 11. 2003 13:51

    Jarda (neregistrovaný)

    Mno nevim, nektere ty Vase priklady na pouziti autoboxingu by spis mohly slouzit jako protiargument vuci jeho zavedeni. Protoze jestli se programatorum vziji do krve cunarny jako

    3.doubleValue()

    tak budou produkovat programy generujici spousty zbytecneho balastu. Samozrejme, ze v urcitych situacich se to uplatni, viz napr. Vas priklad s kolekcemi, ale kdyz uz chcete argumentovat pro, tak proboha nevytahujte zmrseniny jako

    new Integer(3).doubleValue()
    (new String("Ahoj")).equals(new String("Ahoj"))

    ap. Navic ta analogie neplati, kratky priklad se stringem skutecne jen vola metodu a s tou delsi variantou nema mnoho spolecneho, kratky priklad s intem je vicemene eq. dlouhe forme, kompilator vam vygeneruje neco jako

    Integer.valueOf(3).doubleValue(),

    coz v aktualni implementaci vede k zbytecnemu vytvoreni noveho objektu, v ostre by snad melo byt nejake kesovani objektu pro casto pouzivane hodnoty.

    Jinymi slovy, autoboxing ano, ale jen tam, kde by se jinak pouzilo eq. reseni..

  • 7. 11. 2003 14:05

    Martin (neregistrovaný)

    Jako prave neco jako 3.doubleValue() mi pripada zverstvo.
    Kdyz tohle napise profik, tak asi vi co dela...ale bude kazdemu novackovi jasne, ze to udela novy object, ktery se pak posleze zahodi po vraceni doubleValue.

    Je pravdou ze ve Smalltalku se takove vaci taky delaji, jenze prave tam ta 3 uz je objektu.

  • 7. 11. 2003 14:25

    Mat (neregistrovaný)

    Nikde se nerika ze se musi vytvorit novy objekt, ktery se zahodi. Zalezi to na prekladaci a jeho optimalizacich. Pokud vznikne objekt a hned zanikdne neni problem tuto konstrukci obejit.

    Uznavam ze priklad 3.doubleValue() je umely (totezne z '(double) 3' ), ale nevim co je na tom prasackyho.

    Je to jen zvyk na primitivni typy a odmitani mozneho pohledu na ne jako na objekty. Pro me ma int a Integer stejnou vypovidaci hodnotu - cele cislo a je prece na me jestli vyuziji jeho objektovych metod nebo matematickych operator.

    Stejne tak v C++ mohu po implementaci operatoru nad objektem ComplexniCislo nahlizet jako na primitivni typ. Nic z objektoveho pohledu na svet tim neporusim.

  • 7. 11. 2003 14:56

    Jarda (neregistrovaný)

    Ale rika. Specifikace pravi, ze pokud pouzijete primitivni typ na miste wraperu, provede se konverze na prislusny wrapovaci typ, coz se momentalne provadi prez prislusnou factory method a vzhledem k zpetne kompatibilite se to bude dost tezko menit..

    Jinak osklive je na tom to, ze se pred programatorem skryva, ze jim specifikovana konstanta/objekt neni az tak uplne to, jako co se tvari, ale ze misto intuitivne predpokladaneho primeho zavolani metody se deji podivuhodne veci.. A to je to u konstanty jeste pomerne jasne, ze se deje neco podezreleho, u promennych a navratovych hodnot funkci to bude horsi..

    Jeste k tem prim. typum. To neni vec odmitani mozneho pohledu na ne jako na objekty, to je vec toho, ze to objekty nejsou, a ze z michani s nima budou jen problemy.. Ze ma pro vas int a Integer stejnou vypovidaci hodnotu je fajn, ale ekvivalentni nejsou, objekt se da pouzit na spoustu dalsich veci, jako napr. synchronizace ap., objekt se prirazenim nemeni, atd atd.

  • 7. 11. 2003 15:59

    Mat (neregistrovaný)

    Kdyby primitivni typy byli ciste objektove, pak by mohli existovat vyjimky ze syntaxe jako u tridy String - z duvodu prehlednosti (spojovanim retezcu pomoci znamenka '+' je vlastne vytvoreni StringBufferu, spojeni a vysledek). Take se tam neco deje aniz by to clovek videl. Prekladac take provadi optimalizace napr. "Ahoj " + "Jardo" + s zkrati rovnou na "Ahoj Jardo" + s. Tzn. ty kde je vysledek dopredu znam. Coz v pripade 3.doubleValue() je take. Souhlasim ze v pripadech jake je predavani parametru metodam takove optimalizace provadet nelze. Ale prekladaci nikdo nepredepisuje jak se ma chovat ve vyse popsanych pripadech. Takze optimalni prekladac do binarniho kodu ulozi rovnou 3.0

    Jelikoz musi zustat Java zpetne kompatibilni, pak nelze dosahnout namapovani matematickych operatoru na funkce objektu a odposteni se od primitivnich typu.

    U tridy String bylo rovnou pocitano jako z objektovym typem a vyhnuli se tak problemum z C++ ( jejich stringu a char*, v nekterych funkcich je pozadovano char* z duvodu kompatibility a v tele je to hned prekonvertovano do stringu, predkladame-li tedy string, musime ho nejdrive zkonvertovat do char*).

    Stejne jako ve formalnich jazycich je implementace cisel optimalizovana a tedy namapovana na ciselne typy pouzivane v pocitaci. Duvod je jasne: rychla a jedina moznost jak vyrazy spocitat na dnesnich pocitacich. Pouziti je, ale striktne funkcionalni a zalezi na interpretu jak si s tim poradi.

    Prikladem v Jave je trida BigDecimal, kterou by bylo mozne (jeji metody add, substract, multiply, divide) namapovat na operatory + - * /. Operator = by zustal zachovan tedy prirazeni objektu (dalsi operatory by se chovaly obdobne a += b je jen zkratka a = a + b). Pouziti by bylo stejne jako u int:

    BigDecimal a = 3.5bd, b = 2.3bd; // bd je oznaceni typu obdobne jako 3.0f
    BigDecimal i = a + b;

    Funkcnost zustava stejna jako je nyni, ale vypada to jako primitivni typ. Opacnym postupem z int, long, float, ... by se doslo k objektovym typum a prirazovani primitivnich typu by odpovidalo prirazeni objektu (objekt by se nesmel modifikovat stejne jako BigDecimal).

    Vysledek

    Integer a = 5, b = a;
    a = 3;
    Integer i = a + b;

    by byl stejny jako

    int a = 5, b = a;
    a = 3;
    int i = a + b;

    V pripade modifikace instance objektovych typu (zapouzreni primitivni) pri operaci = by byl vysledek jiny.

  • 7. 11. 2003 14:52

    Mat (neregistrovaný)

    Priklad:

    (new String("Ahoj")).equals(new String("Ahoj"))

    byl jen zpusob jak predvest co za nas dela prekladac. konstrukce "" tady nebyla chapana jako objekt String, ale posloupnost znaku. To ze konstrukce "" je chapana jako vytvoreni instance String se stejnym obsahem jako je posloupnost znaku je jen konvenci Javy (v C++ je to pole znaku). Moje chyba ze pisu rychleji nez myslim.

    Sticka metoda Integer.valueOf() vyzaduje String jako parametr, takze prekladac skutecne vyraz

    3.doubleValue();

    prelozi na

    (new Integer(3)).doubleValue();

    s moznymi optimalizacemi, takze vysledek bude asi

    (double) 3;

    Ano je to ekvivalentni zapis, ale jde spise o priklad ruzneho pohledu na typy v Jave. Znate-li nekdo funkcionalni jazyky pak vite, ze primitivni typy tam neexistuji na vse se pohlizi prozmenu jako na funkce: Cislo 3 je chapana jako nularni funkce vracejici vzdy hodnotu 3 (coz muze byt formalne jine vyjadreni vzajemne struktury mnozin - teorie mnozin).

    Nevim proc se Vam stale nelibi pohlizet na primitivni typy jako na objekty. Kdyby od zacatku byli primitivni typy v Jave navrzene jako objektove, pak byste se nad tim nepozastavovali (bylo by to asi i formalne cistsi).

    Zopakuji ze autoboxing se pouziva tam, kde je potreba objektovy typ a v pripade ze je predlozen primitivni typ je implicitne vytvoren odpovidajici objektovy typ. A stejne tak naopak.

    V pripade ze jsou zde dve pretezovane metody
    f(int) a f(Object) predpokladam ze vyraz f(3) povede k volani f(int) a ne k autoboxingu a volani f(Object).

  • 7. 11. 2003 15:22

    Jarda (neregistrovaný)

    Oki, Stringy uz nechame byt:) (i kdyz prekladac udela neco jineho, alebrz obe instance budou identicke a vytahnou se z konstant poolu misto aby se vytvareli v dobe volani..) Jinak ta staticka valueOf() co jsem mel na mysli je az z 1.5 a pouziva se prave pro boxovaci ucely.

    Co se optimalizaci tyce, prijde mi to jako zajimavy problem. Otazka je, jestli by si kompilator vubec mel takoveto optimalizace dovolit. Dokud se zachazi s prim. typy, muze si delat v podstate co chce, ale u wrapperu, jakozto objektu, ktere dostane z nejake knihovny, muze narazit na nejake sideefekty ap. Neco jineho uz to bude u JIT kompileru, ktery vidi skutecne implementace a muze analyzovat dobu pouziti objektu ap. ..

    A co se mi nelibi na michani objektu a prim typu - viz komentar asi o 2 zpet.;) Samozrejme ze by bylo cistsi, kdybychom meli jen objekty, otazka je, co by to udelalo napr. s vykonosti ap. Rekl bych, ze by nakonec stejne doslo minimalne k vzniku ekvivalentu poli primitiv, a zas by se objevila otazka, co jsou vlastne jejich prvky? A muzu je pouzit jako objekty? A co treba ona drive zminena synchronizace? Atd ..

  • 7. 11. 2003 17:27

    Mat (neregistrovaný)

    > i kdyz prekladac udela neco jineho, alebrz obe
    > instance budou identicke a vytahnou se z konstant
    > poolu misto aby se vytvareli v dobe volani..)

    muze platit u nekterych prekladacu, pokud se nachazeji u sebe dve konstanty a operator to dovoli (priorita), pak neni problem z nich udelat jednu a tu pak ulozit do poolu konstant

    > Jinak ta staticka valueOf() co jsem mel na mysli je az z 1.5 a pouziva se prave pro boxovaci ucely.

    OK

    > Otazka je, jestli by si kompilator vubec mel takoveto optimalizace dovolit. ...

    Veskere vysledky odvozene od predem danych konstant lze predpocitat. Nehrozi zadne nebezpeci (od toho jsou konstanty a operace povedou vzdy ke stejnemu vysledku).

    Optimalni prekladac by mel umet i

    "Ahoj " + "Jardo, ted je " + 5 + " hodin."

    v dobe prekladu spojit do

    "Ahoj Jardo, ted je 5 hodin."

    bez nebezpeci.

    > ... otazka je, co by to udelalo napr. s vykonosti ap ...

    To je otazka. Jelikoz by kazdy instance 'objektoveho primitivniho typu' byla zaroven i konstantou (viz muj prispevek o neco vyse). Mohl by s ni prekladac zachazet jako s primitivnim typem a jeji metody chapat jen jako operace nad nimi (ve skutecnosti to tak opravdu je). Meli by proste vysadni postaveni mezi tridami stejne jako String. Nejsem si jist co by to presto nestalo nejakou rezii v dobe behu aplikace.

    To vse je jen otazkou semantiky a implementace.

    V implementaci by to byl vzdy primitivni typ. Semanticky by to byl objekt. Rozdil v kodu nepoznas (viz. muj prispevek o neco vyse).

    Nevim jastli pujde v 1.5 napsat:

    Integer a = 5, b = 3;
    odpovida po autoboxingu
    Integer a = new Integer(5), b = new Integer(3);

    a nebo

    Integer c = a + b;
    po unpoxingu a naslednem autoboxingu
    Integer c = new Integer(a.intValue() + b.intValue());

    Pokud bude toto v 1.5 mozne, pak rozdil mezi nimy se vypari a obe dvojce obou prikladu jsou jen syntaktickou variantou teze semantiky.

    Jen by zustaly dvojice jmen pro totez (napr. int a Integer) - alias. Implementovan by ovsem mohl byt jen primitivni typ (napr. int). Prenesla by se tedy vyjimka pro primitivni typy ze syntaxe cisteho objektoveho jazyka do jeho implementace, tzn. navenek jen objektove typy, uvnitr samozrejmne nektere primitivni (tak jako u funkcionalnich jazyku).

    > Rekl bych, ze by nakonec stejne doslo minimalne k
    > vzniku ekvivalentu poli primitiv, a zas by se
    > objevila otazka, co jsou vlastne jejich prvky? A
    > muzu je pouzit jako objekty? A co treba ona drive
    > zminena synchronizace?

    K ekvivalentu poli primitiv by nedoslo. Vzdy by to bylo pole objektu (syntakticky) Implementacne to muze byt cokoliv. Zalezi na fantazii prekladace. Pokud by neexistoval rozdil mezi int a Integer. Pak

    Integer[] = {3, 4, 5, 6};

    Je chapano jako pole objektu Integer (je zaruceno ze tam neni nic nez Integer kontrolou typu vkladanych objektu) pak nevidim duvod proc by to prekladac nenahradil polem intu v pameti.

    Zopakuji, ze je to jen jiny pohled na totez. Primitivni typ a operace nad nim a objekt s metodami.

    U synchronizace bych potreboval vedet co mate na mysli za problem (lepe specifikovat).

  • 7. 11. 2003 12:12

    astar (neregistrovaný)

    vtip je v tom ze kdo je liny se to ucit tak muze psat po staru a nema problem. ovsem bude ho mit kdyz bude chtit pouzivat kod od tech co nejsou lini se ucit ale naopak jsou lini psat dokolecka stejny idiom iterace kolekci, stale za behu pretypovavat, hledat chyby v pouziti ruznych nahrazek vyctovych typu...

  • 7. 11. 2003 12:48

    petr (neregistrovaný)

    ušetření jednoho řádku kódu dle mého soudu není zas taková výhra.

  • 7. 11. 2003 13:25

    Zdenek (neregistrovaný)

    Kdybys cetl poradne, tak sis vsiml ze se nejedna jen o pocet radku, ale jeho prehlednosti. V ukazkach se kod zkratil i o nekolik radku, ale i poctu znaku na radcich, ale hlavne se logicteji rozclenil. Vyhodou je take prisnejsi kontrola v dobe kompilace. Coz vam take zmensi pocet probdelych noci pri hledani chyby.

    Argument ze mi vyjimka urci radek s chybou je chaba. Mnohdy je nutne vyuzit vnorenych vyjimek nebo vyvolani vyjimek jinych typu nez je chyba (pretezovana funkce nedovoluje vyvolat jine vyjimky nez funkce z predka). Dale se chyba muze projevit az pri pouziti chybne konstrukce a ne pri jejim vytvoreni.

    V takovych pripadech mohou nove konstrukce take pomoci.

  • 7. 11. 2003 12:45

    Mira (neregistrovaný)

    Souhlasím, nevím jestli se Sun neodchyluje od původních myšlenek návrhářů Javy

  • 7. 11. 2003 15:02

    Mat (neregistrovaný)

    Myslim ze hlavni myslenkou Javy bylo byt ciste objektovou - k cistoty se priblizilo autoboxingem/unboxingem a vyctovymi typy (SmallTalk je asi cistejsi :-( ). Dalsi myslenkou byla striktni typova kontrola - genericke typy. Dalsim je rychly vyvoj - rozsireni for, static import, promenny pocet parametru urychluje zapis a cteni a tim i rychlost uprav, a take auto/un-boxing a metadata (v C# velice urychluji vyvoj napriklad webovych metod).

  • 8. 11. 2003 2:14

    tomashv (neregistrovaný)

    Java IMO nechtela nikdy byt ciste OO, ale spis pseudo OO - prave kvuli primitivnim typum a jejich predavani hodnotou... Zrovna ten autoboxing mi moc cisty neprijde, ale to nic nemeni na tom, ze navrhovanymi zmenami se nijak nemeni objektovy vlastnosti Javy, vsechno je to zamereno spis na pohodli programatora. Mozna krome generics, ktery budou vynikajici pro compile-time kontrolu...

  • 8. 11. 2003 21:37

    Milan Zamazal (neregistrovaný)

    Neodchyluje, naopak. Svého času jsem pátral po tom, proč je Java tak nemožná, když za ní stojí někteří velmi schopní lidé. Nakonec jsem někde narazil na článek ze stránek Sunu, kde se vysvětluje, že Java musí být na začátku co nejjednodušší (co se definice jazyka týče), aby se ji snadno mohl naučit každý. Až na Javu přejde dostatek lidí, lze do jazyka začít přidávat složitější konstrukce. A vida, právě se to začíná dít.