Nochtans is Javascript qua programmeertaal niet meteen het neusje van de zalm… Een paar quotes:

• “JavaScript is a language with more than its share of bad parts.”
• “Few classical programmers found prototypal inheritance to be acceptable, and classically inspired syntax obscures the language’s true prototypal nature. It is the worst of both worlds.”
• “undefined and NaN are not constants. They are global variables, and you can change their values. That should not be possible, and yet it is. Don’t do it.

(Uit: Douglas Crockford, JavaScript: The Good Parts )

Er zijn uiteraard ook goede delen aan Javascript (anders zou dat boek toch wel anders heten), maar al bij al zal Javascript geen schoonheidsprijzen in de wacht slepen. Het is een dynamisch getypeerde taal, met prototypische overerving, en het is erg gemakkelijk in Javascript om je programma heel onleesbaar te maken. Programmeurs die met een meer klassieke taal beginnen werken, zoals Java, en daarna pas Javascript leren, moeten typisch serieus wennen (en ontwennen)!

De twee talen zijn trouwens, ondanks de naam en enkele gelijkenissen (e.g. dat ze beide een C-achtige syntax hebben), niet gerelateerd (men zou kunnen zeggen: Javascript en Java zijn zoals Parket en Park). Javascript kreeg zijn naam indertijd van NetScape in de hoop op de toenmalige populariteit van Java te kunnen piggybacken.

Tegenwoordig zijn er ook al verschillende talen die de syntactische tekortkomingen van Javascript trachten op te vangen: het zijn talen die sterk op Javascript lijken, en er ook in worden vertaald wanneer het tijd wordt om de code uit te voeren. Voorbeelden zijn CoffeeScript en Dart. Voorlopig zijn deze talen echter nog maar weinig in gebruik in vergelijking met het origineel.

Waarom is Javascript dan zo populair? Dat heeft een aantal redenen. De belangrijkste daarvan is de V8 engine, die zijn intrede maakte in Google Chrome. Deze engine (hetgeen wat de code daadwerkelijk uitvoert) heeft de performantie van de taal naar een nieuw niveau geheven, en wordt trouwens ook gebruikt in node.js. Daarnaast is het uiteraard zowat de enige taal die nog gebruikt wordt om code uit te voeren in de browser zelf (aan de “client side”), wat, in een goed gebouwde website, de server en het netwerk serieus kan ontlasten, terwijl er toch een mooie en interactieve site of applicatie wordt gepresenteerd.

Een paar positievere quotes:

• de wet van Jeff Atwood: “any application that can be written in JavaScript, will eventually be written in JavaScript“
•  “After some abandoned experiments with static compilation, we looked around and saw how successfully JIT techniques are being applied in the JavaScript space: Chrome’s V8 engine, in particular, has greatly pushed the status quo of JavaScript performance.” – anoniem

Javascript viert volgend jaar al z’n twintigste verjaardag… De taal werd vrij snel populair in het begin en er werd zelfs een standaard voor geschreven. Toch keken “echte” developers een tijdlang neer op de taal. Een grote doorbraak kwam er dankzij AJAX (Asynchronous JavaScript and XML), een technologie die toelaat om niet bij elke communicatie met de server opnieuw de volledige webpagina te moeten laden. Deze technologie heeft een beetje een evolutie gekend voorheen, maar kreeg voor het eerst haar naam in 2005. Sindsdien is de groei van Javascript als taal van het web niet meer te onderschatten.

AJAX op zijn beurt heeft geleid tot twee recentere ontwikkelingen die de dominantie van de taal nogmaals onderstrepen: moderne Javascript raamwerken (Frameworks) en server-side Javascript onder de vorm van Node.js.

Frameworks

