Sun maakt meer Java-componenten open source

Sun Microsystems heeft vandaag tijdens de JavaOne-conferentie bekendgemaakt bezig te zijn met een verdere toenadering tot de opensourcegemeenschap. Zo heeft Sun aangegeven dat in de komende maanden een aantal Java-applicaties open source gemaakt zal worden. Dit zijn onder meer de broncode van Java Studio Creator, Java System Portal Server, de Business Process Execution Language-engine uit de Java Composite Application Platform Suite, het NetBeans Enterprise Pack, het Java Message System, en tot slot de Web Services Interoperability Technology. Op termijn is het de bedoeling dat alle software die deel is van Java System Portal Server 7 open source zal worden. Verder heeft Sun tijdens de conferentie een nieuwe licentie gepresenteerd voor het Java Platform, Standard Edition 5: de Operating System Distributor's License for Java. Deze licentie geeft distrobouwers de mogelijkheid de Java Development Kit en de Java Runtime Environment mee te leveren.

De broncode van Java zelf blijft echter even gesloten als hij altijd al was. Rich Green, vice-president van de softwaredivisie bij Sun, liet doorschemeren dat de mogelijkheid bestaat dat in de toekomst delen van de Java-taal openbaar gemaakt zullen worden. Sun heeft een paar jaar geleden een verandering ingezet om zichzelf om te vormen naar een 'open-source business model'. Dit houdt bijvoorbeeld in dat steeds meer software open source gemaakt wordt, dat nauw wordt samengewerkt met de verschillende community's en dat geld verdiend wordt met het leveren van support op de gratis beschikbare software. Dit levert Sun geen windeieren op, aldus Green: Solaris is in de vorm van OpenSolaris begonnen aan een tweede jeugd en het aantal abonnementen op Suns Java Enterprise System is de afgelopen twee jaar toegenomen. Ondanks deze successen blijft Sun zoeken naar mogelijkheden om het nieuwe en complexe businessmodel beter te benutten, aldus Green.

Reacties (10)

[Verwijderd]

De broncode van Java zelf blijft echter even gesloten als hij altijd al was.

Zo totaal gesloten als deze zin doet vermoeden is ie nou ook weer niet. De license voldoet niet aan de OS definitie nee, maar de source code van een groot gedeelte van de standaard lib zit gewoon bij de JDK en die van de JVM kun je via een ietwat omslachtige zoek tocht ook gewoon downloaden.

Je kunt de (eventueel) gemodificeerde sourcecode alleen niet verspreiden. Via het mustang project kun je wel code contributies doen (die je hebt gedaan op de source die iedereen dus gewoon kan downloaden), maar omdat die code dan vervalt aan Sun en jij alle rechten kwijtraakt is dit tot op heden niet echt super uitnodigend.

Voorts is het in Java handig dat je de source kunt gebruiken om ombegrijpelijke APIs beter te doorgronden of om er via een debugger door heen te steppen zodat je tot op de detail kunt kijken waarom dat ene randgeval waar de documentatie niets over zegt nu fout gaat.

Hoewel het dus geen officiele open source is, is het dus wel beschikbare source, en dat alleen heeft al heel veel voordelen boven een hermetisch gesloten source als bv win32.

[Standeman]

Met gesloten bedoelen ze ook niet de libraries die je kan downloaden, maar de Virtual Machine die sun meeleverd.

Probleem is dat leverancier van bijv. Linux niet zonder meer een JVM mogen meeleveren.

[Verwijderd]

Met gesloten bedoelen ze ook niet de libraries die je kan downloaden, maar de Virtual Machine die sun meeleverd.

Je zou die zin over gesloten kunnen intepreteren dat er helemaal geen source is om in te zien. Maar feitelijk zijn er 4 hoofd modellen met betrekking tot de source:

1) Je kunt de source vrij downloaden, aanpassen en verspreiden
2) Je kunt de source vrij downloaden
3) Je kunt de source inzien via een NDA of soortgelijke agreement.
4) Je kunt de source niet inzien.

Voor zowel de libraries als de VM die sun meeleverd is de source vrijelijk te downloaden. Voor de source van de VM moet je alleen iets beter zoeken, maar hij is gewoon te downloaden en dan kun je hem eventueel zelfs compilen als je wilt.

[Verwijderd]

En sinds Java 5 is ook echt _alle_ source code beschikbaar waarbij eerst alleen de code voor de publieke API vrijelijk te downloaden was.

