Názory k článku Novinky v JDK 7 aneb mírný pokrok v mezích zákona (1)

no ešte že som si miesto Javy vybral C# tam sú tieto "vychytávky" už 10 rokov. nedávno som bol nútený naprogramovať ničo v Jave, a bol som zhrozený koľko základných vecí v nej chýba, pričom v iných jazykoch ich berieme ako samozrejmosť. chcelo by to radšej sparviť kompiler C# ktorý by generoval bytecode pre JVM toto vyzerá celkom zaujímavo:

http://code.google.com/p/stab-language/

V C# nie su zasa ine vychytavky :D

Kdyby měla Java anonymní funkce, linq, lambda výrazy, extension metody apod., tak bys byl taky happy (Oracle slave).
Začni šetřit na placenou verzi JVM Dušane.

Tak se podívej na Scalu, ať vidíš, co C# může umět tak za 10 let.

Scala a C# jsou trochu jiné kategorie. Spíš bych to srovnával s F#.

Jsou a nejsou. Scala je syntakticky daleko podobnější C# než F# a dá se v ní programovat v zásadě velice podobným stylem jako v Javě nebo C#. Ano, přináší funkcionální prvky, podobně jako ta microsoftí varianta OCaml, jenže nelze nevidět, že funkcionální prvky se dostaly už i do C# (LINQ a lambda "delegates") a razí si pomalu cestu i do Javy. Jenže ve Scale se s nimi počítalo už při návrhu a proto tam vypadají úsporně a elegantně, v C# mi třeba připadají ty lambdy jako přilepené žvýkačkou.

Podivnosti z F# (a OCaml) typu rec a těžkopádná implementace inference převzatá z Caml (operátory typu .+.) je Scale také naprosto vzdálená. Scala je IMO prostě jazyk poučený z chyb při návrhu Javy (konzistentní přetěžování "operátorů", parametrické typy - generika, které Java původně zavrhla, flexibilnější dědičnost...). Funkcionální prvky jsou bonus.

Pořád jsem přemýšlel, jak je možné, že někdo rozumí všemu od fraktálů přes historii počítačů až po javu. A už to mám. Pavel Tišnovský je maskovaný Jára Cimrman!

S tou javou to je jednoduché, bude to tím, že pracuje pro Redhat a dělá na OpenJDK :-), snad jsem tedy nevyzradil nějaké tajemství.

To úvodní zkracování s Integer je zajímavé, ale dá se pokračovat až na Integer.toStrin­g(1), což je konečně postup, který se (snad normálně) používá :-)

Ten switch nad řetězci se mi pořád nelíbí – jediná výhoda proti jiným konstrukcím je výpočet hashe už v době kompilace, ale za cenu toho, že budu mít v kódu náhodně roztroušenou sadu řetězců (která se v Javě jinak vyjadřuje enumem).

Výhoda switche s řetězci je třeba v tom, že se to pěkně píše, je to přehledné atd. To, jestli je někde pár bytů navíc 99% lidí nezajímá (třeba celý OKsystem , když vzpomenu na všechny ty JBossy, ejb 3.0 a VVA a podobný generátor gigabytů zaplácané paměti :-)), 90% z toho zbylého procenta nepíše v javě a ta zbylá 0,1 procenta to samozřejmě nebude používat.

Pěkně se to píše, ale špatně se to pak čte nebo opravuje. Máte řetězce různě roztroušené po zdrojáku, upravíte ho na jednom místě a jinde zůstane neopravený… Když to chcete udělat správně, uděláte z těch řetězců konstanty; pak zjistíte, že je to vlastně uzavřená množina a mělo by někde být uvedeno, co do té množiny patří – tak z těch konstant ještě uděláte pole nebo kolekci. A ejhle, právě jste vynalezl enum.

A teď si ve Vašem příspěvku naraďte "String" za "int". Podle mě je to má pořád stejnou míru pravdivosti, o nic víc, o nic míň. Zakázal byste switch přes int?

Platí to stejně i pro int. Jenže zakázat to by znamenalo porušit zpětnou kompatibilitu.