Websites bouwen met interactieve en dynamische graphics was vroeger erg moeilijk, maar daar zijn nu Javascript raamwerken voor. Het begon vooral in 2006 met JQuery: een Javascript pakket dat het een stuk eenvoudiger maakte, en nog altijd doet, om mooie zaken op het scherm te presenteren. JQuery evolueert nog steeds, en is ondertussen geïntegreerd geraakt in tal van andere pakketten en frameworks. Niet in het minst ligt JQuery aan de basis van zowat alle recentere Javascript raamwerken die het ontwikkelingsgemak nog een stapje verder nemen.

Bootstrap.js

Bootstrap werd oorspronkelijk ontwikkeld door Twitter, en in 2011 open source gemaakt. Het bestaat uit een collectie aan tools voor het ondersteunen van het bouwen van websites en -apps, vooral gebaseerd op templates voor allerlei UI-elementen. De huidige versies hebben een goede ondersteuning voor responsive design en hanteren de mobile first strategie.

Backbone.js

Backbone bestaat al sinds 2010 als Javascript raamwerk en volgt iets dat lijkt op het model-view-controller (MVC) principe. Het ondersteunt en vereenvoudigt ook de verbinding via REST van de front-end met de backend van de te ontwikkelen site.

Het is vrij populair geworden en wordt momenteel zelfs in de core van Drupal 8, het populaire CMS, ingebouwd.

AngularJS

Angular is een raamwerk dat zich focust op het via Javascript uitbreiden van het html-model van een website. Zo kan je via eenvoudige, zelf gedefiniëerde extra sleutelwoorden in de html-pagina tonnen functionaliteit toevoegen zonder aan de overzichtelijkheid van het html-model te raken. Er wordt op die manier ook een heel niveau van herbruikbaarheid toegevoegd aan web-ontwikkeling.

Node.js

Voor de allereerste keer is Javascript niet alleen aan de client side, maar ook op de server enorm populair aan het worden. Dit komt doordat het gebruik van node.js verschillende voordelen heeft:

• Efficiëntie en compatibiliteit: er moet niet langer telkens een vertaalslag worden uitgevoerd tussen de gegevens die op de server staan en degene in de browser: alles is in javascript, dus de manier waarop data wordt gerepresenteerd, is voor de client en de server hetzelfde (typisch gebeurt dit met json). Voor de vertaalslag hoeft dus ook geen code meer te worden geschreven. Daarnaast is een node.js server ook vrij performant: één server kan zeer veel requests van clients tegelijk afhandelen.
• Leercurve: Developers hoeven nog maar één programmeertaal te leren alvorens ze een volledige webapplicatie kunnen bouwen. Niet langer moeten ze een server-taal leren, zoals php of java, en daarnaast nog eens Javasript voor de client.

Dit laatste heeft trouwens ook zijn impact op de Javascript frameworks: nu zijn er al frameworks die zich niet alleen op de client, maar op de volledige stack richten, puur in Javascript: Meteor is zo’n framework.

Zal Javascript verder de wereld veroveren en misschien zelfs php naar de kroon steken? Dat is moeilijk te voorspellen, de wereld van web development verandert razend snel. Een Javascript framework dat vandaag populair is kan over een paar jaar al ouderwets lijken in vergelijking met nieuwere frameworks. We kunnen alleen maar besluiten dat we het door deze snelle evoluties allicht steeds makkelijker zullen hebben om goed werkende webapplicaties te ontwikkelen, en dat het gebruik van een modern Javascript framework, of eventueel zelfs van node.js, een te overwegen optie is bij quasi alle web projecten.

Maar goed, ter zake! Wat brengt Java 7 ons voor vernieuwingen?

Ik moet echter beginnen met een disclaimer: na jaren van ontwikkeling is er natuurlijk heel wat meer bijgekomen in de taal dan ik hier kan beschrijven. Mijn oplijsting is dus niet exhaustief. Het blijkt trouwens vrij moeilijk om een perfect juist beeld bij elkaar te googlen van wat er nu precies wél of niet inzit, en daarbij ook nog eens een goede uitleg over deze zaken te krijgen (maar vandaar ook het nut van een blogpost als deze).

De vernieuwingen dan:

