Ook documentaire over ontstaan van Java is gratis te kijken op YouTube

YouTube-kanaal CultRepo heeft ook een documentaire uitgebracht over het ontstaan van de programmeertaal Java. De documentaire laat onder meer James Gosling aan het woord. Hij ontwierp Java bij het bedrijf Sun Microsystems.

De documentaire duurt een uur en veertien minuten en is gratis te bekijken op YouTube. Het is CultRepo's vijfde documentaire over het ontstaan van een programmeertaal: eerder behandelde het kanaal ook het ontstaan van Python, Clojure, Elixir en C++.

De documentaire heet The Java Story en begint bij Sun Microsystems in het begin van de jaren 90. Gosling vertelt dat Sun toen keek naar 'wat er speelde rond computers buiten de gebieden waar de industrie normaal gesproken aandacht aan besteedde'. De doorbraak van de taal kwam uiteindelijk na de release van Mosaic, de eerste browser. Het team van Gosling realiseerde zich toen dat het met 'Oak', de codenaam van Java, interactiviteit aan het internet kon toevoegen.

De documentaire behandelt ook de overgang van Java naar een opensourceplatform en de overname van Sun Microsystems door Oracle. Verder kijken experts naar de toekomst van Java. Ze benoemen daarbij onder andere Project Valhalla. Dat project moet de programmeertaal sneller en geheugenefficiënter maken.

Update, 18.42 uur – In het artikel stond aanvankelijk dat CultRepo drie documentaires over programmeertalen had gemaakt. Dat klopt niet: het kanaal heeft er vijf gemaakt. Dit is aangepast.

Vorige .geek Volgende .geek

Door Imre Himmelbauer

Redacteur

Feedback • 18-07-2026 13:37
65 • submitter: n9iels

18-07-2026 • 13:37

Submitter: n9iels

Lees meer

Documentaire over ontstaan van programmeertaal C++ staat gratis op YouTube

Documentaire over ontstaan van programmeertaal C++ staat gratis op YouTube .Geek van 5 juni 2026

Documentaire over oprichting van Python door Nederlander is uit

Documentaire over oprichting van Python door Nederlander is uit .Geek van 29 augustus 2025

Software development Webdevelopment Documentaire Java Youtube

IT-banen

Meer vacatures

Reacties (65)

65

62

27

0

0

22

Wijzig sortering

PhilipsFan 18 juli 2026 15:49

Ja, wat een ongelooflijk eind zijn we gekomen. Ik haatte Java in het begin, omdat het altijd een ongelooflijk gedonder was om die plugin te installeren en als je dan op een webpagina met een Java applet kwam, dan ging dat ongelooflijk traag. Ik had toen nog niet door hoe bijzonder Java was.

En nu programmeer ik er al jaren zelf in. Ik erger me nog steeds een beetje aan het trage opstarten, maar hoe bijzonder is het dat je je niet druk hoeft te maken om het platform waar je applicatie uiteindelijk op draait...

_Pussycat_ @PhilipsFan • 19 juli 2026 09:22

Ik heb er nog steeds een teringhekel aan. Oneindig langzaam in opstarten en als het draait, lelijk, gaat niet met DPI om, file picker past totaal niet bij het OS. Het enige goeie is het logo: zodra iets in Java is, kun je eerst een kop koffie gaan maken.

Wolfos @_Pussycat_ • 20 juli 2026 13:57

Welke applicaties zijn dat? Ik kan me echt niet herinneren wanneer ik voor het laatst een Java UI applicatie opstartte.

De meeste professionele tools gebruiken eigen UI frameworks of WPF. Meer consument-gerichte applicaties gebruiken web frameworks.

morrowyn @Wolfos • 20 juli 2026 15:41

Was/Is de Intellij UI niet met Java gemaakt? Misschien tegenwoording een mix van Java en Kotlin?

Wolfos @morrowyn • 20 juli 2026 17:50

