Java 7 nylevi újdonságok szubjektíven
Ok, hogy már 2011 nyara óta kint van, de hozzám csak most jutott el a File Watcher api kapcsán.
Az API változás nem igazán szokott meghatni. Java-val szállított API és library annyira nagy, hogy az már szinte káros. Persze értem, hogy ha nagy akkor standardként lehet sok-sok eszközre számítani. De a másik oldalról ez megkötés is, mert sok API nem a legoptimálisabban lett megtervezve és az implementációk sem mindig jók. Manapság egy thirparty lib-et beilleszteni nem egy nagy gond. Hosszabb távon szerintem jobb lenne gy olyan megoldás, hogy választhassam, hogy melyik csomagot akarom telepíteni. Valahogy úgy, mint más rendszerekben a csomagok (lásd ruby gem)
Az újítások nem minden aspektusát emelem ki, de annyit igen, hogy érteni lehessen az izét.
The try-with-resources Statement
equivalent with
Ezt a szart.
Tudni kell, hogy a közösség nagyon régóta várta Java-ba bevezetni a closur-okat. De az nem történt meg.
És a fenti példa closur-okkal API szintre hozható lett volna
A fenti példában nincs Scala foglalt szó. Ebben csak sima függvényhívások vannak. De van closur!
De ehelyett java-ban a nyelv szintaxisát buherálták meg és ezzel növelték a nyelv komplexitását.
Nagy különbség van API és nyelvi komplexitás növelésben. Mert míg az API esetén választási lehetőséged van, hogy melyiket használod, addig a nyelv esetén már nincs.
Handling More Than One Type of Exception
Nagyon jó, nagyon hasznos. Rájöttek, hogy a java kivételkezelési stratégiája nem a legrugalmasabb. Pontosabban az a gond, hogy checked excpetion-ök vannak garmadával, még akkor is, ha érdemben alig van olyan eset, amikor le lehet kezelni.
- Bruce Eckel, vagy ez
- Sokak által kedvelt Spring Framework sem nagyon dolgozik checked exception-ökkel.
Ezzel egy lépést tettek előre, hogy ahol nem kell ott ne kelljen mindent felsorolni. Főleg ott, ahol az excpetion-ök együtt járnak. Például a Jakarta Beanutils majd minden metódusa ugyan azt a 3 kivétel dobálja majd minden eljáráshívásnál.
Nagyszerű újítás.
Binary Literals
Semleges. A teljes szakmai múltamban nem vettem volna hasznát.
Underscores in Numeric Literals
1long creditCardNumber = 1234_5678_9012_3456L;
Nagyon jó. Hiányozni nem hiányzott, de azért hasznos kis trükk a kód olvashatósága érdekében.
Strings in switch Statements
1public String getTypeOfDayWithSwitchStatement(String dayOfWeekArg) { 2 String typeOfDay; 3 switch (dayOfWeekArg) { 4 case "Monday": 5 typeOfDay = "Start of work week"; 6 break; 7 case "Tuesday": 8 case "Wednesday": 9 case "Thursday": 10 typeOfDay = "Midweek"; 11 break; 12 case "Friday": 13 typeOfDay = "End of work week"; 14 break; 15 case "Saturday": 16 case "Sunday": 17 typeOfDay = "Weekend"; 18 break; 19 default: 20 throw new IllegalArgumentException("Invalid day of the week: " + dayOfWeekArg); 21 } 22 return typeOfDay; 23}
Ideje volt!
Type Inference for Generic Instance Creation
Nem vagyok nagy híve a generikusoknak.
Elképesztően verbose(bőbeszédű, feleslegesen bőbeszédű) a szintaktikája. Sokszor azért sem használom, mert olvashatatlanná teszi a programot. És el is vezet a következő gondomhoz.
Gyakorlatilag kötelező. Pontosabban alapból nem generikus használat esetén tele vagyok compile warninggal, ami ellent mond azon elvemnek, hogy a compiler warning-ok legyenek bekapcsolva és úgy programozz, hogy egy warning se legyen.
Magának a generikusnak a szintaxisa (mármint ha te csinálsz generikus osztályt) valami rémálom (trivialitásoktól eltekintve) Ezen youtube vidon van pár példa, amit Scala tíz körrel lepipál. És ami lényeg, hogy ennek semmi köze nincs a Scala egyéb funkcionalitásához. Ez csak az, hogyan lehet a generikusokat egyszerűbb szintaxissal megvalósítani.
Ezt megoldást már a generikusok legelső megvalósításával meg kellett volna lépni.
Improved Compiler Warnings and Errors When Using Non-Reifiable Formal Parameters with Varargs Methods
Igazság szerint érteni alig értem, szóval valószínűleg eddig sem zavart.