En vanaf 6 worden er wekelijkse code-drops gemaakt van de aller-allerlaatste versie waaraan de Sun developers zelf ook werken en wordt het gestimuleerd om patches in te sturen (intern schijnen developers zelfs voorrang te moeten geven aan dat soort patchen boven hun eigen werk!)

Al met al vind ik het helemaal niet slecht wat Sun de laatste tijd doet.


edit: typo

[YaPP]

maar de source code van een groot gedeelte van de standaard lib zit gewoon bij de JDK

De code van de java.* en javax.* packages zijn inderdaad gewoon in te zien. Er is alleen een vervelend detail: deze classes maken gebruik van de sun.* packages. En laat die nu gesloten zijn.. dus je hebt praktisch gezien niets aan de open java.* classes..

De virtual machine is ook gesloten. Dit is geen gezonde basis om Open Source op te ontwikkelen. Een JVM die Open Source is biedt de garantie dat Java altijd beschikbaar zal blijven, ook als Sun ineens geen zin meer heeft. Het is de ontwikkelaars van Open Source applicaties meer hier om te doen, dan dan ze zograag de broncode van alles willen hebben.

Hoewel het dus geen officiele open source is, is het dus wel beschikbare source, en dat alleen heeft al heel veel voordelen boven een hermetisch gesloten source als bv win32.

Van win32 zijn er genoeg voorbeelden in de MSDN library te vinden. Zo hermitisch kan ik win32 ook weer niet noemen..

[Verwijderd]

De code van de java.* en javax.* packages zijn inderdaad gewoon in te zien. Er is alleen een vervelend detail: deze classes maken gebruik van de sun.* packages. En laat die nu gesloten zijn..

Dat is dus waarom ik refereerde naar een gedeelte van. Zelfs zonder die sun packages kun je nog heel veel zien trouwens.

De virtual machine is ook gesloten.

Nee hoor, kun je gewoon de source van downloaden en volgens mij zitten daar ergens ook de sun.* packages bij (weet ik niet zeker, maar die zouden dus ook te downloaden moeten zijn)

Van win32 zijn er genoeg voorbeelden in de MSDN library te vinden. Zo hermitisch kan ik win32 ook weer niet noemen..

Als je dan een MS voorbeeld neemt, pak dan een goede De source van MFC is ook in te zien en komt uiteindelijk ook uit op iets waar je niet de source van hebt. Alleen is Win32 wel bedoeld om direct te gebruiken en zijn de interne sun packages dat niet.

Overigens houdt het close source zijn van MS wel in dat de MSDN documentatie van veel hogere kwaliteit is als de gemiddelde OS docu's, inclusief alle Sun Java dingen. OS mensen laten vaak de documentatie geheel zitten: Use the source luke! Zeggen ze dan.

Bij closed source -moet- je de documentatie wel enigsinds op orde hebben, anders is er helemaal geen beginen aan.

[arjankoole]

OS mensen laten vaak de documentatie geheel zitten

werkelijk? Ik heb dit nooit persoonlijk ondervonden, ondanks dat ik toch al ruim 7 jaar met opensource bezig ben. De documentatie van Opensource projecten is doorgaans erg goed.

Goed, bij sommige projecten is de documentatie duidelijk niet geschreven door iemand die documentatie voor zijn beroep schrijft, maar desalnietemin kan ieder persoon met een fatsoenlijke hersencapaciteit er goed mee uit de voeten IMHO.

[Verwijderd]

Ik maak me wel wat zorgen dat Fedora/RedHat afwezig is uit de lijst met distros die aangekondigt schijnen te hebben dat ze Java-packages gaan leveren.

[kozue]

Redhat zat vroeger ook moeilijk te doen over .net (mono), en die zit sinds FC5 ook gewoon in de Core volgens mij (en anders in extras), aangezien het nodig is voor Beagle en andere handige apps.
Dat zegt overigens nog niks over java, aangezien er voor java al open source VM's zijn. Redhat gebruikt momenteel de JVM van gcc, onder andere voor de java componenten van OpenOffice, en ze hebben ook Azureus in Extras zitten, die daarop zou moeten draaien, alleen krijg ik die niet aan de praat...

[SPee]

Ik vraag me af hoeveel aandelen ze hebben in andere grote java application server fabrikanten (zoals JBoss en Weblogic).

Het is soms best leuk om te zien in hoeverre de standaard componenten geprogrammeerd zijn. Zo zou je dus de standaard JPanel etc. als voorbeeld kunnen gebruiken voor jouw customized panel.

Ik vraag me af in hoeverre het Eclipse team hier gebruik van gaat maken