Ezek voltak a tegnapi Java7 vitafórum témái. Lehet folytatni!
Generikus típusok futásidőben
if (list instanceof List<String>) { ... }
Ez most nem fordul, pedig jó lenne ha ki lehetne deríteni futásidőben a generikus szerkezetek paramétereinek típusait.
Elvileg valami trükkel mégiscsak ki lehet szedni! Aki véletlenül tudja ezt a trükköt, ne tartsa magában!
Enum-ok ordinary értékei
Ha enum-okat definiálok, akkor az int reprezentációjuk mindig 0-tól egyesével növekszik, pedig jó lenne, ha kézzel meg lehetne adni értékeket. Pl. Utólag szeretnék beszúrni egy elemet középre. Ha simán beszúrom elcsúsznak az értékek mögötte. A program verziók nem lesznek kompatibilisek! Vagy egy meglévő rendszer konstansait szeretném beállítani az enum értékeinek.
Ez nem igazán zavart senkit, könnyen kiküszöbölhető. Pl. hibernate-ben nem a számértékeket, hanem a név-értékeket érdemes eltárolni.
Autoboxing NPE
Integer i = null; int x = i
NullPointerException-t okoz. Tapasztalataim szerint nem könnyű észrevenni a fentinél kevésbé triviális helyzetekben.
Lehetne az NPE üzenetrészében legalább valami "autoboxing" vagy hasonló.
Ez sem zavart senkit.
Triviális kasztolások
byte[] b = new byte[] {0xFF, 0xFF }; byte[] b = new byte[] {(byte)0xFF, (byte)0xFF };
(Megj.: amikor alacsonyszintű Java-t programoztam (Embedded java) majdnem szétkapartam az arcomat kínomban emiatt.)
Más is találkozott már vele, ez van.
switch-be nem lehet String-et írni
switch (str) { case "ONE": return 1; case "TWO": return 2; case "THREE": return 3; }
Ezen elfilóztunk kicsit. A switch JVM utasítás belső szerkezete csak az int összehasonlításnak kedvez és tulajdonképpen egy függvénytáblát használ. Azért syntax sugar-nek meg lehetne csinálni. De akkor is, mikor használjunk equals-t és mikor ==-t?
Typedef
Ha sok helyen használunk egy adott generikus típust lehessen egy typedef-szerű dolgot megadni:
import java.util.Map<String, Integer> as CodeValueMap;
(Megj: Ha sok helyen használunk egy adott generikus típust, akkor akár külön osztályt is csinálhatunk rá.)
No way.
Rövidítés
Mi lenne, ha nem kellene kiírni a List-ben a get-et:
List<String> list; ... String s = list.get(3000); helyett String s = list[3000]
vagy
Map<String, Integer> map; ... Integer i = map["egy"];
(Mi lenne ha lenne operator overloading...)
Nem tartottuk fontosnak. Aki C#-ban akar programozni az programozzon C#-ban-ban.
Property-k
Van aki nem szeret gettereket írogatni.
public class Person { private String _forename; public property int age; }
(Megj.: Jobb IDE megírja öt kattintásra a gettereket. A fentinél bonyolultabb esetekben a property-knek is kell getter.)
Azért van aki mellette volt. Jobban belegondolva tényleg csak fölösleges "kódzaj" a sok getter és setter, azokban az esetekben, amikor úgyis csak beállítja-visszaadja a privát mező értékét.
BigDecimal, BigInteger
Kényelmetlen a használata: metódushívások helyett kényelmesebb lenne operátorokat használni.
BigInteger sum = a.add(b.add(c.add(d))); helyett BigInteger sum = a + b + c + d;
Elvileg már tervezik.
XML support
Lehetne valami nyelvi szintű XML szolgáltatás, mint a Stringeknél.
Node n = <Person><Name>Joe</Name><Country>Netherlands</Country></Person>;
(Láttam valahol egy videót, ahol 45 percen keresztül taglalja a témát egy ipse.)
Gáznak tartottuk. Ha megtalálom a videót belinkelem majd / aki ismeri linkelje be.
Closures
Belső függvények, lokális függvények. Néha jól jönnének.
(http://tronicek.blogspot.com/2007/12/closures-closure-is-form-of-anonymous_28.html)
public class SimpleClosure { public static void main(String[] args) { // function with no arguments; int answer = { => 42 }.invoke(); System.out.println(answer); } }
(Megj.: ez nem valami jó példa.)
Szintén, aki Scala-ban akar programozni, programozzon Scala-ban.
KIVÉTELEK:
Multi-catch
Ha két kivétel catch ágában ugyanazt a kódot akarjuk használni, lehessen így egyszerűsíteni:
try { } catch (IOException | SQLException ex) { }
(Megj.: ha kiemeljük metódusba a használandó kódot az is segít.)
És akkor mi az "ex" változó típusa...?
Checked exception: Szükséges?
Kemény téma volt mindig is.
Néha úgysem tudunk értelmes catch kódot írni.
Sok helyen látok üres (vagy ami még roszabb alibi) catch blokkot.
Mi lenne, ha a checked exception kezelésének kihagyása csak warningot eredményezne?
Jó az a checked exception.
Stacktrace
row.getPerson().getAddress().getCity(); java.lang.NullPointerException: at myprogram.Main(Main.java:365)
Jó lenne tudni a soron belül hol történt a kivétel.
Ami null, annak kiírni a típusát, vagy a metódus nevét (Delphi csinálja így?).
Megadni valahogy, hogy mi kerüljön a stackTrace-be. Valakit zavarnak a hosszú stacktrace-ek is.
Egyébként le lehet cserélni az el-nem-kapott-exception kezelőt sajátra, ami azt csinál amit akarunk
a tömbben megkapott StackTraceElement-ekkel.
Egyebek
Több értékű visszatérési értékek. Egy metódus tudjon visszaadni több értéket. (Akkor már kimenő paraméterrel is megoldható.)
return type overloading. (Biztos sok további kérdést felvet.)
JVM lassú, modularizáció elkelne. El.
GC-hez közelebbi hozzáférés. Pl. cache-ek írásánál. Néha a WeakReference sem elég.
Appletek használhatatlanok. Majd a javaFX!
Dátumkezelés lassú. Már tervezik a javítást!
String ne legyen final. No way.
Minimalista API-k. (Már nem annyira jellemző.)
13 Comments
Karnok Dávid
Generikus típusok: A módszert Szuper Type Tokennek hívják. A lényege, hogy egy konkrét absztakt osztályról le lehet kérdezni a futás idejű generikus típusát: http://gafter.blogspot.com/2006/12/super-type-tokens.html
Autoboxing NPE: használjuk a FindBugs-ot!
XML Support: http://www.parleys.com/display/PARLEYS/Integrating+XML+into+the+Java+Language
Multi Catch: A kivétel típusa a legközelebbi közös ős, vagy simán egy Throwable
tvik
http://tech.puredanger.com/java7
Auth Gábor
Bakos Gábor
Vagy épp Fortressben. Azt hiszem az XML kezelés kivételével hasonlóak a megoldásaik. (És a felsoroltak kb felére már van megoldásuk.)
tvik
A Scala csak egy példa volt, mást is mondhattunk volna. (A Scala JVM alapú.)
Bakos Gábor
Unknown User (crystal)
Auth Gábor
Én inkább szeretném elfeledtetni a primitív típusokat is a nyelvből. De ehhez feljettebb autoboxingra lenne szükség, mert jelenleg tízszeres-hússzoros különbség is lehet futásidőben ha primitív típus helyett az osztályt használom... :)
Laiszner Tamás
tvik
Ugye a lényege, hogy egy változó többféle típusú értéket tud tárolni. C struktúrákban - ahol az adatok reprezentációja helyben kerül tárolásra a struktúrán belül - szükség van rá hogy megmondd milyen típusok lehetnek ott, mert eszerint allokálja a memóriát, méghozzá a legtöbb memóriát igénylő típushoz igazítva az igényt.
Java-ban az atomi típusokon kívül minden referenciaként van tárolva, tehát ilyen allokációra nincs szükség ebből a szempontból.
Egyébként pedig számos eszköz van rá, hogy unió-hoz hasonló funkcionalitást csinálj. Pl. Object-nek deklarálod a változót, vagy generikusokat használsz.
De lehet hogy nem is erre gondoltál unió alatt?
Auth Gábor
Biztos van ezen kívül hasznos felhasználása, de mi? :)
Unknown User (kuvera)
Az int/long szétszedést bitmaszkokkal meg lehet oldani, más típusokat esetleg sorosítással és byte stream olvasással, de a Java igazán nem erre való.
Auth Gábor
Crystal, szerintem ez rossz ötlet. Előre lépésnek tekintem, hogy eltűnt ez a lehetőség.
Egyrészt nagyon megnehezítené a kódolvasást (a kódelemzőket azért könnyű lenne átírni, fejben nehezebb):
Tényleg szeretnél ehhez hasonló kódot látni (nem biztos, hogy van értelme ;-))?
Másrészt matematikailag a két dolognak nincs közvetlen köze egymáshoz. Természetesen lehet leképezést végezni egyikből a másikba, de erre vannak már operátorok, lehet használni az == jelet, illetve a ?: operátort. :)
(Persze lehet, hogy bennem van a hiba. Az implicit konverziók szerintem kissé áttekinthetetlenné teszik a kódot.)