Volgens mij zijn ze inmiddels over op Compose na die hele UI redesign. Maar het zijn wel Java applicaties idd, alleen niet de standaard Java UI.

morrowyn @Wolfos • 23 juli 2026 11:15

Compose kende ik niet, lijkt wel een mooie concurrent voor flutter en react native

jj71 @_Pussycat_ • 19 juli 2026 22:25

Het klinkt alsof je het hebt over Java voor desktop applicaties. Daar wordt het in de praktijk nauwelijks voor gebruikt. Het grote succes van Java is als backend taal, voor de backend van webapplicaties. Daar wordt het ontzettend veel voor gebruikt en is ook waar ik mijn carrière van heb gemaakt sinds 1998.

En applets, die eind jaren '90 amazing waren toen het WWW voornamelijk bestond uit statische tekst, zijn allang dood en werken in de huidige versie van Java niet eens meer.

[Reactie gewijzigd door jj71 op 19 juli 2026 22:31]

_Pussycat_ @jj71 • 20 juli 2026 01:47

Inderdaad, ik ken het alleen van de desktop. Laatste week nog for STM32cubeMX, een configuratietool voor STM Microcontrollers.

davince72 @_Pussycat_ • 20 juli 2026 13:08

Waarom moet je er een teringhekel aan hebben als het niet je smaak is?

Redeneer je ook zo over mensen of andere zaken?

Dan gebruik jij toch lekker een andere taal, genoeg andere mooie keuzes.

Persoonlijk ben ik wel enthousiast over Java icm Spring.

_Pussycat_ @davince72 • 21 juli 2026 03:46

Ik spreek zeker niet zo over mensen.

Dan gebruik jij toch lekker een andere taal, genoeg andere mooie keuzes.

Ik moet sommige Java-Software gebruiken als ik bepaalde tools nodig heb. Ik heb geen keuze.

@PhilipsFan • 18 juli 2026 16:03

Ik werk mee aan Apache CloudStack, een groot Java project.

Opstarten duurt even, maar daarna blijft het een snel en stabiel platform wat draait. Ik blijf het wel mooi vinden.

Over 25j is deze taal nog steeds groot gok ik zo maar.

elmuerte @Snow_King • 18 juli 2026 21:26

Ik werk mee aan Apache CloudStack, een groot Java project.
Opstarten duurt even

Dat heeft niks met Java te maken. Vroegah was dat wel anders. Java Applet's in the browser hadden nog een extra uitdaging, het downloaden van de code over je trage internet verbinding. Vaak waren de applets ook niet geminimaliseerd in grootte, en moest je soms wel honderden kilobytes downloaden voordat de applet kon starten.

[Reactie gewijzigd door elmuerte op 18 juli 2026 21:27]

@elmuerte • 18 juli 2026 21:37

Zeker wel, de JVM opstarten kost ook wel wat tijd. Alle Spring modules laden, is eventjes bezig. Maar als het dan eenmaal draait, dan draait het ook gewoon goed.

elmuerte @Snow_King • 18 juli 2026 21:45

JVM startup is niet gelijk aan een volledige Spring Application Context startup.

Inaldt @elmuerte • 19 juli 2026 10:47

Geen idee waarom je downvotes krijgt want je hebt natuurlijk helemaal gelijk. Het is juist Spring dat bekend staat om z'n trage startup. Andere frameworks hebben daar veel minder last van.

elmuerte @Inaldt • 19 juli 2026 17:30

Nou ja, trage startup. Dan hebben we het over een paar seconde voor een Spring applicaties die goed opgezet is. Een slecht opgezette, en grote Spring Boot applicatie kan nog wel behoorlijk wat secondes extra kosten.

Waar we het vroeger over hadden was een JVM startup van tientallen secondes. Application server startups van minuten.

