Ten eerste gaat het hier om de JRE en niet om de JVM, groot nuance verschil in dit verhaal.
Met de JRE (Java Runtime Environment) word de Sun/Oracle JVM (Java Virtual Machine) plus nog wat tooltjes (keytool, Java Webstart, browser plugin, etc) bedoelt. De JVM is waar al het werk gebeurt; Waar de bytecode omgezet word naar native code. De JVM is 95% van de JRE. Er is dus in deze discussie helemaal geen verschil.
Wikipedia linked je zelfs door naar de JVM als je zoekt op
Java Runtime Environment.
Ten tweede hebben Apple en Sun/Oracle altijd ten stelligste ontkent dat er ook maar iets aan ontwikkeling door Apple is gedaan
Bron ? Die is er niet kan ik je verklappen want dit is gewoon een keiharde leugen. Kijk dan naar
deze post van Mike Swingler. Hij noemt hier letterlijk Apple's eigen JVM implementatie:
we will be adding pieces and parts of our Java SE 6 implementation to the public project, and will cut over from using an X11-based AWT to a Cocoa NSEvent-based one with a new OpenGL-backed graphics layer.
Dat is ook niet zo raar want Java is geruime tijd closed source geweest. Sinds het OpenJDK verhaal is het semi-open source geworden. Zoals je al hebt kunnen lezen is Apple pas zeer recentelijk tot OpenJDK toegetreden en had het daarvoor geen enkele band met Sun/Oracle op dit vlak.
Het komt wellicht als een klap maar ook IBM, BEA (tegenwoordig ook Oracle) en HP hebben hun eigen JVM implementatie. Deze hebben ze als sinds ver voordat er ook maar over de opensourcing van Sun's/Oracle's JVM gesproken werd. Dan praten we niet over hun eigen installertje maar een eigen JVM. Welliswaar komt er ook code uit hotspot maar de JVM is substantieel aangepast (lees aanpassingen en toevoegingen aan de sourcode) voor hun specifieke eisen. Hierdoor moeten deze JVM implementaties ook opnieuw door de TCK heen om als Java compatible gecertificeerd te worden. In het geval van HP is dat voor HP-UX, IBM voor AIX en Webrockit van BEA is geoptimaliseerd voor servers (gebruikt bijvoorbeeld grote hoeveelheden geheugen om performance winst te behalen). Apple had ook een dergelijke eigen JVM allemaal al ver voor de opzet van het OpenJDK project. Al de code die Apple geschreven heeft voor deze eigen implementatie word nu in de OpenJDK gemerged.
Sinds het OpenJDK verhaal is het semi-open source geworden.
De source is GPL + Classpath exception. Je kan patches submitten en wijzingen aan de taal worden gedaan via het
Java Community Process waar partijen zoals Google en Redhat aan mee doen (was overigens al zo voor OpenJDK). Gewoon volledig opensource dus. Je doelt waarschijnlijk op de closed source variant die je nog van Oracle kan downloaden. Deze is er nog voor backwards compatibility doeleinde en Oracle heeft aangegeven dat OpenJDK de reference (ie. hoofd) implementatie is.
Dat kan echter ook betekenen dat ze wat aanpassingen moeten maken om dat voor elkaar te krijgen maar dit zijn aanpassingen aan de omgeving voor hun platform en niet iets wat weer teruggaat in de Java broncode en voor iedereen beschikbaar is.
Dat zouden dan hele opervlakkige aanpassingen moeten zijn want je beweerd net dat Apple de source van JVM niet had. Zoals hierboven nu al meerdere keren uitgelegd hadden ze die wel en maakte subsantieele aanpassingen en voegde code toe.
Sterker nog als Java programmeur merk ik dat zelfs. Bijvoorbeeld Apple's JVM delegeerd op Mac OS X de font rendering van Java 2D aan Mac OS X (quartz) in plaats van dat het in de JVM gebeurt (zoals bij de door Sun ontwikkelde JVMs op Linux en Windows). Hierdoor zien fonts er in Mac OS X in Java anders uit dan in Linux en Windows. Probeer dat maar is te doen zonder de broncode van de JVM.
Een hack is lang niet altijd het gevolg van falend beheer, verouderde software, etc.
Klopt, maar in het geval van nu.nl wel. Als je een dergelijke high profile site bent en de admin login van je CMS is vanaf het hele Internet toegankelijk (dus ook vanuit China, etc) en enkel beveiligd met een password dan is de kans dat het mis gaat behoorlijk groot. Kijk bijvoorbeeld naar een
ander willekeurig CMS wat die als deployment advies geeft.
want het kan even goed op up to date systemen gebeuren die zonder problemen door een security audit heen weten te komen.
Security is het doel, niet door audits heen komen. Als je door een audit komt betekend niet dat er geen gevaar is en dat je werk klaar is. Met andere woorden als je ergens niet vanaf weet betekend dat niet dat het niet bestaat, het betekend enkel dat je het in ieder geval nog niet gevonden hebt. Daarnaast zijn de meeste "audits" eindeloze vragen lijsten. Het is niet heel moeilijk om de waarheid zo te buigen dat je door een audit komt.
Ten vijfde: waar je naar linkt is niet meer dan een opinie stukje, de mening van iemand. Het is dus zeker geen objectieve onderbouwing van je relaas.
Dat is een blog entry van
James Gosling; De man die Java gemaakt heeft en vanuit Sun betrokken was bij de gesprekken over licensing van Java door partijen zoals Apple en Google. Je kan wat hij zegt niet wegwuiven als "een opinie stukje".
Ook daar gaat het alleen om de JVM en niet de JRE waar het juist hier om gaat.
Dat heb ik bovenin dus al uitgelegd. Daar zit dus geen verschil in voor deze discussie.
De link naar de zogenaamde secret APIs is naar een artikel van Arstechnica over allerlei undocumented APIs in OS X (Safari in het bijzonder) en dus niet Java specifieke APIs in OS X. Sterker nog, heel Java wordt er niet eens genoemd...
Je snapt duidelijk niet waar het over gaat. De crux van het verhaal is dat Apple voor haar Mac OS X JVM implementatie gebruik gemaakt heeft van API's in Mac OS X welke niet publiekelijk beschikbaar zijn. Dit maakt het overdragen van de Apple JVM naar een organisatie anders dan Apple extreem moeilijk.
Het stuk bij Arse is een voorbeeld dat ze vaker gebruik maken van API's in Mac OS X in hun eigen applicaties die niet beschikbaar zijn voor de rest van ons niet-Apple programmeurs.
Je helpt hier wederom totale onzin de wereld in. Je verspreid desinformatie welke je neerzet als de waarheid. Als je niet weet hoe het zit kan je er ook gewoon niks over zeggen.