Sun: 'Java binnen twee maanden open source'

Sun-ceo Jonathan Schwartz kondigde op de Oracle OpenWorld-bijeenkomst aan dat het bedrijf binnen de twee maanden de broncode van Java openbaar zal maken. Dat het programmeerplatform openbaar zou worden, was al aangekondigd, maar concreter dan 'in de eerste helft van 2007' was men tot nu toe nog niet geweest. Uit de toespraak van Schwartz blijkt nu echter dat de broncode nog voor 2007 verwacht mag worden. De source van de Java Standard Edition zal onder een OSI-licentie vrijgegeven worden, maar concrete details zijn nog niet onthuld. Het gebruik van de CDDL, die ook op Suns besturingssysteem Solaris toegepast wordt, lijkt het waarschijnlijkst.

Eerder was de GlassFish-applicatieserver uit Java Enterprise Edition al onder een opensourcelicentie ter download aangeboden, maar met het beschikbaar stellen van de broncode van Java Standard Edition krijgen ontwikkelaars nu ook inzicht in de core van het Java-platform. Sun zet deze stap onder druk van de community, die al geruime tijd vraagt om mee te kunnen denken over de ontwikkeling van het Java-platform, maar dat werd tot kortgeleden steeds geweigerd door het bedrijf. Mogenlijk is Sun ook tot inkeer gekomen door de positieve ervaringen met het openbaar maken van Solaris, waarvan er tot een drietal weken geleden zes miljoen licenties verkocht werden. Sinds het opensource maken van het besturingssysteem is zowat zeventig procent van de verkochte licenties meegeleverd met een server van Dell, HP of IBM.

Reacties (44)

[ari3]

De sourcecode vrijgeven is prima, maar ik hoop wel dat niemand iets mag distribueren dat niet 100% voldoet aan de specificatie. Dat zou echt een stap terug zijn. Kijk maar wat er gebeurd is met de HTML-specificatie. Zoveel verschillen tussen browsers dat het niet leuk meer is.

Het is van het grootste belang dat de spec afgedwongen wordt anders moet voor het uitleveren van Java programma's straks gepatchte versies voor specifieke OS- en JVM-vendors uitgeleverd worden. Zit ik persoonlijk niet op te wachten.

Het huidige systeem voldeed prima. Je kunt nu al kiezen uit verschillende JVM implementaties. Deze zijn tenminste wel gecertificeerd zodat je een zekere aanname kunt maken over de kwaliteit van de implementatie.

[humbug]

Dit is al lang de praktijk.

Op de PC niet omdat
a) een PC makkelijk van nieuwe java versies voorzien kan worden
b) een PC eigenlijk standaard de Java virtual machine van Sun draait.

Maar bij enterprise servers of telefoons kun je heel veel verschillende virtual machines tegenkomen die allen net wat andere extensies ondersteunen.

In praktijjk is de eerste regel van mijn java code dan ook het aanroepen van een methode om achter de gebruikte virtual machine te komen. Ja de basisfunctionaliteit is overal hetzelfde maar in praktijk zijn sommige extensies verdraaid handig.

[ari3]

Op de PC niet omdat
a) een PC makkelijk van nieuwe java versies voorzien kan worden

Een nieuwe java versie is een nieuwe versie van de specificatie. Dit is niet hetzelfde. Iedere J2SE 1.4 moet namelijk exact aan de spec voldoen. De versie van de JVM doet er niet toe zolang de spec maar geïmplementeerd is.
b) een PC eigenlijk standaard de Java virtual machine van Sun draait.

Er zijn verschillende JVM-implementatie voor PCs. Op zich moet een Java programma zich niet druk maken over welke JVM wordt gebruikt. Zolang de spec geïmplementeerd is zal het werken.

Maar bij enterprise servers of telefoons kun je heel veel verschillende virtual machines tegenkomen die allen net wat andere extensies ondersteunen.

