"szerintem sokkal olvashatóbb egy értékadás az erre szolgáló operátorral (=), mint set/get függvényhívásokkal" eldontheted melyiket valasztod. Persze a kulso lib fejlesztoje is eldonti.
"globálisan írható mezők kissé veszélyesek tudnak lenni" immutable a kulcsszo. nem fogja irni :D
"hogy elkapod de nem kezeled le" de ez egyaltalan nem a nyelv hibaja, hanem a kodere meg a reviewere
"és megpróbálunk valami helyreállítást csinálni" hat ott altalaban lovesed sincs mi ment felre, es azt hogyan kell javitani (szerintem)
"Az autoboxing (java 5-től van)" aminek 10 eve, szoval van mar egy ideje ;)
"gyakorlatilag az egyszerű típusok által nyújtott teljesítményt bukjuk el vele, hogy ne fájjon collection-ökbe pakolni őket" ezt nem tudom ertelmezni mi koze az autoboxingnak collectionnonknek. Amugy a boxing majdnem 0 overhead
"A List és az int[]" itt valoszinuleg egy vegtelen ciklusba kerulunk, de most rajtam a sor ;) :D nem kotelezo hasznalni a tomboket, sot nem is ajanlott. Ha neked a List apija tetszik hasznald azt. Ha nagyritkan belefutsz valami tomb hasznalatba es a foreach-en kivul tobbre van szukseged alakitsd at collectionne
"oké, annyira azért mégis, hogy StringBuilder lesz belőle" mar re nem ;)
"hanem a + operátor felül van bírálva string-ekre" ezt sajna nem tudom ertelmezni, te + jelet irsz a compiler meg lecsereli valamire a hatterben, de ebbe neked semmi beleszolasod nincs (9-es Javaig). overloadolasrol akkor beszelhetunk, ha te a kodban tudod overloadolni. Az, hogy a compiler hogyan oldja meg bytekod szinten az nem szamit annak, az en olvasatomban. A compiler ertelmezi, amit leirsz, es hatekony gepi kodot csinal belole.
"nem tudom, nem próbáltam a 10-es Java-t" A specifikaciobol szedtem a peldakat. Az a para, hogy a generikusok csak compile time vannak ertelmezve, es ezert Java-ban megengedett a raw tipusok hasznalata. Tehat tok valid a var l = List.of(), ahogyan a List l = List.of() is, meg a List&ls;Object> vagy a List<?>. Ezt nem torhettek el, mert akkor 5os Javaig vissza mindent eltornek. Azt gondolom a visszafele kompatibilitast nem lehet a szemukre hanyni.
"java nem konvertálna automatikusan" semmit nem konvertal, megprobalja kitalalni a tipusat, es mivel az osszes valid int, ezert annak veszi. pont ezert nyelvidegen a var kulcsszo.
"mégis mily módon okozhatna visszamenőleges kompatibilitási problémákat?" hat pl mert eddig barmint bele lehetett tolni, ki lehettt szedni, vagy lehetett torolni. A fix utan pedig eltorik a program. "ott az eleve hibás volt!" hat egyfelol igen, masfelol meg nem, hiszen nem kellett vizsgalnod semmit, map.remove(akarmi) es ha kitorli kitorli ha nem nem, az api megengedte. Namost ha ezt megvaltoztatjak, akkor szomoru leszel, amikor a dependenciad dependenciajanak a dependenciaja miatt nem tudod forditani az alkalmazasodat.