Ja, runtime dependency resolution is traag; maar overgaan naar een compile time dependency resolution (e.g. quarkus) is niet een silver bullet. Gelukkig werkt Spring ook aan snellere startup constructie. Maar ook vanuit Java is er gewerkt om alle mooie byte code optimalisaties niet te verliezen bij een restart. En dan is er ook nog Project CRaC, die je Java applicatie nog sneller in de ready-state brengt (of je nu Spring, Quarkus, Micronaut, ... gebruikt.).

@elmuerte • 18 juli 2026 22:00

Technisch niet, maar het is bijna altijd wel zo dat Java applicaties en behoorlijke tijd nodig hebben om echt te gaan draaien. Het is niet instant. Het duurt altijd eventjes.

Zodra het draait, top!

Atlantis1995 @elmuerte • 20 juli 2026 13:47

Tegenwoordig heb je Spring Boot die alles regelt. Vroeger zat je te kloten met Apache Tomcat die afhankelijk waren van een versie die precies overeen moet komen. Spring is een verademing.

RRRobert @PhilipsFan • 18 juli 2026 18:42

Ik ben enkel gebruiker, en viel 20 jaar geleden van m'n spreekwoordelijke stoel van verbazing, toen mijn toenmalige werkgever (Amerikaanse multinational) een global database vrijgaf die geprogrammeerd was in Java, met een webinterface, waar tot die tijd altijd alles 'Microsoft only' was, tot aan de browserkeuze toe (IE7, destijds)

Nog groter was de verbazing dat we er achter kwamen dat we, met (een stiekem geïnstalleerde) Firefox destijds wel 70% sneller konden werken dan met de voorgeschreven Internet Explorer. Daarmee was de weerstand overigens wel snel verdwenen.

m_snel @RRRobert • 18 juli 2026 21:21

Mijn ervaringen uit die tijd of iets eerder was toch dat vaak Oracle gebruikte als database.

En volgens Google AI was het twintig jaar geleden een drama vergeleken met nu om via Java een database te gebruiken. Eigenlijk pas na 2006 kwam daar verandering in, misschien waren jullie dan een van de eerste, of Google heeft het helemaal mis.

Persoonlijk vond in het een drama , al was het maar alleen omdat na installatie de oude meuk gewoon bleef staan. Heel veel programmeurs oude versie bleven gebruiken die vol zaten met security problemen.

edwinjm @m_snel • 18 juli 2026 22:38

JDBC bestaat sinds (even opzoeken) 1997. Nooit een probleem gehad om daarmee te werken. Mysql, Postgres: het werkte prima.

m_snel @edwinjm • 18 juli 2026 23:09

Als ik even kijk naar de release in 2006 dan staat daar expliciet bij dat de functionaliteit sterk verbeterd is en het programmeren een stuk makkelijker maakt.

Veel programmeerwerk wil niet zeggen dat het niet prima kan werken en mis moet gaan.

Mortis__Rigor @m_snel • 19 juli 2026 09:35

In mijn eerste jaren als developer heb ik gewerkt met een resem verschillende databases (Oracle, DB2, Informix, MSSQL, eXcelon XML Database,...)

Eind 2006 is Java 6 uitgekomen, maar ik kan mij niet meer voor de geest halen wat er daar specifiek zou ingezeten hebben om werking met JDBC te verbeteren. De Autocloseable interface heeft het licht gezien met Java 7 (wat in 2011 was) waardoor je niet meer voor elk connectie/statement/... in de finally een close moest oproepen.

Langs de andere kant was hibernate al in gebruik. Versie 1 en 2 waren nog niet JPA compliant waren, vanaf versie 3 (2005) was dat wel het geval. Maar dat maakte toendertijd nog niet veel uit.

Spring had al programmatorische transactie support sedert versie 1.0 (2004) en de @Transactional annotatie bestaat al sedert versie 1.2 (2005)

Software development

@PhilipsFan • 19 juli 2026 16:24

maar hoe bijzonder is het dat je je niet druk hoeft te maken om het platform waar je applicatie uiteindelijk op draait...