Extensies zijn geen onderdeel van de platform specificatie. De interfaces die de basis zijn voor de extensies wel. Het meeleveren van extensies fragmeneteert de Java basis functionaliteit en zou ontmoedigd moet worden. Een Java applicatie die afhankelijk is van extensies doet er daarom goed aan deze extensies mee te leveren als dependency.

[humbug]

Je gaat hierbij volledig voorbij aan JSRs. JSRs zijn wel degelijk onderdeel van de platform specificaties. JSRs beschrijven namelijk de verschillende vernieuwingen die in toekomstige platformen terecht moeten gaan komen. Vaak zijn deze JSRs al lang af en in gebruik voordat ze onderdeel worden van een nieuwe standaard. Een nieuw platform is dan ook niet veel meer dan een bundeling van verschillende JSRs tot een geheel. Waarbij er dan ook nog ruimte is voor optionele en hardwareafhankelijke functies. Dus zelfs als je gebruik maakt van een bepaald platform kun je er niet vanuit gaan dat alle als optioneel of hardware afhankelijk gespecifiseerde onderdelen van dat platform ook daadwerkelijk geimplementeerd zijn.

Bij PCs is het nog relatief eenvoudig om nieuwe JSRs te gebruiken, je levert de libraries voor die extra functionaliteiten mee en je bent meestal klaar. Maar ook hier komt het voor dat niet elke JVM zomaar werkt met deze extensies. Bij andere hardware platformen is dit al helemaal geen optie. Als het platform bepaalde functionaliteit gewoon ontbeert, kun je wel libraries voor die functionaliteit meeleveren maar werken gaat het echt niet. In andere gevallen werkt het wel, maar moet de library volledig aan de gebruikte hardware worden aangepast. In die gevallen is het gewoon onmogelijk om de juiste libraries voor alle potentiele hardwareplatformen mee te leveren. Je zult dan toch echt moeten wachten totdat er een nieuwe JVM beschikbaar komt voor dat platform (vaak kansloos), een ander platform moeten gebruiken of je code zo schrijven dat het in staat is met of zonder die functionaliteit te werken.

[jj71]

Veel (de meeste?) mensen denken nog steeds dat Sun nu eindelijk de source code van hun JVM / JDK gaat vrijgeven.

Dat is niet zo, want die source code is al jarenlang gewoon verkrijgbaar, je kunt 'm gewoon downloaden op de Java SE downloadpagina (scroll naar beneden naar "J2SE 5.0 JDK Source Code").

Het hele Java open source verhaal gaat alleen maar over de licentie. Je kunt op dit moment kiezen tussen twee licenties: Sun Community Source License (SCSL) of Java Research License (JRL). Ik heb verder geen verstand van die licenses, maar die zullen wel niet compatible zijn met wat er "open source" wordt genoemd. Er zal wel een echte OS licentie voor SCSL en JRL in de plaats komen.

[Onno]

Veel (de meeste?) mensen denken nog steeds dat Sun nu eindelijk de source code van hun JVM / JDK gaat vrijgeven.

En helaas geldt dat ook voor de nieuwsposters op tw.n, want keer op keer komen er in de artikelen over Java weer zinnen als

met het beschikbaar stellen van de broncode van Java Standard Edition krijgen ontwikkelaars nu ook inzicht in de core van het Java-platform.

voor. Beetje jammer.

[smokalot]

Ik hoop dat de licentie vrij genoeg is... Anders schieten we er per saldo weinig mee op, nog steeds geen java zonder je vrijheid op te geven, maar nog minder animo om aan een echte open java te werken (zoals GNU classpath en dat Apache project).

[Left]

Het is maar de vraag of het zo prettig is dat er een open licentie komt. Volgens mij zit niemand erop te wachten dat er allemaal verschillende jvm's komen met hun eigen aanvullingen op de Java specificatie.

[Verwijderd]

