Dev Summit 2026 met Adele Carpenter: 'Java sucks, maar hoeft niet weg'

Java vraagt vaak veel code, kan behoorlijk stroef aanvoelen en null ligt altijd op de loer. Toch draaien banken, verzekeraars en talloze andere organisaties nog altijd op de programmeertaal. Tijdens de Tweakers Developers Summit laat software-engineer Adele Carpenter zien waar de bekende ergernissen vandaan komen. En waarom C#-developers zich daar best een beetje zelfvoldaan over mogen voelen.

Via een omweg naar softwareontwikkeling

Adele Carpenter kwam niet via de gebruikelijke route in de softwareontwikkeling terecht. Toen ze tien jaar geleden naar Nederland verhuisde, bezat ze diploma's in civiele techniek en handelswetenschappen, maar wist ze nog weinig van software. Ze solliciteerde bij Trifork Amsterdam op een functie in sales en marketing rond de GOTO-conferenties en bijbehorende trainingen.
"Tijdens mijn sollicitatie moesten ze me uitleggen wat opensourcesoftware was. En toch namen ze me aan."Dat sollicitatiegesprek verliep anders dan dat van de gemiddelde toekomstige developer. "Tijdens mijn sollicitatie moesten ze me uitleggen wat opensourcesoftware was. En toch namen ze me aan."

Via de conferenties ontmoette Carpenter dagelijks ontwikkelaars die enthousiast vertelden over programmeertalen en de systemen waaraan ze werkten. Die wereld trok haar steeds meer. Ze wilde begrijpen waarover zij spraken en uiteindelijk zelf op zo'n podium staan.
"Ik dacht: dit is de plek waar ik wil zijn. Ik ga leren programmeren en op een dag sta ik zelf op dat podium."

Carpenter overtuigde de directeur van Trifork ervan dat ze tijdens haar werk mocht leren programmeren. Ze verdeelde haar tijd tussen marketing en code en vroeg na ongeveer een jaar om een plek in een klantproject. Sinds 2019 werkt ze als software-engineer; eind 2021 stond ze voor het eerst als spreker op een conferentie.
Tegenwoordig combineert ze ontwikkeling met advieswerk bij klanten en gebruikt ze onder meer Java, Kotlin, Spring, React, JavaScript en TypeScript. Trifork bouwt complexe maatwerksoftware, waaronder digitale toets- en examenomgevingen voor het onderwijs. Daarbij gaat het om systemen die op drukke momenten probleemloos beschikbaar moeten zijn en lang worden onderhouden. Dan telt niet alleen hoe prettig een taal programmeert, maar vooral of de software betrouwbaar en voorspelbaar blijft draaien.

Java afkraken uit liefde

