( deje | 2022. 08. 14., v – 22:58 )

Tapasztalatom szerint a Java-féle szigor nem véd a túlbonyolított és összebarmolt kódok ellen: ugyanúgy lehet szar rendszert készíteni, mint bármi más nyelven. (Ld: bármilyen nyelvben lehet Fortran-ban programozni...)

Az egyik problémás eleme a checked exception. Az elv jó, de egy nagy rendszer közepére ha egy gyenge képességű fejlesztőnek exception kezelést kell írnia, néha bizony a catch ág ott lesz, de a kezelése nem... Kedvencem mikor catch (Exception e) kódokat írnak s népek EJB környezetben, aztán néz nagyokat sz üzemeltetés, hogy miért lett rollback-elve a tranzakció magától... Tapasztalatom szerint több problémát okoz, mint amit megold.

Az interfész nácizmus problémás tud lenni, rettenetesen olvashatatlanná tud tenni nagyobb kódokat.

Tiszta szerencse, hogy a 14-es Java óta van már végre record class, mert a property még mindig nem nyelvi elem (kb sz összes többi nyelvben van ilyen, csak a Java-ban nincs), és igazán kellemetlen volt szarakodni data classokkal így. Persze Lombok meg egyebek léteznek már nagyon régóta, de bakker!

Nem rossz nyelv a Java, de évekkel le van maradva használhatóságban (és olvashatóságban!) a konkurencia mögött. A lambda megvalósítás és az egész stream fw kimondottan fos lett. Az nem érv, hogy a jvm platform korlátokat hoz, mert az összes többi JVM alapú nyelvben jobbak a lambdák, pl Kotlinban is, és mégis kompatibilis marad.

Külön mókás, hogyan lehet pl iterátor implementációt készíteni Kotlinban (és C#-ban is): imperatívan megírod a ciklus blokkot, és kész, nem kell szarakodni az interfész implementációval és az állapottal. Pár sor kód egy komplett class helyett, és még olvashatóbb is.

Ha csak tehetem, Kotlint használok Java helyett, akárt keverten id (pár class Java, pár pedig Kotlin).