Eerst de zaken die we niet meteen met het blote oog kunnen zien: de virtuele machine heeft een hele evolutie doorgemaakt sinds het begin van Java, en in versie 7 is er voor gezorgd dat er goede support is voor dynamische talen, zoals Groovy. Deze talen zullen nu quasi even performant zijn als Java zelf (no pun intended). Verder zijn er een aantal zaken verbeterd betreffende class loaders, die voor minder bugs zorgen wanneer er meerdere van gebruikt worden, en er is nu ook een URLClassLoader.

Ook de ondersteuning voor parallelisme is nog wat beter geworden, met nieuwe klassen in het concurrency framework zoals de ForkJoinPool en de TransferQueue. Dit lijken mij goeie toevoegingen, maar de ondersteuning voor multithreading, met een hoog niveau van abstractie, was reeds erg goed. Ik bespreek dit raamwerk graag nog uitgebreider in een toekomstige blogpost. Multithreading zal zeker nog aan belang winnen in de toekomst, wanneer we meer en meer cores in onze computers krijgen.

Wat IO en netwerken betreft, zijn er voorts nog een aantal interessante toevoegingen, zoals een vernieuwing van de IO api (New IO: “NIO”), scp en sctp ondersteuning, gebruik van windows vista ipv6 en, last but not least: TLS 1.2 (ook wel SSL 3.3 genoemd).

Voor de security mensen: Elliptic Curve Cryptography is nu out-of-the-box beschikbaar.

En dan één van mijn stokpaardjes: de client, en Swing! Er is nu een nieuwe rendering-pipeline voor Java2D, waardoor een aantal features van moderne gpu’s ter beschikking komen te staan. Verder is er ondersteuning voor translucente en onregelmatig gevormde vensters, een nieuwe Look and Feel, en een nieuwe sound synthesizer. En ten slotte, zoals gewoonlijk, zijn een aantal zaken van SwingLabs gemigreerd naar de standaard Swing api.

Tot zover de ‘saaiere’ vernieuwingen; de echte vraag die echter op ieders lippen ligt, is natuurlijk: Wat zijn de nieuwe dingen die we kunnen doen als programmeur? Give us the language features!

Een eerste kleine verbetering, is de mogelijkheid om Strings te gebruiken in een switch statement. Persoonlijk vind ik dit niet supernuttig, dus ik ga er ook geen voorbeeld van geven. Volgens mij zijn enums veel beter geschikt om ‘of-of-of’ constructies op poten te zetten, en is een goed uitgedacht design, gebruik makende van polymorfisme en dynamische binding, meestal zowiezo een beter alternatief. Maar goed, het was een zinloze beperking, en het is goed dat deze nu is weggewerkt.

Next! Naast hexadecimale, octale en (gewone) decimale getallen, komt er nu ook een voorstellingswijze voor binaire getallen: ik moet zeggen: in quasi alle gevallen: blijf er van weg! Wat wel interessant is, is dat men nu underscores in getallen kan plaatsen om de leesbaarheid te verhogen. Zo is b.v. 1_000_000 vanaf nu een correcte en beter leesbare voorstellingswijze voor het getal 1000000. Ook in de andere voorstellingswijzen, en in floating point getallen, kan men ze gebruiken. Een getal moet wel nog altijd met een cijfer starten en eindigen.

Nog een kleine, eenvoudige verbetering is type inferentie bij het aanroepen van de constructor van generische klassen. Stel: je declareert een List<String> en je wil deze lijst initialiseren als een arraylist. Vroeger moest je dan als volgt de constructor aanroepen: new ArrayList<String>(). Met type inferentie wordt dit gewoon: new ArrayList<>(). De compiler is dus eindelijk slim genoeg geworden om te raden welk type je wou maken. Bemerk dat er nog steeds een diamandje “<>” nodig is, anders heb je een raw type. Vandaar dat men deze verbetering “diamond” heeft gedoopt. Eenvoudig en handig.

