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

Clanok si podrobne precitam az zajtra :) Teraz som na takuto obsaznu spravu velmi unaveny :)

Ale ozaj by som uvital


var al = new ArrayList<Strin­g>();


Pokial sa nechcem hrat s polymorfizmom, su to zbytocne opisovacky.

Jde o to, co myslíte tím hraním s polymorfismem. Já to chápu tak, že byste očekával následující význam:

ArrayList<String> al = new ArrayList<Strin­g>();

Jenže většina programátorů chce být na nějaké hrátky s polyformismem připravená, a tak očekávají

List<String> al = new ArrayList<Strin­g>();

V tom druhém případě by to ale znamenalo, že by se do popisu jazyka dostala tvrzení jako "třída java.util.ArrayList je implementací rozhraní java.util.List". A to tvůrci jazyka nechtěli.

Kto by chcel


List<String> al = new ArrayList<Strin­g>();


tak by to tak aj napisal, nevidim problem :D

Ak nie je dovod pouzivat polymorfizmus, tak ho nepouzivam, zhorsuje to citatelnost :) Holt patrim potom k mensine programatorov.

A v cem to zhorsuje citelnost? Zapis s var je dobry tak maximalne pro privatni promene v metode. Tech se zas tak moc netvori, kamkoli jinam stejne date rozhrani misto implementace proto, aby bylo mozne nasazovat mocky a cely kod testovat. Nehlede na to typ promene urcujete az podle prirazeni coz mi prijde dost hruzne a naopak daleko hure citelne, protoze musite precist cely radek byste vedel o co vlastne jde, jinak vam staci precist pouze kus radku do znaku =.

Ok, dam priklad z praxe.

Drajver z oraclu. Vypytam si od neho prepared statement
PreparedStatement xy = connection.pre­pareStatement("Bla­bla");

Automaticky som cakal, ze byde typu OraclePrepared­Statementm ale nie OraclePrepared­Statement je az fieldom OraclePrepared­StatementWrap­per. Ok, takze reku, ze uz ho mam. Ale ono to zasa bolo typu T4CPreparedsta­tement, ktory dedi od OraclePrepared­Statement.Tak ok, zasa som potreboval ziskat subclassu a z nej fieldy a tie az mi na nieco boli dobre.

Vsimnite si ten maglajz v predchadzajucom odstavci, zda sa to ako bluznenie, ale je to pravda .Proste potreboval som sa v tom vrtat a nejake veci si vytiahnut pomocou reflexie a zalogovat.

Ano chapem vyuzitie rozhrani v dependency injection, na ktore narazate. Predsalen tam sa to s tymi rozhraniami az tak neprehana a je to zrozumitelnejsie.

Ale vyuzivanie polymorfizmu v jave niekedy sposobuje, ze by si clovek radsej vyskriabol oko. Skratka niekedy sa veci zbytocne komplikuju, aj ked nemusia.
Ale to nie je o docitani riadku, ale o debugovani a rypani sa v neprehladnom kode.

Preto mi ten zapis, neprijde taky uleteny.
var a = new LinkedList<Strin­g>()
by znamenalo
LinkedList<String> a = new LinkedList<Strin­g>().

A co?

No nevím, ale tady podle mě nejde o polymorfismus. ArrayList není potomkem Listu, ale je to jeho implementace. Tady se jedná o oddělení rozhraní od implementace.
K tomu var bych řekl, že v javě se to tak prostě nepíše a nevidím důvod proč tam cpát každý jazykový konstrukt, který existuje jinde. Na platformě Java existují jazyky kde to tak psát jde(Scala, Groovy, Jython ...), tak komu to vadí ať použije je.

Nekdy by dokonce bylo jeste lepsi pouzit:

Collection<String> al = new ArrayList<Strin­g>();

Protoze rozhrani Collection nabizi skoro vsechny metody, jako rozhrani List. Ale jak kde, nekdo se dokonce v public API nestydi za ArrayList-y ;-)

No tak to se poustite na dost tenky let. U Collection netusite dve zakladni veci:
1) Jsou prvni trizene?
2) Bude tam prvek vice nez jedenkrat?
A popravde to dost casto to chci vedet.

List garantuje pořadí prvků a je indexovaný.

to prece nic nemeni na tom, ze se da napsat:

Collection<type> c = new ArrayList<type>()

ty vlastnosti zustanou zachovany.

Jak se mi "minulé novinky" zamlouvaly, tak tyhle zase tak moc ne. Toto se dá uspokojivě řešit něčím jako IOUtils.close­Quietly() (z Commons IO) nebo si napíšu vlastní metodu (klidně i s vyhazováním vyjímek):

