JDK 7 language changes: DeVoxx poll
By: Jan-Kees van Andel, 8 March 2009
Afgelopen DeVoxx is een stemming geweest waar de bezoekers konden stemmen op hun favoriete nieuwe JDK 7 features.
De grote wijzigingen zijn natuurlijk allang bepaald, zoals !closures (niet dus), JVM optimalisaties voor scripttalen (JSR 292) en Java Module System (JSR 294), maar voor JDK 7 willen ze ook een aantal kleinere wijzigingen faciliteren.
Stephen Colebourne heeft op zijn blog een mooie samenvatting van de poll geplaatst.
Zoals je kunt zien, zitten er 3 populaire tussen:
- Null handling
- Infer generics
- Multi catch
Properties is ook populair, maar deze komt sowieso niet in JDK 7.
Deze 3 populaire features zal ik even kort laten zien:
Null handling
Iedereen heeft weleens dergelijke code gezien:
if (myObject != null) { if (myObject.getProp() != null) { if (myObject.getProp().getProp() != null) { return myObject.getProp().getProp().getString(); } } }
Zou het niet relaxed zijn als je het zo kunt schrijven?
return myObject()?.getProp()?.getProp()?.getString();
Er zitten nog wat vergelijkbare constructies aan vast, zoals een aanpassing aan de ternary operator, zie Alex Millers blog.
Infer generics
Waarschijnlijk hebben jullie deze constructie ook weleens gezien? Zo nee, dan heb je waarschijnlijk nog geen JDK 5+ collections gebruikt. 
List<String> list = new ArrayList<String>();
Dit is nog niet zo vervelend, maar wat dacht je van deze variant?
Map<String, AtomicReference<SoftReference<SomeObject>>> list = new ConcurrentHashMap<String, AtomicReference<SoftReference<SomeObject>>>();
Vrij lelijk als je het aan mij vraagt. En in de meeste gevallen is het niet eens nuttig, aangezien links en rechts van de assignment hetzelfde staat.
Wat dacht je hiervan?
Map<AtomicReference<SoftReference<SomeObject>>> list = new ConcurrentHashMap<>();
De haken aan de rechterkant geven aan dat de compiler de typespecificatie links van de assignment naar de rechterkant gekopieerd moet worden.
Zie wederom Alex Millers blog voor de details.
Ten slotte de Multi catch
Jullie hebben ook vast weleens dergelijke catch clausules gehad neem ik aan.
try { // Do something } catch (Exception1 e) { LOG.error("Something horrible happened", e); } catch (Exception2 e) { LOG.error("Something horrible happened", e); } catch (Exception3 e) { LOG.error("Something horrible happened", e); } catch (Exception4 e) { LOG.error("Something horrible happened", e); }
“catch (Exception)” is niet netjes, hebben we allemaal geleerd. Voor je het weet, vang je onterecht een fout af. Maar al die code duplicatie zit je toch niet lekker. Vandaar een nieuw alternatief:
try { // Do something } catch (Exception1 | Exception2 | Exception3 | Exception4 e) { LOG.error("Something horrible happened", e); }
Dat is een stuk beter he? Vooral in combinatie met Safe Rethrow kan dit erg krachtig zijn.
Ik ben nog wel benieuwd naar de details, want wat is het type van “e”? Gaan ze op zoek naar een common supertype, of wordt het duck typing?
En weer een linkje naar Alex Miller.
Dusss…
Dit zijn maar een paar van de toevoegingen waar momenteel aan gewerkt wordt. Meer info over “Project Coin” op Joe Darcy’s blog.
En natuurlijk weer Alex Miller.
9 March 2009 om 10:10 am
Begrijpelijk dat deze 3 bovenaan geëindigd zijn. Het zijn alle drie goede voorstellen in mijn ogen. Ik heb alleen mijn twijfels bij de leesbaarheid van de Null handling constructie.
De overige oplossingen zijn gewoon nuttig en voorkomt een hoop boilerplate code.
11 March 2009 om 7:28 am
Hoi JK,
jij stelt dat alle changes al zijn bepaald. Dit is nog niet het geval… de ideeen die nu op tafel liggen zijn de plannen zoals Sun het liefst ziet dat Java SE 7 eruit zal gaan zien.
Jij hebt het steeds over JDK 7, volgens mij bedoel je de Java Language Specification en de Java Virtual machine versie 7. Dit zijn de twee gebieden waar alex buckley de spec lead van is. Er is namelijk ook een idee geopperd dat de language specification en de VM misschien niet gekoppeld moeten zijn aan een gelijktijdig release schedule. Echter zal dit pas met een modulaire Java VM realitisch zijn.
De Java language changes krijgen zeer veel aandacht. Ik denk dat de modulaire Java en JSR294 een veel grotere invloed gaan hebben op de toekomst van het Java platform. Project Jigsaw (modulaire JDK) staat iig niet gepland voor Java SE 7, echter zou Sun dit wel graag erin hebben. JSR 294, Java Module System, staat wel op de planning. Dit is een voorwaarde voor de modulaire Java aanpak.
Daarnaast is JSR 308: Annotations on Java Types ook een belangrijke, omdat het static code analysis tools (bijv findbugs) veel krachtiger kan maken.
Alle zaken die jij hierboven noemt zijn dus nog voorwerk, als de expert group zijn werk gaat doen hoeft niet alles nog geformaliseerd te worden via de JCP. Definitief is het allerminst! Volgens mij zal de expert group op de volgende pagina bekend worden: http://jcp.org/en/jsr/detail?id=901
Timeframe voor Java SE 7 is tussen jan 2010 en JavaOne 2010. Ze hebben dus nog even
12 March 2009 om 11:24 am
Thanks voor de aanvulling. Ik zeg alleen niet dat alles al bepaald is, maar de grote lijnen zijn al wel duidelijk, zoals dat closures er niet in komen.
Over JDK 7, ik heb alleen de terminologie gevolgd zoals ze die op DeVoxx hanteerden.
Die annotations zijn idd leuk, want tooling kan met relatief weinig annotations in je code vrij veel aannames doen. De presentatie van de spec lead op DeVoxx komt ergens dit jaar op Parleys.
Maar, Sun is heel erg duidelijk over hun plannen met Java en ik hoor van de andere spelers ook vooral positieve geluiden.
De discussies van de JSR 294 EG kun je hier volgen: http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg. Ik volg het nu al een tijdje. Ze zijn het absoluut nog niet eens over de details, dat is duidelijk.