Een iets minder voor de hand liggende taaluitbreiding, is automatic resource management (ARM). De standaard manier van werken om een InputStream of File terug vrij te geven in geval van onverwachte gebeurtenissen, is dit in een finally clausule te zetten ( finally { file.close(); } ). Dit kan echter problemen opleveren wanneer je meerdere close-statements moet uitvoeren en de eerste close-methode zelf een foutmelding geeft, waardoor de erop volgende close-statements niet meer worden uitgevoerd. De nieuwe manier van werken, is de resources aan te maken in een statement, ingesloten in haakjes, volgende op het ‘try’-keyword. Een beetje zoals de declaratie van de teller in een for-statement. Bijgevolg krijg je dan iets als volgt: try (InputStream i = …; OutputStream o = …) {…} finally {/*niet meer nodig*/}. Achter de schermen zou dit dan werken alsof men recursieve try-finally statements gebruikt om alle mogelijke fouten op te vangen (dus de eerste close zit nog in een extra try blok, gevolgd door een finally block met daarin de tweede close; het geheel van deze try-finally zit op zijn beurt in het finally blok van de uit te voeren code). Je kan je inbeelden dat, als je dit manueel moest doen voor meer dan twee resources, er nogal wat boilerplate code aan te pas kwam; dit is dus een vrij nuttige feature.

De laatste taaluitbreiding die ik wil bespreken, heeft opnieuw met exception-handling te maken, ditmaal met het catch-blok. Bij het loggen van excepties die men niet onmiddellijk kan afhandelen, zal men deze vaak vangen, loggen, en dan opnieuw gooien. Vaak heeft men echter een try-blok dat verschillende soorten uitzonderingen kan gooien, waardoor men hetzelfde stukje code moet herhalen in een hele resem catch-blokken. Een superklasse gebruiken voor het catch-blok is vaak gevaarlijk, omdat er eventueel exceptie-types kunnen omvat worden waarvoor dit in eerste instantie niet de bedoeling was. Wanneer men b.v. het type “Exception” gebruikt, omvat dit alle mogelijke RuntimeExceptions, terwijl men misschien enkel een aantal niet-gerelateerde checked exceptions wou opvangen. De boilerplate code die hierbij komt kijken, kan men nu voor een deel schrappen, doordat men in de catch-expressie nu een lijst van types kan geven, gescheiden door verticale of-strepen ( “|” ). Men zou bijvoorbeeld kunnen zeggen: catch (NullPointerException | IndexOutOfBoundsException e) {log(e); throw e;}, in plaats van voor elk type uitzondering een apart catch-blok te maken. Ik had nog niet echt stilgestaan bij deze problematiek, maar ik denk wel dat het kan helpen om robuuste code te maken, voorzien van alle toeters en bellen om ze “enterprise-ready” te maken.

Meer uitleg betreffende de kleine, handige taaluitbreidingen, kan je vinden op de site van Project Coin. Een aantal goeie voorbeelden kan je bekijken op een presentatie die een tijdje terug op JavaOne is gegeven.

Tussen haakjes: tijdens mijn zoektocht ben ik ook de filosofie van Java nog eens tegengekomen, wat betreft het evolueren van de taal:

• Reading is more important than writing
• Code should be a joy to read
• The language should not hide what is happening
• Code should do what it seems to do
• Simplicity matters
• A clear semantic model greatly boosts readability
• Every “good” feature adds more “bad” weight
• Sometimes it is best to leave things out

Of deze principes tot nu toe trouw gevolgd zijn, laat ik over aan de lezer.

En als afsluiter: wat zit er niet in? Een aantal zaken zijn reeds lang in ontwikkeling, maar voorlopig blijkbaar toch nog iets te moeilijk: Doorgedreven modularisatie is o.a. al zeker tot Java 8 uitgesteld. Ook de veelgeplaagde, vaak gevraagde closures (Project Lambda), zijn voorlopig nog even terug in de kast gestoken, alsook een meer directe taalondersteuning voor het collection framework. Meer geluk eind 2012?