Momenteel zijn er al verschillende Java versies ( https://help.ubuntu.com/community/Java )
Dit moest omdat Suns java niet vrij was. Mss kunnen distro's zoals Ubuntu vanaf nu Suns Java gaan leveren. Dat zou zeker beter zijn.

[beantherio]

Java is toch gestandaardiseerd? Het lijkt me niet dat je iets 'Java' mag noemen terwijl het niet aan de specs van Java voldoet.

[kozue]

Er gaat toch niemand extensies gebruiken die niet overal ondersteund worden. De officiële jvm is nog altijd de reference jvm, en zal normaal gebruikt worden om apps op te ontwikkelen.
Bovendien heb je wat jij omschrijft nu al. Eclipse gebruikt extensies om GTK te kunnen gebruiken, ipv de standaard look&feel, die niet goed in je desktop integreert. En dat levert niet echt problemen op. Of heb jij wel eens een systeem gehad waar Azureus niet op draaide?

[Left]

@Finalbeta
Ja er zijn nu ook verschillende andere JVM's, maar die moeten allemaal wel voldoen aan de Java Language Specification. Dus software die op de ene jvm draait, draait ook op alle anderen.

@beantherio

Er gaat toch niemand extensies gebruiken die niet overal ondersteund worden.

Nou mijn reactie was op de post van smokalot, en die stelde al voor om GNU Classpath in een JVM te integreren.

Bovendien heb je wat jij omschrijft nu al.

Ik zou niet weten waar. Eclipse gebruikt SWT, dat is een aparte software library die niet deel uitmaakt van een eigen JVM of zo.

[Cameleon73]

Microsoft had express een brakke JVM (zie dit artikel). Hun plannetje om Java uit de wereld te helpen is (tot op heden) niet gelukt.

[humbug]

Wat gek, vandaar dat ik dagelijks moet kijken welke hardware welke JSRs ondersteund.....

Er is een hele java wereld buiten de PC.

[moto-moi]

Er gaat toch niemand extensies gebruiken die niet overal ondersteund worden. De officiële jvm is nog altijd de reference jvm, en zal normaal gebruikt worden om apps op te ontwikkelen.

Ach, Microsoft was blijkbaar wel zo gek, gelukkig heeft hun te brakke implementatie het uiteindelijk niet gered, maar er bestaat wel een kans dat het weer gaat gebeuren.

[JKVA]

Java is meer dan client apps zoals Azureus.

Binnen de Java Enterprise wereld wordt IBM WebSphere heel veel gebruikt als applicatieserver. En ja hoor, die gebruikt de JVM van IBM, niet die van Sun.

En die twee zijn niet hetzelfde.

[Verwijderd]

Die andere Java's kun je vergelijken met Wine. Proberen zo veel mogelijk de originele versie te imiteren.

Over Azureus, het draaide niet op alle Java's.

[Verwijderd]

Die andere Java's kun je vergelijken met Wine. Proberen zo veel mogelijk de originele versie te imiteren.

Onzin, dat geldt alleen voor de zogenaamde clean room implementaties (cafe bv).

De gelicentieerde implementaties (ibm en bea) hebben gewoon toegang tot de volledige spec en al haar details.

Zowieso was de source, zowel van de interne sun classes als van de VM ook al iets langer te downloaden. De source van de publieke classes is altijd al beschikbaar geweest.

Beschikbare source is echter niet gelijk een open source. Open source betekent heel kort gezegt dat je mag veranderen en de veranderingen mag verspreiden. Tot op heden kon precies dit nou net niet.

[dkong]

Je kunt hoe dan ook wel lekker gaan kijken hoe alles werkt.

[Verwijderd]

Je kunt nu ook al een package met alle .java files downloaden die in de API staan.

[Verwijderd]

Het gaat niet om de rt.jar, maar om de source van de JVM.

[Verwijderd]

Dat weet ik, maar volgens mij denkt dkong dat we nu pas toegang krijgen tot de .java-files uit de API, vandaar mijn reactie.

[Verwijderd]

@krpors en @ViVa:

jullie bedoelen de sources voor de VM zoals deze?

http://download.java.net/jdk6/beta2/

Voor je het geval dat je me niet gelooft, lees de readme:

The hotspot directory contains the source code and makefiles necessary for building the Java HotSpot Client VM and the Java HotSpot Server VM.

Dus ook deze code is al een tijdje beschikbaar. Sun is altijd erg open geweest wat code betreft. Wat er gaat veranderen is de LICENTIE van deze code en dus wat je er mee kunt doen.

Ik kan de link nu even niet meer vinden, maasr er stond laatst ergens op een blog van een Sun engineer wat ze allemaal moeten doen voordat ze alles Open Source kunnen maken en daar wordt je toch echt moe van als je er alleen naar kijkt.

Één van de dingen was iets van 400.000 commit messages aflopen (omdat ook de source code repository wordt opengesteld, niet alleen de laatste code of zo) om te kijken of er in het _commentaar_ iets staat wat ze niet mogen publiceren!!

[Jrz]

Dat kan al jaren. Gewoon de source halen van jdkxxx en je kan aan de slag.
Het is dat ze niet een simpele build hebben, maar een waar je je hele systeem omzeep moet helpen, anders had ik wel wat veranderd..

[crzyhiphopazn]

Is dit niet juist gevaarlijker omdat er via java scripts spy/malware geladen kan worden??

[n4m3l355]

Is dit niet de eeuwige discussie waarom open/closed software beter is? Er zijn tientallen (misschien zelfs honderden) onderzoeken die aantonen dat of wel open of wel closed beter is. Misschien is het beste om dit gewoon in het midden te laten en in dit geval je eigen voordeel eruit te slaan binnenkort.

[smokalot]

dit heeft niets met javascript te maken.

En persoonlijk vertrouw ik een product meer als ik kan zien wat erin zit, en gelukkig zijn er meer mensen die er zo over denken.

[4VAlien]

zoals smokalot zegt: Java IS GEEN Javascript. Verder is Java niet zo gevoelig voor buffer en stack overflows vanwege het VM concept waarin gecontroleerd wordt of een bepaalde index in een array of stack wel bestaat voordat deze gelezen of beschreven wordt.

[kozue]

Nee, want die bug die misbruikt wordt om de malware te laden is sneller gefixt dan geëxploit, omdat niet alleen crackers die code in kunnen kijken, maar ook de good guys

[twiFight]

En welk bewijs heb jij dan dat de fixers sneller zijn dan de exploiters? Je stelt het hier als een feit.

[killercow]

Agh, alsjeblieft kijk anders eens op secunia ofzo.

[Verwijderd]

Fixen is een ding, zorgen dat de fix ook op (vrijwel) alle systemen geinstalleerd wordt is punt 2. Dat kan best even duren.

[Verwijderd]

Mischien kan iemand een lichtere versie maken?
De runtime die ik geïnstalleerd heb is 120 MB, sinds wanneer is Java eigenlijk zo groot geworden?

[Remus]

De 1.5.0_09 JRE is 'maar' 70MB, de JDK (development kit) is 120MB. Het vrijgeven van de java source zal hier weinig verschil in brengen, aangezien het grootste deel (>50MB) van de grootte gaat zitten in de libraries/APIs die met Java worden meegeleverd en niet in Java zelf.

[humbug]

Lichter betekent bijna altijd verlies aan functionaliteit en dat wil je ook niet. Nee, persoonlijk vind ik het niet zo erg dat Java en .Net zoveel MBs opslokken want je krijgt er ook heel veel voor terug. Maar ik vind wel dat java (en .Net) gewoon standaard geinstalleerd moet worden als onderdeel van het OS.

Met deze stap komt Sun tegemoet aan Linux distributies die Java weigerde mee te leveren omdat het niet "Open" genoeg was. Als dat betekent dat Java binnenkort standaard op Linux systemen staat denk ik dat Sun hier een goede stap mee doet. Maar ik ben bang dat het alleen tot verbrokkeling van Java gaat leiden en elke Linux distributeur zijn eigen aanpassingen gaat doen.

[Verwijderd]

Waarom zou een Linux-distributeur aanpassingen aan een taal willen doorvoeren? Je zou zeggen dat Free Software ontwikkelaars geleerd hebben van de browser wars.

Je ziet toch ook geen afbrokkeling van Firefox? Nouja, qua naam misschien, maar dat komt nu juist doordat Mozilla (terecht) de merknaam verdedigt.

[humbug]

Geen flauw idee, handig is het waarschijnlijk niet.

Maar het is wel zo dat er "optimalisaties" aan de JVM toe te voegen zijn zodat de kans bestaat op verschillende JVMs, al was het maar om een lichtere versie te maken. Als dat gebeurd raakt Sun de controle kwijt en kan er een heerlijke stammenstrijd gaan ontstaan. Een beetje zoals met Gnome en KDE. Java is wat dit betreft niet te vergelijken met een programma als FireFox. FireFox heeft 1 doel, webpagina's zo goed mogelijk weergeven. Java wordt gebruikt voor een hele hoop toepassingen waarbij iets wat noodzakelijk is voor de ene doelgroep, nutteloze bagage kan zijn voor een andere. Java is nu trouwens ook al geen uniform product (J2ME is niet vergelijkbaar met J2SE) en een verdere opsplitsing is zeker niet ondenkbaar.

En dat Open Source ontwikkelaars geleerd hebben van de "browser wars" is maar te hopen. De geschiedenis van open source is doorspekt met politieke spelletjes. De controlle over Java is helaas iets waar ik wel weer wat politieke touwtrekkerij over verwacht. En de mooiste manier om de controlle over Java te verkrijgen is nu eenmaal een alternatieve fork te maken en die te verspreiden onder jou bezielende leiderschap.

[Verwijderd]

Tsja, aan de taal zelf (dus de VM ed) zullen ze niks willen veranderen neem ik aan, maar er zijn verschillende voorbeelden te verzinnen waarom Linux distributies een soepeler licentie zullen waarderen:

1. Distros zoals Debian en RedHat/Fedora kúnnen nu geen Java leveren want de licentie is niet OSS en dat is tegen hun regels. Dat veranderen is net zoals de Paus vragen om moslim te worden.

2. Distros hebben een vaste "layout" waar de files allemaal moeten staan. Dit is per Distro verschillend. Sun levert maar één installer en de huidige regels verbieden het aanpassen van het geheel. DUs zoals je het download van hun website zo moet je het EXACT installeren op het systeem. Geen probleem al sje het zelf installeert, maar voor Distros zou het een zooitje worden.

3. Het kan zijn dat een Distro een security probleem tegenkomt die zij heel belangrijk vinden maar Sun niet. Dan is het wel handig als jij kunt beslissen om de patch NU al uit te bengen en niet te wachten op Sun.

Zo zijn er vast nog wel meer voorbeelden te verzinnen.

Ik hoop echt dat de stap van sun om de code open source te maken een sterke verbetering zal alten zien voor Linux distros in de toekomst!!!

[_JGC_]

Het enige waar ik als distro maintainer in geinteresseerd ben is de manier waarop het integreert in mijn distributie. Het zal mij een worst wezen dat ik de taal kan aanpassen, maar wat ik wel heel graag zie is een native compilatie met de compiler en libraries die op mijn distributie gebruikt worden, ipv een groot lomp precompiled pakket wat op zoveel mogelijk distributies universeel geinstalleerd moet kunnen worden.

[itsme]

Dit nieuws vraagt om een quote van mij sig op t forum ^^

Saying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.

[Verwijderd]

En heb je het uitgeprobeerd? Want zoiets beweren zonder het zelf te hebben ervaren is natuurlijk wel een beetje dom.

[Verwijderd]

Ik voel het gedonder met Microsoft Java Virtual Machine weer op doemen..

[Verwijderd]

Hmm dit geeft mij nu de mogelijkheid om default argumenten
en operator overloading te implementeren voor java. Dit zijn dingen die C++ wel ondersteunt, maar java niet. Snap niet waarom ze deze dingen vanaf het begin niet in java hebben gezet.

[Verwijderd]

Dezelfde reden waarom er geen multiple subclassing en geen pointers zijn in java.