Na 1 dag communityOne en 4 dagen JavaOne, heb ik wat gemengde gevoelens. Er waren dit jaar geen schokkende nieuwe dingen te melden. JavaFX werd even als vorig jaar in de schijnwerpers gezet. Java 7 duurt nog wel even en heeft wel wat toevoegingen aan de taal zoals Switch op String, Multi Catch en Modules. Zie ook de blog van Peter. Maar over echte aanpassingen zoals het toevoegen van closures is niet gerept. Daarvoor moet je in de JVM scripting talen zijn zoals Groovy of JRuby.

Alle vernieuwingen lijken op basis van Annotaties te gebeuren zoals voor de modules en generics in Java of in de JEE REST API.
Aan de andere kant kun je dit ook zien als een goed punt omdat SUN voorzichtig is met uitbreidingen aan Java en de platformen eromheen gestabiliseerd zijn. De echte innovaties vinden nu plaats in de scripting talen en frameworks zoals Grails en JavaFX.
Evengoed waren er erg veel leerzame sessies, waar ik hier een terugblik op geef.

Community One

De eerste officieuze dag van JavaOne, bedoeld voor Open Source initiatieven. Sun kondigt hier Open Solaris aan. Ook werd verzekerd dat MySQL een vrij product blijft. Verder was er uiteraard veel aandacht voor Sun’s eigen IDE; Netbeans. Versie 6.1 wordt binnenkort gereleased waarbij weer veel support voor nieuwe talen is toegevoegd, waarbij PHP het meest opvalt. Verder is de Javascript support sterk uitgebreid. Een andere aardige toevoeging in de IDE is de mogelijkheid om op basis van de EJB’s JSF schermen te genereren. Het genereren van Entity EJB’s vanuit een database schema was al mogelijk.

Een ander aardig onderwerp was de binnenkort te verwachten release van Subversion 1.5, begin juni. Een mooie uitbreiding is “Merge Tracking”. Stel dat er na het refactoren een bugfix wordt gemerged van de oude code. Dan hoeft er niet opnieuw te worden gemerged.
Ook is een “Sparse Checkout” mogelijk. Dit voorkomt dat alle code uit SVN moet worden uitgechecked om een atomic commit over alle projecten uit te voeren.

Performance tuning en debugging

Er waren een aantal aardige sessies over performance tuning. De sessie “My database is slow” van Josh Berkus (Posgresql specialist bij Sun. Sun levert support voor Postgresql op Solaris).
Hij ging in op de typische klacht dat de database traag is, terwijl het probleem in de praktijk zelden alleen aan de database ligt. Er werd een structurele methode gedemonstreerd waarbij de hele stack van applicatie, middleware, database, besturingssysteem en hardware in beschouwing wordt genomen. Zijn idee is om te beginnen op hardwareniveau en daar een baseline-meting te doen. Daarbij moeten alle configuraties naar de defaults worden teruggezet. Als de defaults afwijken van de huidige settings, dan kan dat direct een mogelijke indicatie zijn voor een performance-probleem. Zo werk je langzaam naar boven in de stack. Verder gaf hij veel tips over relevante tools per stack. Zijn hele presentatie is hier te vinden.

Verder was de “Advanced Enterprise Debugging Techniques” sessie van Neal Ford erg inspirerend. De belangrijkste tip voor het debuggen is: stop en denk na! Begin niet direct met breakpoints. Ga even weg van je computer. Een goede suggestie vond ik om Selenium te gebruiken als ontwikkelaar om je eigen code te testen. Bij het testen van je code, moet je heel vaak hetzelfde pad doorlopen. Door Selenium IDE te gebruiken kun je dit eenmaal opnemen en vervolgens constant herhalen.

Een aardige sessie over hele lastige bugs was de “Defective Java Code: Turning WTF Code into a Learning Experience” door William Pugh. Een van de voorbeelden die werd gegeven was het gebruik van synchronized op een constante. Code die hij had gevonden in een aantal open source projecten was de volgende:

private final String _lock = “LOCK”;
synchronized(_lock) {
}

Zodra er nog ergens in je code of gebruikte libararies in je classpath iemand dezelfde constante gebruikt om te locken, wordt er door verschillende code op hetzelfde object gelocked aangezien er van duplicaat sring objecten slechts 1 object instantie wordt gemaakt!
Nog een voorbeeld van een veel voorkomende bug is het feit dat DateFormat niet threadsafe is. Heel vaak zie je in code dat een DateFormatter als constante wordt gedeclareerd, wat dus niet is toegestaan.