void close(Closeable... objs) throws Exception {
    Exception ex = null;
    for (Closeable o : objs) {
        try {
            o.close();
        } catch (Exception e) {
          if (ex == null) ex = e;
        }
    }
    if (ex != null) throw e;
}

Jenze kam se tato metoda ma napsat? Do tridy, ktera s closeable objekty pracuje nebo jako staticka metoda (=funkce) do vlastni tridy? V prvnim pripade to bude copy & paste na 100 mistech ve vetsim projektu ne?

A navic to reseni v Jave (7) neni nijak genialni, to je pravda, ale zase je citelne a nestane se, ze byste zapomel na to, pridat referenci na tento objekt do vasi metody close (a to jeste na spravne misto - i kdyz tady to mate flexibilnejsi nez Java).

Jo a tusim, ze vyjimky (kdyz treba close()s vyhodi 3) se ve vasem pripade ztrati ;-)

Kdyz se neco deje "samo" neni to zrovna 2x prehledne. Jeste pochopit se to da u ruznych frameworku ale jako zaklad jazyka... nevim nevim. Ne vzdy chci volat close na vsem. Tim padem budou existovat pripady kdy nejake inicializace napisu do try() a nektere az do try{} - bude v tom jeste vetsi bordel.

Kam to napsat: nejlepe jako util tridu do java api. nebo jinam, to uz bude asi jedno.

Zapomenout se da na ledasco a ta nova syntax me nenuti ji pouzivat, takze zapomenout zavrit stream stejne muzu.

S tema vyjimkama: vyjimky se strati vzdy... nelze vyhodit 3 vyjimky najednou a nemuze to udelat ani tato specialni konstrukce. Podle logiky veci sem pochopil ze se vyhodi ta prvni a proto jsem to tak do kodu napsal. Klidne muzu vyhodit nejakou MultipleException ktera bude obsahovat seznam vyjimek...

Tohle je typicka staticka metoda do nejakeho helpru. Takze import static ... A znamena to pak volani close(opjekt) nic vic. (Btw. asi by bylo lepsi mit tu metodu lepe pojmenovanou).

P.S.: Nicmene si nemyslim, ze by pridani tohohle do jazyka byl nejaky spatny krok. Aspon je hned na startu videt co se inicializuje jako nejaky omezeny zdroj. I kdyz zase na druhou inicializujete tak neco v dobe kdyz jeste ani nemusite vedet jestli to budete potrebovat (treba vam ten kod vylitne driv nez se k pouziti daneho zdroje dostanete) v opacnem pripade se stejne nevyhnete spouste zanorenych try finally bloku.

Take si myslim, ze pridani ARM neni spatny krok. Ta inicializace az v dobe pouziti by sla mozna "obejit" nasledovne:

try (
  T t1 = new T("T1");
  T t2 = null;
)
{
  ... neco, neco, neco ...
  t2 = new T("T2");
}

Otazka zni, zda-li se s necim takovym pocita + programator musi davat bacha na NullPointerEx­ception.

S.

Nedaří se mi rychle najít, jak to bude se zachycením výjimek při volání AutoCloseable­.close(). Bude to v některém z příštích dílů?

Z příkladů v článku je patrné, co se stane v případě, když dojde k vyvolání výjimky i v bloku try {…} – výjimky z AutoCloseable­.close() se k té výjimce přidají jako odložené, a je pak možné si je přečíst z Throwable.get­SuppressedExcep­tions() (nebo se vypíšou při výpisu zásobníku volání). Ale co v případě, kdy v bloku try {…} k výjimce nedojde, ale dojde k jedné (nebo více) výjimkám v AutoCloseable­.close()? Vyhodí se poslední výjimka z close(), a k ní jsou případně přidány jako odložené výjimky z předchozích close()?

A jak se to bude chovat v případě, že k vyhození výjimky dojde v bloku finally {…} – stejně jako s try, tj. vyhozena bude výjimka z finally {…} a k ní budou jako odložené přidány výjimky z volání close()? A co v případě, kdy bude výjimka vyhozena v try {…} i finally {…} – výjimka z try se zahodí (jako dnes) a propaguje se jen ta z finally s vloženými potlačenými výjimkami, nebo se i ta z try přidá mezi potlačené? To by pak změnilo i význam kódu pro 1.6 přeloženého 1.7 kompilátorem, i když by ta změna neměla mít žádný viditelný dopad…

Vy pisete nejaky komplikovany kod. Mozno by sa niekedy hodili ale tie si mozete urobit pomocou standardneho kodu bez Closeable. Ale na 99% veci potrebujete v podstate jednoduchy handling. Nieco robim a to bud skonci OK alebo s chybou ktoru oznamym operatorovi (do logu) a skoncim.
Veci ako opakovanie operacie po N minutach a podobne sa riesia na vyssej urovni ako try/catch blok.

