ArrayIndexOutOfBoundsException

Regular visitors of Javapolis/Devoxx will know Click and Hack, the alter ego's of Joshua Bloch and Neal Gafter, both former Sun employees who joined Google. Neal and Josh are also known for their book Java Puzzlers, of which they've been doing presentations on several conferences around the world, including last year's Javapolis conference.

For those of you who attended this session: remember it very well (you may even keep a shortcut to this blog post as a "memorial" and/or to Parleys: http://www.parleys.com/display/PARLEYS/Home#title=The%20J...), because there will be no more Click and Hack. Why not? Because Neal Gafter left Google. OK, no problem, you may think. It's not because Neal Gafter no longer is a colleague of Josh Bloch that they cannot do presentations together anymore. Wrong! Why? Because Gafter went to Microsoft to join the .Net languages team. Knowing that Microsoft is not the most Java-minded company (.Net languages don't include Java), I guess it is clear that Click & Hack have become "deprecated". According to his blogger profile, he joined the M-company in September.

I remember last year's Javapolis presentation of Josh Bloch about closures. He had an entirely different opinion about closures that Neal Gafter had. Neal already did a short presentation on closures the previous year (Javapolis 2006) Neal's presentation can be found on Parleys: http://www.parleys.com/display/PARLEYS/Home#slide=1;title.... Back then that all seamed reasonable. But after the presentation of Josh Bloch last year (see Parleys: http://www.parleys.com/display/PARLEYS/Home#slide=1;title...), which put an entirly different light on closures, I was... puzzled, to say the least. Immediately after Bloch's presentation Gafter write a reaction on his blog (http://gafter.blogspot.com/2007_12_01_archive.html). This reaction clearly showed there was a tension between Bloch and Gafter regarding closures. Does this have something to do with the reason why Gafter eventually left Google?

Vandaag werd het nieuws wereldkondig gemaakt dat Google een eigen web browser gaat lanceren: Google Chrome. Naar het schijnt was het nieuws iets te vroeg gelekt, toen iemand per vergissing het stripverhaaltje, dat de lancering van Chrome moet vergezellen, had doorgestuurd. Dat stripverhaaltje vind je op volgende URL:
http://www.google.com/googlebooks/chrome/

Toen ik het nieuws pas hoorde, dacht ik: Och nee, toch niet weer een nieuwe browser? We zitten al opgescheept met Internet Exploder, Firefox/IceWeasel (de volledig OPEN variant, gebaseerd op de Firefox source code, gebruikt in Debian Linux) wint aan terrein, Opera hinkt achterop, Safari vind je enkel op Mac en die is eigenlijk gebaseerd op Konqueror, die je enkel op Linux (onder KDE) vindt. Waarom weeeer een nieuwe browser? Maar dan ben ik eerst even het stripverhaaltje gaan bekijken. En eigenlijk hebben ze wel een punt. De browsers zoals wij ze kennen hebben allemaal een verleden. Ze stammen allemaal uit de tijd dat browsers enkel tekst en wat prentjes moesten visualiseren. En nu? Java applets, AJAX, Flash, alle mogelijke streaming audio en video... We chatten, zetten onze fotoalbums online, bekijken filmpjes, spelen spelletjes, sturen mails... Google biedt ons zelfs een volledige tekstverwerker en spreadsheet aan via de browser! Met andere woorden: we doen heel wat meer met onze browser dan wat die pakweg 12 jaar geleden moest doen. Natuurlijk, de browser van nu moet ook die dingen van 12 jaar geleden nog kunnen tonen. Maar da's geen probleem.

Google begon dus van nul. Zo vermijd je dat je een hoop legacy meesleept; code van 12 jaar geleden, zeg maar. Gevolg: je kan een veel zuiverdere architectuur uittekenen. En dat hebben ze ook gedaan. In plaats van multi-threaded te werken, werken ze multi-processing: Elke tab in de browser is een browser sessie op zich (apart proces). Als er een probleem is met het renderen van een bepaalde tab, gaat niet heel je browser down, maar enkel die ene tab. De rest kan blijven werken. Op die manier wordt het geheugen ook beter benut (minder fragmentatie), waardoor je browser niet stelselmatig gaat vertragen als er te veel tabs openstaan. Met aparte processen per tab kan dat dus niet... Sterker zelfs: als je in 1 tab van site A naar site B gaat en beide sites staan volledig los van mekaar, dan wordt het proces van site A gestopt op een nieuw te creêren voor site B.

Door van nul te beginnen, is de browser ook sneller: het start sneller op, laadt pagina's sneller en blijft sneller bollen (of, zoals hiervoor vermeld: gaat na een tijd niet vertragen). Ook werd veel effort gestoken in een degelijke Javascript virtual machine én degelijke garbage collection in deze VM. ook dat maakt de browser veel performanter.

Visueel dan. De browser is heel sober. De tab bar is het vertrekpunt. De tabs staan dus bovenaan, niet de address bar. Door het gebruik van aparte processen per tab kunnen tabs ook effectief uit het browser window worden gesleept en als een apart window verder leven. Geïntegreerd zoeken is ook een belangrijk punt geworden met de Omnibox, een intelligente address bar, zeg maar.

Veiligheid wordt gegarandeerd door een strikt sandbox principe. Elk browser (tab) proces speelt in zijn eigen zandbak. Er mag geen data worden weggeschreven. Sensitive data kan niet worden gelezen. Op die manier kan er geen malware worden geïnstalleerd. Moest er toch al malware over de lijn gaan, dan wordt die weggesmeten van zodra het browser proces worden gestopt.

En het beste van al? Het is open source! Google heeft zelf de mosterd gehaald bij verschillende open source projecten zoals Firefox en Apple's WebKit. Ik ben benieuwd hoe snel de ideeën en principes van Chrome zullen worden overgenomen door andere browsers...