Eigenlijk is het totaal niet bijzonder. Zork, zo een beetje de eerste game liep op een interpreter zodat men adventures kon schrijven en het niet uitmaakte op welk platform het draaide zolang dat maar een interpreter had.

Later waren de sierra games hetzelfde opgezet. En lucasart had ook iets. En er zullen nog vele andere voorbeelden zijn uit zowel de game wereld als de programmeer wereld voor we zelfs maar in de buurt komen van het jaar waarin java ontstond.

En dan hebben we nog smalltalk (veel eerder), python (zelfde tijd als java). etc etc etc... Je kan eerder zeggen dat virtual machines in de mainframe tijd normaler waren. Want dan kon je programma's over zetten tussen de wild verschillende architecturen van die tijd.

En laten we wel zijn .net is ook al jaren cross platform. Eerst via mono, maar tegenwoordig gewoon via de standaard .net familie. En open source.

Gekeken naar wat er staat op: Wikipedia: Project Valhalla (Java language) lijkt het wel alsof ze .net willen nadoen. Daar zijn de genoemde syntax verbeteringen de normale methode.

cdwave @PhilipsFan • 20 juli 2026 14:42

Er zijn vast een paar niches waar Java goed te gebruiken is.

Ik heb het altijd een slecht ontwerp met een nog slechtere implementatie gevonden. Het geheel straalt "ivoren toren" uit. Zoals de beslissing om maar geen "unsigned" types te hebben...

Belangrijkste technische pijnpunt is dat Java zo'n beetje z'n eigen OS binnen het OS vormt. Dat betekent dat het delen van geheugen vrijwel niet werkt, het OS ziet geen verschil tussen code en data, en samenwerking met het OS om geheugen te beheren is ook ver te zoeken.

Waar je Python nog wel op een embedded systeem kunt zetten, met alleen de modules die nodig hebt, geldt voor Java een alles-of-niets benadering en je hebt honderden megabytes nodig om zelfs maar een headless applicatie te kunnen runnen. Niet dat veel mensen dat gaan proberen - het cross-compileren van de JRE is een drama,ook Yocto is er maar mee opgehouden om het nog te proberen.

Llopigat 18 juli 2026 15:45

Sun zag het destijds als een taal die door speciale bytecode processoren gerund zou worden. Ik heb nog eens met zo eentje gespeeld, de NC1, network computer 1. Het was daar zelfs het hele OS. Het ding was helaas niet vooruit te branden zo graag. JIT compilatie was toen nog niet uitgevonden.

Maar de overname door het kwaadaardige Oracle heeft de techniek doen tanen. Nu is JavaScript (dat niks met Java te maken heeft) veel groter.

MSalters @Llopigat • 19 juli 2026 00:16

JIT is natuurlijk geen ding als de CPU zelf al bytecode runt. JIT compileert van bytecode naar native assembly.

Llopigat @MSalters • 19 juli 2026 00:19

Nou die CPU deed dat niet echt. Het was gewoon een omgekatte sparcstation die een interpreter draaide. Dat was ook meteen de reden dat dat ding niet vooruit te branden was.

Het idee was wel om daar naartoe te gaan maar daar is het nooit van gekomen. In plaats daarvan kregen we dingen als JIT.

[Reactie gewijzigd door Llopigat op 19 juli 2026 00:39]

elmuerte @Llopigat • 19 juli 2026 17:04

Afhankelijk welke JavaStation je had was het 100% een read-only thin client. Het draaide een basis OS met Hotjava, en daarna moest je alle software downloaden. Veel van de traagheid kwam door het continue downloaden van code, en minder door het uitvoeren van de bytecode. Het was zelfs zo erg dat code vaak opnieuw gedownload moest worden omdat het ontladen was voor ruimte vrij te maken. Maar ook de bytecode execution was niet bijzonder snel. Leuk concept, maar de hardware wat te weinig RAM, geen storage, en dus enorm afhankelijk van een "snelle" netwerkverbinding (10Mbps iirc).