I ve vámi uvedených případech máte pořád omezenou množinu řetězců, na které program umí reagovat. Když budete chtít vypsat uživateli hlášku, že má v CSV neznámý typ sloupce a podporované jsou jen sloupce a, b, c, potřebujete jejich seznam. Když budete chtít kód testovat, zase potřebujete seznam.

Já si dovedu představit spoustu příkladů využití switche přes řetězce, ale všechny jsou takové, že když to budu chtít napsat aspoň trochu „správně“ a udržovatelně, musím to stejně změnit na enum. Proto to podle mne do Javy nepatří – jsou jazyky, kde je to plně na odpovědnosti programátora, a když si chce programátor prostřelit koleno, jazyk mu k tomu ochotně poskytne nástroj. Java je ale jiná (a často se jí to vytýká) a pokouší se takovéhle postupy programátorovi co nejvíce znepříjemnit. A teď najednou povolí takovouhle věc.

A jak je to s uzavery? Slysel jsem, ze maji byt v Jave 7.

Zdravim, nemelo by byt v 7. oddilu, na 5. radce prvniho prikazu to nerovnitko v ternarnim prikazu naopak?

String s = (args.length > 0) ? args[0] : "";

například settery a gettery je – alespoň prozatím – nutné psát explicitně namísto použití dekorátorů či anotací;

A znáte projekt lombok? Doporučuje 10 z 10 pragmatických programátorů ;-).

Veliká škoda je, že vytvoření takové knihovny je poměrně složité, v porovnání třeba s Ruby. Kdyby tvorba takové knihovny byla v Javě jednodušší, tak si myslím,že by to Javu a myšlení lidí hodně posunulo.

Moc pěkný článek, děkuji!

Docela bych někdy uvítal nějaký popis, co je to "closure" - všichni o tom pořád mluví, že to jednou v Javě bude, ale co to je?

Včera jsem zrovna viděl prezentaci v nějakém jazyce, kde to je, ale nebyl jsem schopný pochopit, co to přesně dělá...

Uzaver je neco jako funkce, ktera se muze odkazovat na lokalni promenne z mista, v kterem byla definovana. Tim, ze pak muzete tu funkci nekam predat, ziskavate funkcionalitu, ktera zhruba odpovida tomu provest urcity blok kodu uvnitr nejakeho uplne jineho kodu.

Dobry priklad pouziti je, ze mate nejakou datovou strukturu, jejiz implementaci neznate (a nezalezi vam na ni), a chcete nad daty z te struktury provest nejakou operaci. Pak muzete v jazyce s uzavery implementovat situaci nasledovne:

1. Implementace datove struktury zavola nad kazdym prochazenym prvkem funkci, kterou ji predate.

2. V miste, kde chcete provadet operaci nad tou datovou strukturou, tuto operaci zabalite do funkce. Protoze jazyk podporuje uzavery, neni zde zadny problem - tato funkce se muze odvolavat na lokalni promenne v miste sve definice. Tuto funkci pak predate jako argument do funkce na prochazeni te datove struktury.

Je to krasne ciste - oddelite tim technicke detaily implementace od rozhrani. Teoreticky by bylo mozne udelat rozhrani k te datove strukture, abyste ji mohl prochazet primo, ale to muze zpusobit chyby, napriklad pokud byste pozadoval, aby se po skonceni prochazeni datove struktury jeste volala nejaka funkce (napr. uvolneni zamku nebo kurzoru).

jaky je ale rozdil oproti anonymni tride s definovanym rozhranim a vnitrnimi atributy?

Nejsem Javista, ale mam za to, ze anonymni tridy jsou obezlicka, kterou se tvurci Javy pokusili nahradit prave silu uzaveru.

(Do jiste miry jsou uzavery a tridy dualni koncepce - pomoci uzaveru lze tridy implementovat, stejne jako lze uzavery implementovat pomoci trid. Oba postupy s sebou ale nesou samozrejme syntakticky balast. Common Lisp, ktery ma objektovy system postaveny na uzaverech, tento problem s balastem resi elegantne pomoci maker.)