Uniká mi souvislost vašeho komentáře s tím mým. Já jsem neuváděl žádný příklad kódu, ptal jsem se, jak je ve standardu nadefinováno chování toho rozšířeného příkazu try. V článku autor poukázal na to, že může v kódu vzniknout paralelně několik výjimek, a je tam uveden příklad, jak se to řeší v určitém případě – a já jsem se zeptal na ostatní případy. Do Javy 1.6 mohlo několik výjimek „najednou“ vzniknout jen vyhozením výjimky ve finally a platilo pravidlo „poslední vyhrává“. V Javě 1.7 se tohle evidentně změní, tak jsem se jen ptal, zda Pavel Tišnovský (nebo někdo jiný) náhodou neví detaily.

void close() throws Exception;

Ach jo, na tom je dobře vidět zbytečnost celého konceptu checked exceptions. Oč by bylo pohodlnější, kdybysme v Javě měli jen unchecked. Chápu ale požadavek zpětné kompatibility...

Cituji z knihy Pavla Satrapy "Perl pro zelenáče":

Vstup se nejčastěji odehrává prostřednictvím konstrukce <>, které se říká diamantový operátor*. Ten načte...

* Z toho je vidět, jak jsou ti angloameričané slušní. Oni když vidí kosočtverec, napadne je diamant.

Konec citátu.

stejně tomu budou všichni říkat: http://cs.wikipedia.org/wiki/P%C3%AD%C4%8Da
(pevně doufám, že odkaz na wikipedii nebude považován za vulgarismus:)

Hle, Java se docela přibližuje k C#. Některé ty konstrukce zde jsou ale docela krkolomné. Chápu však, že nechtějí zaneřádit syntaxi jazyka, ale občas je třeba pokroku uvolnit uzdu...

Skoda, ze nezavedli "elvis" operator zapisovany obvykle jako ?. nebo .?, to by se v mnoha pripadech hodilo.

(tento operator vola metodu/pristupuje k atributu jen tehdy, kdyz reference neni null)

Dekuji za rychly vycuc sedmicky. Clovek to ani nemusi hledat.

No promiňte, ale jak koukám na tu diskuzi tak si nikdo i včetně autora článku nikdo nevšiml (tragikomedie je že to neví i lidi z coinu:-( ) že v části 5. Je operátor <> skutečně nezbytný a/nebo dostatečně obecný?
má chybu a to takovou že lze zapsat... viz jednoduchý test:

//kompilováno pod jdk6, javac kompilátor pouze upozorní na potenciální //unsafe operaci
public class CollectionTest {

@Test
public void testType() {
List<String> list = new ArrayList();
List<List<String>> list2 = new ArrayList();
List<List<Lis­t<String>>> list3 = new ArrayList();
Map<String, Collection<In­teger>> map = new LinkedHashMap();

//list.add(new Integer(1));//nejde zkompilovat
list.add(Strin­g.valueOf("he­llo"));//toto jo

//list2.add(new Integer(2));//nejde zkompilovat
list2.add(new ArrayList());//toh­le jo ! všimně te si že se nekontroluje typ !!!

List beztypovyList = list;
beztypovyList­.add(new Integer(3)); //tohle projde i s tím pitomým diamantem!!!

//tohle projde
for (Object object : beztypovyList) {
System.out.prin­tln(object);
}

//tohle NEprojde ale spadne ! a spadne to i s tím pitomým diamantem!!!
for (String object : list) { //java.lang.Clas­sCastException: java.lang.Integer cannot be cast to java.lang.String
System.out.prin­tln(object);
}
}
}

přesně nevylepší, proto také nevím jaký má důvod

Rozdíl je ve varování.

List list = new ArrayList();

se přeloží, ale s varováním.

List list = new ArrayList<>();

se přeloží jako

List list = new ArrayList();

(parametrické typy z levé strany se okopírují doprava), tedy bez varování.

Ano to jsem psal Filipe, ale to mi pořád přijde zbytečné přidávat konstrukci navíc (lze udělat pouze u vytvoření nového objektu) místo aby u vytvoření nového objektu zrušili to upozornění! ;-)
Pokud si vygeneruješ class soubor tak v obou případech bude stejný takže se se to opravdu redukuje na výběr mezi zrušení upozornění nebo přidávat novou konstrukci

tak jediný důvod který jsem našel je že pokud

List<String> strings = new ArrayList();
strings.add("he­llo");

//přidělím při vytvoření nové kolekce

List<Integer> integers = new ArrayList(strings);
//tak dál už to je potenciálně nebezpečné ale pokud udělám

List<Integer> integers = new ArrayList<>(strin­gs);
//tak mi to kompilátor nedovolí