Ook een mooie aankondiging van Sun was de VisualVM tool (http://visualvm.dev.java.net/).
Deze tool combineert Jconsole, HeapWalkers etc. in 1 tool. Het aardige is dat deze tool nauwelijks intrusive is. Je hebt Java 6 nodig om de tool te kunnen starten, maar er kan worden geconnect met een Java 1.4 applicatie. Het is bijvoorbeeld mogelijk om een snapshot te maken van een productie-omgeving en deze vervolgens off-line te analyseren.

Applicaties

Erg nuttige sessies over grote Java applicaties waren die van LinkedIn en Yahoo.

Yahoo
Yahoo heeft 500M+ geregistreerde gebruikers, verwerkt 20TB+ aan data per dag en heeft zo’n 100.000 servers in gebruik. De servers zijn gebaseerd op LAMP met voor Java-applicaties Tomcat en Jboss.
Voor Yahoo geldt dat de basis is geschreven in C en C++ maar door allerlei overnames veel Java gebaseerde applicaties zijn toegevoegd. Deze applicaties moesten veel van de standaard C libraries gebruiken waarvoor JNI wordt gebruikt. Dat leverde 2 grote problemen op. De performance van JNI is niet altijd even goed. Met name karakterconversies kosten veel tijd. Verder was er een probleem dat alle C libraries niet threadsafe waren. Daarvoor moest een custom serialization oplossing worden gebouwd.
Verder is bij Yahoo veel zorg besteed aan privacy van gegevens. Een van de maatregelen om file path exploits te voorkomen is het gebruik van de Apache JSVC Commons Daemon (http://commons.apache.org/daemon/jsvc.html). Het idee is dat Tomcat wordt opgestart als root om initieel secret gegevens die als root zijn opgeslagen in te lezen. Daarna wordt er geswitched naar een andere user zodat de applicatie niet langer de rechten heeft om root gegevens te lezen. Voor Tomcat is er een standaard implementatie voor deze daemon interface.
Verder maakt Yahoo gebruik van servlet filters die alle request parameters opschoont zodat er bijvoorbeeld geen html paramters kunnen worden doorgegeven.

LinkedIn
Linked in is gebaseerd op Spring, Hibernate en Spring Remoting. Een van de lastige problemen voor LinkedIn is dat het uitrekenen van een netwerk bijna onmogelijk is op basis van SQL aangezien het om een graaf gaat. Daarom wordt bij het opstarten van de applicatieserver het hele netwerk voor alle gebruikers uitgerekend. Dit netwerk wordt in memory gehouden op 50 identieke applicatieservers. Probleem dat daarbij optreed is dat de garbage collector erg veel moeite heeft met zo’n groot object. Als oplossing wordt het netwerk object opgeslagen in native C code die via JNI wordt benaderd. Zo blijft het memory management buiten de JVM en kan zo veel efficienter worden afgehandeld.

Scripting talen

Na mijn eerdere sessies over Grails was ik behoorlijk nieuwsgierig geraakt naar de vergelijking tussen JRuby en Groovy. In de sessie “Comparing Jruby and Groovy” door Neal Ford werd een erg heldere vergelijking tussen beide scripting talen gegeven. Belangrijk om te realisen is dat Groovy is ontworpen om het Java platform dynamisch te maken waarbij de mogelijkheden van de taal enigzins worden beperkt. JRuby daarentegen is een Java port van Ruby en maakt Ruby dus beschikbaar op het java platform.
Zowel Ruby als Groovy zijn dynamische strong typed talen en proberen veel van de ceremony weg te halen uit de talen. Zie ook de blog van Okke hierover.
Veel plumbing code wordt overbodig gemaakt. Typische voorbeelden om dit te illustreren zijn de Javabean getter en setter methoden. In Ruby en Groovy gaat dit met veel minder ceremony:
Ruby:
class Person
attr_reader :name
attr_accessor :age, :salery
Groovy:
class Person {
def name, age, salary
}

Ook het werken met null values is een goed voorbeeld. In Groovy kun je protected references gebruiken wat veel null checks kan voorkomen. Door een ? Achter een reference te gebruiken, wordt deze conditioneel aangeroepen. Bijvoorbeeld: Person?.adress?.street
En in Ruby is nil een instantie van NilClass. Dus nil is ook een object.
Andere voorbeelden waarbij het dynamisch karakter van Ruby en Groovy meerwaarde bieden boven Java vind je op het gebied van switch statements, closures, meta programmeren en operator overloading. Wat dat betreft bieden beide talen een mooie aanvulling op Java. Maar welke van de 2 is nu de beste keuze?

Nadelen van Groovy t.o.v. Ruby:

• Er vinden nog steeds veel changes plaats in de core terwijl Ruby ouder is dan Java en stabiel is.
• Draait alleen op Java terwijl Ruby overal draait.
• Wil alle frameworks omarmen waardoor je bijvoorbeeld enorme stacktraces krijgt.

Voordelen van Groovy t.o.v. Ruby:

• Groovy is eenvoudig te begrijpen voor ontwikkelaars met een Java achtergrond terwijl Ruby een nieuwe taal is.
• Groovy is gebouwd bovenop Java terwijl Ruby een andere denkwijze hanteert (bijvoorbeeld geen gebruik van interfaces)

Neal Ford laat duidelijk doorschijnen dat Ruby de superieure taal is en als je van scratch zou moeten beginnen, zou dat de eerste keuze zijn.
Maar voor een ervaren Java ontwikkelaar biedt Groovy vele extra’s bovenop Java terwijl de leercurve laag is zodat de drempel hiervoor veel lager wordt.
En bij die conclusie kan ik me helemaal aansluiten. Ik ben dan ook nog steeds erg enthousiast over Groovy (in combinatie met Grails) omdat ik veel extra’s krijg terwijl ik kan blijven putten uit mijn kennis over Java.