Co se stane, když při vytváření hash z "case" řetězce při překladu dojde ke kolizi? K tomu dojít přece může. Nebo jsem něco přehlédl?

Ja jsem to pochopil tak, ze kdyz se budou hashe shodovat, tak se provede jeste standardni equals

Java byl můj milášek ... <img>http://www­.alysion.org/ry­an/poems/Verse%20of%20th­e%20Rings_files/i­mage004.jpg
Ale v poslední době mě vše okolo Java nějak otravuje.
Z J2EE jsem vysloveně otrávený, přechod SUN pod Oracle a všechno s tím spojené, rozkouskovaný vývoj....

neda mi to:

http://www.ariel.com.au/a/teaching-programming.html

Ten článek jsem nečetl nijak podrobně, ale ten příklad v Java mi přijde záměrně složitě napsaný.

Pokud vynechám zabalení do objektu a import, získám stejné tři řádky jako v basicu....

int a = Console.readIn­t("Zadej cislo A:");
int b = Console.readIn­t("Zadej cislo B:");
System.out.prin­tln(a+b);

Čas: 1min včetně hledání nějakého mého příkladu kde jsem používal konzolu....

Přesně. Navíc try - catch je v tomto příkladě taky zbytečné, stačí přidat "throws Exception". System.exit na konci zbytečné. Jediná netriviální věc je použití BufferedReaderu (kvůli readLine), to začátečníka zmate.
Celkově ovšem překomplikované, autor toho příkladu evidentně nemá praxi.

Osobně na Java pomalu rezignuji. Třeba s NIO nejsem kamarád - to je moje chyba - asi mu nerozumím. Rozpracovaný projekt se chová zákeřně. Anglicky umím celkem dobře, ale velice složité principy z Anglického originálu prostě nepochopím. Po chvilce čtení si jen řeknu WTF? Naopak, pokud chápu princip nemám problém studovat i ty velice odborné texty. Všechno do sebe pěkně zapadá. NIO.2 mi už nedává smysl vůbec, evidentně k vůli nepochopení NIO. Všechno mi to začíná připomínat stav s J2EE. Už mě v JAVA skoro netěší programovat. Ano, mohl bych použít nějakou externí knihovnu která chování NIO odstiňuje, ale nemám rád černé skříňky.

Nejsem John D. Carmack, potřebuji jednoduchý programovací jazyk pomocí kterého udělám věci jednoduše, dobře a příjemně.

Slovo frustrace častým používáním vyčpělo a mám pocit že tedy můj pocit nedokáže vyjádřit dostatečně. Prostě mě už netěší v tom programovat. Z čistého diamantu se stává sudoku. Nemám rád sudoku.

Abych v nějakém jazyce mohl programovat musí mě těšit, aby mě mohl těšit musí být logický, nezáludný (PHP/Javascript ble ble) a snadno pochopitelný.
Vůbec si nejsem si jistý, jestli JDK7 je krok směrem k přehlednosti nebo krok k obdobné situaci jako je u J2EE. Nevím proč, ale mám pocit že JDK7 všechno jen komplikuje.

Slovo ,,jednoduchý" (programovací jazyk) není zvolené vhodně, jen nevím jak popsat mocný a přesto snadno srozumitelný programovací jazyk držící se zavedených logických principů.

Co zkusit Clojure? Mam rad Common Lisp, ale pokud delate s JVM, mohla by to byt dobra volba. Pokud bych delal v Jave, urcite bych se Clojure naucil. Vyhoda je, ze nemusite zahodit znalost Javovskych API.

Zrovna NIO je hodně speciální věc. Pro většinu použití je lepší použít "normální IO API". Viděl jsem i nějaké testy a pokud je NIO použito pro běžnou komunikaci s FS nebo na síti, tak je to srovnatelně rychlé jako "normální IO API" a v některých případech i pomalejší.

A samozřejmě gratuluji k pěkně napsanému článku.
Tak dobrých článků vychází opravdu málo.