Apple stopt met ontwikkeling OS X-versie Java

C++ kan ook naar zowel OSX/WIndows als Linux compileren en zelfs nog naar heel veel meer. Punt is alleen dat je voor elk platform een andere binary nodig hebt - je krijgt dus niet één .exe die het doet onder Windows, OSX en Linux.

Bij Java en .NET is dat dus wel het geval, omdat er geen machinecode wordt gegenereerd voor een specifiek platform, maar voor het virtuele platform van de JVM. Je hebt op een systeem dus alleen een programma nodig dat JVM-byte code kan uitvoeren, om de generieke Java binary te kunnen draaien. Zeker bij libraries en dergelijke is dat ontzettend fijn, omdat je dan zeker weet dat als de JVM-implementatie juist is, je code zich op verschillende platforms, van Desktop PC's tot Servers en van mobiele telefoons tot lego robots, zich hetzelfde gedraagt.

Het grappige is dat door deze aanpak optimalisaties in de JVM, oude binaries sneller kunnen maken. Als je een .exe hebt, staat de machinecode in principe vast - als er een nieuwe processor op de markt komt met snellere handige instructiesets, zal de exe die nooit gaan gebruiken. In het geval van Java is het echter prima mogelijk dat een update van de JVM ervoor zorgt dat een programma dat vroeger is gecompiled die nieuwe instructies gaat gebruiken, en de applicatie dus veel sneller werkt op een moderne JVM implementatie. Het grote voordeel is dus dat innovaties in processoren en de Virtual Machine ook profijtelijk zijn voor oude applicaties. .NET heeft dit voordeel trouwens ook (en dat geldt ook voor JavaScript).

Nog een grappig feitje: op een gegeven moment introduceerde men een garbage collector in de JVM introduceerde die parallel aan het eigenlijke programma kon draaien en die geheugen vrijmaakte op basis van reference counting (wat niet feilloos is, dus in bepaalde gevallen wordt nog steeds wel teruggevallen op de oude aanpak). Met de komst van dual core processor was het gevolg dat single threaded applicaties ineens soms toch meer dan één core tegelijk aan het benutten waren, omdat de garbage collector dus geheugen aan het opruimen was in een aparte thread. Dit geldt zelfs voor code uit een tijd dat dual core processors nog niet of nauwelijks bestonden.

Ten eerste is een enkel praktijkvoorbeeld van twee vergelijkbare pakketten natuurlijk op geen enkele manier een representatief argument voor je stelling dat Java troep is - je kunt in C++ net zo goed slechte code schrijven als in Java en assembler. Verder vind ik het verhaal ook wat vreemd - als je de Java VM afsluit wordt gewoon al het geheugen vrijgegeven en zou bij het opnieuw opstarten van je applicatie alles weer netjes moeten zijn. Als er een reboot van het OS nodig is om memory vrij te geven, zit er blijkbaar ook iets mank in het memory management van het OS.

Om op je probleem met de garbage collection terug te komen: de Garbage Collector is natuurlijk geensinds een vrijbrief aan de programmeur om niet meer over geheugenmanagement na te denken. Sterker nog, memory leaks zijn inderdaad nog steeds prima mogelijk. Een object wordt pas vrijgegeven als het niet meer bereikbaar is vanuit de scope van een nog draaiende Thread. Als je domweg al je sessies in 1 of andere lijst zet die globaal bereikbaar is "voor het geval je ze ooit nodig hebt" en die lijst vervolgens nooit opruimt, loopt je geheugen gewoon vol. Een programmeur die daar niet over nadenkt met het argument "daar zorgt de garbage collector wel voor", is gewoon een slechte programmeur. Het grote voordeel is echter dat áls een object bereikbaar is vanuit je huidige scope, het niet kan dat dat ding inmiddels al is opgeruimd omdat je ergens te gretig was in je memory management, of dat je per ongeluk bent vergeten ergens een object dat in een simpele locale scope wordt aangemaakt en niet verder gebruikt, te verwijderen. Het probleem dat je aankaart klinkt dan ook gewoon meer als iemand die dacht dat garbage collection een vrijbrief is om maar wat aan te kloten, dan als een feitelijk argument tegen garbage collection.

Over het argument van de slechte performance kun je natuurlijk blijven touwtrekken, maar "veel sneller" is C++ alleen maar in specifieke gevallen (en er zijn ook wel specifieke gevallen waarin Java "veel sneller" is dan C++). Daarbij zijn er op dat vlak enorme vooruitgangen geboekt door de jaren heen.

Met betrekking tot je opmerking over Datastructuren ben ik het trouwens ook echt niet eens - de standaard collectie datastructuren in Java is erg uitgebreid en goed gedocumenteerd. Eén van de grote voordelen vind ik juist dat je standaard balanced Trees, ArrayLists, LinkedLists, HashSets, HashMaps, PriorityQueues, etc. hebt, samen met standaard implementaties van Quicksort en Mergesort en allerlei andere handige algoritmen op verzamelingen. Binnen de STL van C++ heb je echt niet zoveel keus - er zitten niet eens Balanced Trees in (in veel praktische gevallen toch wel een belangrijke datastructuur als je met grote hoeveelheden data werkt en een O(log n) garantie wilt op een hoop operaties). Daarnaast is het ontzettend makkelijk om je eigen klassen te laten werken met deze datastructuren - om je objecten in een Java Tree te kunnen stoppen hoef je alleen maar de Comparable interface op je class te implementeren.

[Reactie gewijzigd door sirdupre op maandag 25 oktober 2010 13:33]