De titel van Carpenters talk laat weinig ruimte voor subtiliteit: Java Sucks (So C# Didn't Have To). Toch is de sessie geen afrekening met de taal waarmee ze haar geld verdient. De provocatie komt juist voort uit haar waardering voor Java én haar ontmoetingen met developers uit de Microsoft-wereld.

Op conferenties met veel C#-developers hoorde Carpenter regelmatig dat Java hopeloos verouderd was. Sommigen hadden de taal voor het laatst tijdens hun studie gebruikt, vaak in de jaren negentig. Hun oordeel stond nog altijd vast: Java 1.2 was vervelend, dus Java moest wel een slechte taal zijn.

In de praktijk worden Java en C# allebei gebruikt voor bedrijfskritische systemen. Het zijn volwassen talen met omvangrijke ecosystemen en gemeenschappen vol kennis en ervaring. Voor organisaties is de keuze tussen beide daarom meestal minder dramatisch dan developers doen voorkomen.

Toch plagen de kampen elkaar graag. "Er bestaat nog steeds behoorlijk wat hokjesdenken. Dan denk ik: zien jullie niet dat we in wezen allemaal hetzelfde doen?"

Carpenter gebruikt die rivaliteit om te laten zien hoe programmeertalen van elkaar leren. De makers van C# konden voortbouwen op keuzes die bij Java goed of juist minder goed uitpakten. Java nam later weer ideeën over uit nieuwere talen. Zo veranderen talen stap voor stap, terwijl ze eerdere beslissingen soms tientallen jaren meedragen.

Waarom Java niet vervangen hoeft te worden

Java bestaat inmiddels ruim dertig jaar en bevat keuzes die met de kennis van nu waarschijnlijk anders zouden worden gemaakt. Carpenter ziet dat niet als reden om de taal af te schrijven. "Ik denk niet dat Java vervangen hoeft te worden. Je moet de taal nemen zoals hij is, met alle wratten erbij."
Sommige eigenschappen die Java ouderwets laten aanvoelen, maken de taal juist"Ik denk niet dat Java vervangen hoeft te worden. Je moet de taal nemen zoals hij is, met alle wratten erbij." aantrekkelijk voor grote organisaties. Java is stabiel, beschikt over veel frameworks, bibliotheken en hulpmiddelen en draait via de Java Virtual Machine op verschillende besturingssystemen.

Daar komt de sterke achterwaartse compatibiliteit bij. Nieuwe versies moeten bestaande software zo min mogelijk beschadigen. Daardoor blijft soms oude ballast behouden, maar hebben organisaties doorgaans een duidelijk upgradepad en hoeven ze hun systemen niet bij iedere update te herbouwen. Carpenters team werkt inmiddels met Java 25 en ondervindt bij upgrades weinig problemen: veel bestaande code blijft gewoon werken. Voor toepassingen die twintig jaar of langer meegaan, weegt die zekerheid vaak zwaarder dan een compactere of elegantere schrijfwijze.

Generics, lambdas en verdwenen type-informatie

De tekortkomingen van Java krijgen in Carpenters talk volop aandacht. Checked exceptions zijn bijvoorbeeld lastig te combineren met lambdas: "Je kunt ze combineren, maar daarvoor heb je extra code nodig, bijvoorbeeld om een functionele interface te implementeren." Ook de manier waarop Java generics heeft ingevoerd, werkt nog dagelijks door in moderne code.

C# bood al vroeg de mogelijkheid om functies via delegates door te geven. Daardoor voelt functioneel programmeren in C# vaak natuurlijker. Java kreeg later eveneens lambdas en andere functionele mogelijkheden, maar die sluiten niet overal soepel aan op oudere onderdelen van de taal.

Kotlin voelt op dat vlak volgens Carpenter natuurlijker. Doordat Kotlin en Java binnen dezelfde JVM-omgeving samenwerken, kunnen teams per probleem kiezen voor een meer objectgerichte of juist functionele oplossing zonder hun bestaande Java-ecosysteem achter te laten. Bovendien ondersteunt Java functioneel programmeren met elke nieuwe versie steeds beter.

Een veelbesproken verschil is de manier waarop beide talen met generics omgaan. C# bewaart tijdens het uitvoeren informatie over het concrete type. De software kan daardoor onderzoeken met welk type zij werkt. Java past daarentegen type erasure toe: na het compileren is een groot deel van die informatie niet meer rechtstreeks beschikbaar. Dat beperkt bepaalde vormen van inspectie tijdens runtime en dwingt developers soms tot omwegen.

C#-ontwikkelaars kijken daar graag hoofdschuddend naar. Carpenter: "Dan vragen ze hoe we in vredesnaam kunnen overleven in die donkere middeleeuwen zonder reified generics. Maar weet je? Java-developers redden zich prima." Als je bijvoorbeeld met een bibliotheek als Jackson data deserialiseert naar Java-objecten, moet je het verwachte type expliciet als parameter meegeven. Dat lukt mede dankzij vaste programmeerpatronen, bibliotheken en de kennis die in dertig jaar rond Java is opgebouwd. Niet iedere oplossing is elegant, maar een taal staat nooit los van het gereedschap en de gemeenschap eromheen.

Ook een programmeertaal is een softwareproject

De makers van Java beschikten in de jaren negentig over andere hardware, eisen en inzichten dan taalontwerpers nu. Een keuze die toen verstandig was, kan tientallen jaren later onhandig uitpakken. Door de nadruk op achterwaartse compatibiliteit zijn zulke beslissingen bovendien moeilijk terug te draaien.
Carpenter vergelijkt kritiek op een vreemde taalconstructie met een klant die vraagt waarom een ogenschijnlijk eenvoudige functie niet morgen kan worden opgeleverd. Een developer weet dat achter zo'n verzoek afhankelijkheden, beveiligingseisen, tests en architectuurkeuzes schuilgaan.

"De mensen die aan Java werken, verschillen daarin niet van jou en mij. Zij werken alleen aan een ander soort systeem. Ze hebben net zo diep over hun problemen nagedacht en kennen technische beperkingen waarvan wij niet allemaal op de hoogte zijn."

Een ongelukkige eigenschap is dus niet automatisch het resultaat van slecht denkwerk. Een wijziging kan gevolgen hebben voor de compiler, de JVM, frameworks en enorme hoeveelheden bestaande code. Soms beschermt een compromis miljoenen toepassingen. Soms blijkt pas jaren later dat een keuze minder goed heeft uitgepakt. Een programmeertaal is uiteindelijk zelf een langlopend softwareproject.

Engels als nieuwe programmeertaal

Terwijl haar talk terugkijkt op dertig jaar taalontwikkeling, verandert Carpenters eigen manier van programmeren snel door AI. Tijdens een workshop bouwde ze met Claude Code een kleine chatdienst in Go, een taal die niet tot haar gebruikelijke gereedschap behoort. "Mijn agent heeft hem voor me in Go gebouwd. Zelf houd ik me meestal bij de talen waarmee ik mijn geld verdien."

"Mijn belangrijkste programmeertaal is op dit moment Engels. Dat is behoorlijk wennen."Dat roept een ongemakkelijke vraag op: voelt ze zich prettig bij productiecode waarvan ze niet iedere regel zelf heeft geschreven of uit haar hoofd kent? Ze begrijpt wat de software doet, maar kent niet automatisch elk detail van de gegenereerde code. Daar is ze naar eigen zeggen nog niet helemaal uit.

Tegelijkertijd krijgt ze meer gedaan. De nadruk verschuift van iedere regel zelf typen naar vooraf nadenken over ontwerp, architectuur en grenzen. Een programmeeragent heeft duidelijke instructies en structuur nodig. Zonder die sturing kan hij snel veel code produceren die het verkeerde probleem oplost. De snelheid van de agent neemt de verantwoordelijkheid voor review, tests en de uiteindelijke productiecode niet weg.

"Mijn belangrijkste programmeertaal is op dit moment Engels. Dat is behoorlijk wennen." Carpenter schrijft nog altijd graag code, maar haalt de meeste voldoening uit toepassingen die nuttig zijn en problemen voor gebruikers oplossen.

Een verhaal in plaats van een feitenlijst

Ervaring met Java of C# is niet nodig om Carpenters talk te volgen. De geschiedenis van Java vormt een herkenbaar voorbeeld van de afwegingen achter langlopende softwareprojecten. Dezelfde vragen spelen bij frameworks en platformen die jarenlang worden onderhouden: wat verander je, wat laat je staan en hoeveel bestaande gebruikers mag een verbetering raken? Java-developers krijgen mogelijk hernieuwde waardering voor hun taal. C#-developers mogen zich van Carpenter nog iets zelfvoldaner voelen.

Haar uitnodiging voor de Tweakers Developers Summit is eenvoudig: "Wil je iets leren over de geschiedenis van software, begrijpen hoe projecten zich door de jaren heen ontwikkelen of gewoon lachen ten koste van Java? Kom dan vooral langs."

Dev Summit 2026: Koop nu je kaartje voor de Tweakers Dev Summit 2026 en verdiep je in het complete programma!

Hou je ook zoveel van – of haat je vurig op Java? Dan mag je deze talk van Adele natuurlijk niet missen. Koop dan hier een kaartje. De stapel overgebleven kaartjes slinkt met de dag (geen grap!), dus wacht niet heel lang meer als je erbij wilt zijn. Meer informatie over het programma, workshops en de andere sprekers vind je op de aparte Dev Summit-website. We zien je heel graag in Utrecht!

Reacties (9)

[Vexxon]

"Mijn belangrijkste programmeertaal is op dit moment Engels. Dat is behoorlijk wennen."

Dit besef ik mij ook steeds meer en meer en daar baal ik best wel van soms.
De issue is vooral jongere collega's die alleen maar Engels spreken maar niet meer de programmeertaal die gebruikt wordt. "Het moet af" betekent tegenwoordig, laat AI maar genereren, als het werkt is het goed we hoeven niet te begrijpen wat we zelf opleveren. We bouwen dus niet alleen technical debt op maar ook cognitive debt.
Een bug in productie wordt weer opgelost door AI, ik denk dat veel bedrijven de deksel op de neus gaan krijgen over een aantal jaar wanneer de code niet meer te onderhouden is door mensen en ze totaal afhankelijk zijn van AI.

[Reactie gewijzigd door Vexxon op 23 oktober 2026 08:31]

[The Zep Man]

Daar komt de sterke achterwaartse compatibiliteit bij. Nieuwe versies moeten bestaande software zo min mogelijk beschadigen. Daardoor blijft soms oude ballast behouden, maar hebben organisaties doorgaans een duidelijk upgradepad en hoeven ze hun systemen niet bij iedere update te herbouwen. Carpenters team werkt inmiddels met Java 25 en ondervindt bij upgrades weinig problemen:

Ondertussen lees ik over horrorverhalen waarbij met veel moeite een organisatie een upgrade van Java 6 naar 8 uitvoert en daar zo'n beetje blijft hangen omdat de upgrade naar 11 pijn kan doen. Zie ook de staat van Java-installaties aan het begin van 2025. Het moet fijn zijn om tijdig voldoende middelen te krijgen om upgrades goed te testen en door te voeren.

[Reactie gewijzigd door The Zep Man op 23 oktober 2026 08:33]

[Gropah]

Volgens mij is voor 8 naar 11 voor veel enterprises een groot probleem (geweest) omdat er nogal wat breaking changes in zaten rondom java EE/jakarta. Ik heb zelf een aantal van die migraties gedaan. In het begin was het zeker even ploeteren, maar als je openrewrite gebruikt ben je er al snel. Sindsdien zijn er ook nog een paar dingen waar je rekening mee moet houden met upgraden, maar is het over het algemeen relatief makkelijk geweest.

[Hardfreak]

6 naar 8 en 8 naar 11 waren inderdaad wel vrij heftig, maar de upgrades naar de volgende LTS versies waren steeds minder en minder pijnlijk. Het grootste pijnpunt zit hem tegenwoordig vooral in speciale libraries zoals Lombok of andere libraries die heel diepgaande introspectie doen en zelf bytecode gaan beginnen injecteren at compile time.

Ook frameworks zoals Spring Boot en Quarkus moet je vaak mee upgraden naar de volgende major voor ondersteuning van de nieuwe Java versie. Daar zit je dan vaker met breaking changes, maar die komen soms ook gewoon voort uit veranderingen en deprecation van standaarden en libraries. Op die manier blijf je ook wel een beetje mee met de tijd.

Het is en blijft nog altijd een hoop werk, maar vaak is de JDK niet meer het grootste pijnpunt. Als je tijdens de lifecycle van je applicatie ervoor zorgt dat je je dependencies geregeld update, dan zou de migratie niet zo pijnlijk meer mogen zijn.

En just for fun and giggles, ik heb onlangs nog een java 8 desktop applicatie weten starten met java 25. Het enige probleem waar ik tegenaan liep was dat die een interne SSL class niet meer vond, maar die applicatie is dan ook blijven steken op TLS1.

[Wolfos]

De vergelijking met C# is incompleet zonder het .NET Core project te noemen. Microsoft heeft flink in C# geïnvesteerd met eigenlijk een volledige herimplementatie van C# en het hele ecosysteem eromheen.
Daar plukken we nu de vruchten van. C# is snel, cross-platform en modern terwijl Java nog altijd voortborduurt op dezelfde 30 jaar oude basis en een beetje achterblijft.

[Gropah]

Ik vind het persoonlijk wel meevallen hoe erg java achterblijft? Het heeft een tijdje stil gestaan (vooral tussen 7 en 11), maar de laatste tijd zijn er veel goede toevoegingen en verbeteringen geweest. Oracle kijkt goed naar andere talen, wat daar goed werkt en waar developers blij van worden. Dingen als records en pattern matching en (wat minder recent) de switch als expression kunnen gebruiken. En ook de JDK word nog steeds beter, met dingen als compact object headers (waardoor RAM verbruik verkleint, met alle gevolgen van dien) en de garbage collector is ook flink verbeterd.

Ik word persoonlijk iets blijer van kotlin (ja, ik ben een programmeur die JVM talen gebruikt ), maar het is niet alsof java echt een kriem is om mee te werken. En uit deze survey van Jetbrains lijkt hetzelfde te komen.

[Reactie gewijzigd door Gropah op 23 oktober 2026 09:00]

[pclin]

Weer zo’n presentatie over hoe achterhaald Java zou zijn, terwijl Java 25 flink is verbeterd sinds Java 8, dat inmiddels twaalf jaar oud is.

Dan wordt het feit dat sommige organisaties al die jaren niet zijn meegegaan met nieuwe Java-versies ineens gebruikt als bewijs dat Java moeilijk te onderhouden is. En in de introductie komt ook nog voorbij dat Java 1.2 vervelend was, dus dat Java wel een slechte taal moet zijn.

Jammer dat het weer zo’n talk is. Er staan er al zoveel op internet: “Java is dead” roepen om aandacht te trekken. De argumenten zeggen vooral iets over organisaties die zelf zijn blijven stilstaan.

Ik ben ook al 27 jaar Java ontwikkelaar en de code die ik nu schrijf lijkt niet op de code van in het begin. Ja, zoals bij alles in software ontwikkeling. 'It depends!'

[RichieB]

Lees eens het hele artikel. Dit is dus juist niet een "Java is dead" talk, maar ze legt uit waarom Java gewoon blijft bestaan naar alle andere talen.

[rneeft]

Voor wie ’m nog niet gezien heeft: YouTube: The Java Story | The Official Documentary is een leuke docu over het ontstaan van Java, de bijna-ondergang en de cadans waar ze tegenwoordig in zitten.