De java in die tijd had nog geen optimizer. Je Java code vertaalde direct naar bytecode zonder echte optimalisaties. Als je C code direct naar CPU instructies compileert krijg je ook geen fantastische performance. De introductie van de JIT runtime compiler zorgde initieel voor snellere executeerbare code, en later ook voor code optimalisaties. De java compiler doet nog steeds niet echt aan code optimalisatie. Dat wordt zo'n beetje allemaal at runtime gedaan door de JIT, want die is veel beter in code optimaliseren (en die kan dat doen voor alle talen die naar de JVM byte code compileren).

Llopigat @elmuerte • 19 juli 2026 18:25

Oh dat wist ik niet. Ik heb zelf ook nog een Sun Sparc XTerminal 1 gehad. Dat was dan eigenlijk ongeveer hetzelfde, die had ook geen lokale opslag, die moest altijd van het netwerk booten. Hij had ook te weinig geheugen om volledige Solaris te draaien dus ik draaide er meestal BSD op.

De Javastation heb ik alleen op een beurs geprobeerd toen. Maar die was echt lachwekkend traag. Dat was nog de eerste die ook gewoon in een sparcstation kastje zat (die later zag er meer uit als een sunray).

[Reactie gewijzigd door Llopigat op 19 juli 2026 18:26]

MSalters @elmuerte • 19 juli 2026 18:37

Als je C code direct naar CPU instructies compileert krijg je ook geen fantastische performance.

Ik weet niet waarom je dat denkt. Dat is compleet normaal. GCC werkt zo, MSVC ook. En dan heb je het performance nivo waar andere talen naar streven.

elmuerte @MSalters • 19 juli 2026 19:50

Zelfs met -C0 doet GCC aan optimalisaties, je moet extra moeite doen om de standaard optimalisaties uit te zetten. En zelfs dan zou de compiler stiekem optimalisaties kunnen doen omdat in de AST of intermediate language bepaalde nutteloze input komen te vervallen. Zoals bijvoorbeeld een `i++` zonder assignment, zal gecompileerd kunnen worden alsof het een `++i` was.

Mijn punt was niet dat een direct C naar machine code compiler slechtere performance zou leveren dan andere talen. (Als een C compiler dat zou doen, zou elke compiler die dat doet, dezelfde machine code produceren.) Mijn punt was dat "als je C code direct naar CPU instructies compileert", en dus ook al je onhandige code op die manier naar machine code vertaald, je geen fantastisch performance hoeft te verwachten. Dat was ook een beetje de situatie met Java in het begin, en in plaats van te focussen om optimalisatie in de compiler, hebben ze meer gefocused op runtime hercompilatie. Want dat zou ook al eerder gecompilede code kunnen optimaliseren. Alleen de syntactic sugar heeft daar geen voordeel bij. (i.e. `"foo" + bar` gecompileerd met Java 1 doet het niet zo goed dan als het gecompileerd was met Java 5+ (StringBuffer vs StringBuilder).

MSalters @elmuerte • 20 juli 2026 11:07

Ik noem specifiek MSVC en GCC omdat die geen Intermediate Representation hebben, LLCM/clang heeft die wel.
Een AST is een ander verhaal: dat is een boomstructuur om de source code te begrijpen.

Ook je idee dat een "directe compilatie" altijd dezelfde code zou opleveren ongeacht de compiler is erg vreemd. Dingen als variabele allocatie naar stack en/of register zijn variabel. Sterker nog, afhankelijk van de precieze CPU kan een compiler daar andere keuzes maken.

fenrirs 18 juli 2026 20:02

Java, best een eind in gekomen. Het idee was mooi, maar volledig ingehaald door talen die, ofwel sneller te begrijpen waren voor beginnelingen( en daar zijn er veel van) hoeveel talen die sneller zijn). De haat tegen Oracle zal ook zeker meegespeeld hebben.

Des al niet te min, dingen die werken blijven gewoon werken, in tegenstelling tot andere populaire talen

Llopigat @fenrirs • 19 juli 2026 00:42

Wat ik ook zie met moderne talen is het ecosysteem dat veel belangrijker is. Met traditionele talen moet je externe libraries zelf regelen. Met commerciële software moest je daar zelf vaak flink voor betalen. Met npm, pip enz wordt het je heel makkelijk gemaakt.

Dit heeft nadelen zoals security, er wordt vaak malware in libraries aangetroffen. En dat dingen soms kapot gaan als een externe library verdwijnt omdat de maintainer er geen zin meer in heeft. Maar het heeft ook veel voordelen als veel sneller en makkelijker kunnen ontwikkelen en verspreiden.

keigezellig123 @Llopigat • 19 juli 2026 07:53

Java-dev hier. Het ecosysteem is bij Java net zo belangrijk. Frameworks als Spring (Boot) en Quarkus worden heel veel gebruikt (allemaal open-source) en via Maven en Gradle (package managers, vergelijkbaar met npm en pip) zijn heel veel externe libs beschikbaar. En ja hebt dezelfde mogelijke vulnerability/dependency hell als bij andere package managers.

fenrirs @Llopigat • 19 juli 2026 07:29

Dat is allemaal in java net zo erg. Log4J anyone? Een developer die er mee op houd: je hebt toch zeker alles lokaal mag ik hopen?

Wolfos @fenrirs • 19 juli 2026 10:25

Ik krijg van Nuget waarschuwingen als er ergens een kwetsbaarheid zit. Als ik alles offline zou houden dan zou ik nog steeds die kwetsbaarheden hebben maar dan zonder waarschuwingen wanneer ze gevonden worden.

[Reactie gewijzigd door Wolfos op 19 juli 2026 10:25]

fenrirs @Wolfos • 19 juli 2026 11:22

Eerste hit op google hoe je nuget kan gebruiken om lokale packages te scannen

Powerblast 18 juli 2026 14:29

Blijven wel leuke documentaires vind ik als je wat in het wereldje zit

. Is eens wat anders dan de standaard docu's die je meestal tegenkomt. Helemaal top dat ze dit gratis aanbieden natuurlijk. Daarnet eerste half uurtje alvast bekeken, weer wat bijgeleerd over het ontstaan van de taal. Zeker een aanraden voor diegene die wat meer willen weten over waarom Java ontworpen is.

Navi @Powerblast • 18 juli 2026 15:42

Ik vind ze ook leuk, pas die van C++ gezien.

Af en toe vind ik ze wel iets teveel ge-edit door alleen maar one liners en quotes van prominente personen achter elkaar te plakken. Soms gaat het zo snel dat je niet eens kon lezen wie die persoon dan was incl functie titel.

Ze mogen af en toe ook wel een een verhaal of anecdote vertellen ofzo.

18 juli 2026 13:48

Heel raar dat het artikel niet direct linkt naar de documentaire, dus alstublieft: YouTube: The Java Story | The Official Documentary

CH4OS @Iekozz • 18 juli 2026 13:50

Terranca in "Ook documentaire over ontstaan van Java is gratis te kijken…"

Meerderen vinden het raar, het is dus ook hier gemeld.

@CH4OS • 18 juli 2026 13:51

Jullie zijn snel

.

warp 18 juli 2026 15:48

De doorbraak van de taal kwam uiteindelijk na de release van Mosaic, de eerste browser.

Dit klopt niet helemaal, Mosaic was de eerste populaire browser. De eerste browser heette WorldWideWeb en werd geschreven door de uitvinder van het wereldwijd web, Sir Tim Berners-Lee in 1990 en werd geïntroduceerd aan zijn collega's bij CERN in maart 1991...

bommel 18 juli 2026 18:22

Een documentaire over het ontstaan van Java? Klinkt voor mij toch vooral als een horrorfilm. Te veel enterprise line-of-business-apps gezien die zo lek zijn als een mandje en ondertussen meer geheugen vreten dan Chrome. 😉

elmuerte @bommel • 18 juli 2026 21:40

Dat heeft niks te maken met Java. Ja, EJBs waren meer een probleem dan een oplossing, maar als je dan toch echt met vingers wilt gaan wijzen moet je die naar CORBA wijzen. Daar ligt je probleem. De voornaamste reden waarom dit soort "enterprise software" zoveel in Java geschreven werd is omdat het daar wel redelijk werkend was te krijgen. De echte oorzaak van de problemen ligt bij de snake oil en silver bullet verkopers die nog steeds rondlopen.

bommel @elmuerte • 19 juli 2026 10:45

Gedeeltelijk eens: slechte ontwikkelaars heb je overal, en daar kan een programmeertaal op zichzelf weinig aan doen.

Maar ik heb genoeg quality time met de debugger en IDA Pro op de JVM doorgebracht om Java-crashes te onderzoeken, om te zien dat ook de runtime zelf lang niet altijd fraai in elkaar zat. Soms leek het alsof de ontwikkelaars iedere ongedocumenteerde Windows-API per se zelf wilden aanroepen.

Een concreet voorbeeld: om een COM-object te maken gebruik je normaal CoCreateInstance. De JVM bouwde daar echter een eigen variant omheen met LoadLibrary en GetProcAddress om rechtstreeks de standaard COM-export DllGetClassObject op te zoeken. Maar dan zonder degelijke foutafhandeling. Als een COM-DLL niet exporteerde wat men verwachtte, eindigde dat soms gewoon in een access violation. En zo kan ik nog talloze voorbeelden noemen.

Ook de upwards compatibility was in de praktijk vaak matig. Bij veel applicaties kon je niet zomaar een nieuwere, veiligere JRE installeren zonder het risico dat de applicatie niet meer werkte. Daardoor bleven oude, kwetsbare runtimes jarenlang naast elkaar op werkstations staan.

En de droom van universele applicaties leverde vooral software op die, om de bekende uitdrukking te gebruiken, “sucked equally well on all platforms”. Omdat er voor de least common denominator werd ontwikkeld, zag het nergens echt native uit en profiteerde het nauwelijks van de specifieke mogelijkheden van het onderliggende besturingssysteem.

Dus nee, niet alle ellende was “de schuld van Java”. Maar de JVM, het ecosysteem en het beheer eromheen hebben daar in de praktijk zeker ook hun aandeel in gehad.

keigezellig123 @bommel • 19 juli 2026 07:58

Dat was misschien vroeger zo. Tegenwoordig zijn de jvms en frameworks beter geoptimaliseerd, maar een deel hangt natuurlijk ook van de developer af

CPM @bommel • 19 juli 2026 08:44

Helemaal waar. 10 jaar terug ook gewerkt met een op Java gebaseerd rooster pakket. Niet vooruit te branden en geen leverancier die het kon oplossen. En dan hebben we het nog niet over de cliënt. Deze wilde je gecontroleerd uitrollen/updaten binnen een organisatie. Echter toen Oracle ineens geld wilde zien voor de "speciale" .msi werd het uitrollen nog meer drama. En dan had je nog cliënt versie afhankelijke software. En dat je na installatie van de nieuwe cliënt de oude, lekke cliënt gewoon nog op een werkstation bleef staan, tenzij specifiek verwijderd.

Idd een horror movie. Nooit begrepen dat Java, misschien mijn onwetendheid, maar altijd ellende qua beheer.

[Reactie gewijzigd door CPM op 19 juli 2026 08:45]

FastFox91 18 juli 2026 13:59

Samenvatting in het Nederlands: https://youtube-summarize.msvos.nl/summaries/the-java-story-the-official-documentary-542

himlims_ 18 juli 2026 14:20

Ook tutorials over Java zijn gratis te kijken op YouTube

Borgia 18 juli 2026 15:51

Wat fijn dat die gratis is! Een echte primeur.

Om te kunnen reageren moet je ingelogd zijn