Sun-manager: 'Gedeeltes broncode Java worden openbaar'

Robert Brewin, co-CTO bij Sun Microsystems, heeft in een interview laten weten dat het bedrijf delen van de Java-broncode stap voor stap vrij wil geven. Hoewel er geen concrete uitspraken worden gedaan, suggereert de topman dat het hier onder andere om de Java Virtual Machine en de Swing GUI-onderdelen gaat. Daarnaast zijn er binnen het bedrijf stemmen te horen die de Virtual Machine, Swing-onderdelen en de Java Runtime Enviroment in een keer willen vrijgeven, aldus Brewin. De reden voor de gecontroleerde uitgifte van de broncode is de grootte ervan: "de code moet eerst zorgvuldig worden nagelopen en onder andere worden opgeschoond om een probleemloze uitgave te kunnen garanderen".

Halverwege mei liet Rich Green, onderdirecteur bij Sun, al doorschemeren dat het vrijgeven van de Java-broncode er wel aan zat te komen, maar gaf hij verder geen enkele tijdschema of strategie. Wel heeft Sun de afgelopen tijd aardig wat softwarepakketten onder een open-sourcelicentie vrijgegeven, waaronder Project Glassfish en Solaris, die nu als OpenSolaris door het leven gaat. Op de JavaOne-conferentie twee maanden geleden trakteerde het bedrijf de open-sourcegemeenschap op het vooruitzicht van de broncode van Java Studio Creator, het NetBeans Enterprise Pack en het Java Message System, die binnen enkele maanden zal worden vrijgegeven.

Reacties (25)

[LosserNL]

Het is goed dat de broncode open wordt, maar ik ben als Java ontwikkelaar wel bang dat er net als met Linux meerdere JVM's en meerdere JRE's komen die elkaar mogelijk niet ondersteunen. Daar heb je nu geen last van omdat alles gecontroleerd wordt. Wie gaat er nu dan de JSR's implementeren en vooral controleren?

[Bbfreak]

I agree. Volgens mij krijgen we een wild groei aan JVM's en daar is niemand mee gezegend
Ik hoop dat ze weten wat ze doen!

[watzie]

No offence maar dat is al zo hoor. Er zijn vele VM implementaties buiten de reference implementatie van Sun (o.a. van IBM en nog een heleboel meer).
Dat is ook helemaal niet erg, want een VM hoeft alleen maar te voldoen aan afspraken. Hoe het geimplementeerd is boeit niet als het gedrag maar voldoet aan de afspraken voor een bepaalde versie van de taal. Zelfde verhaal voor JSP, Servlet, J2EE etc. containers.
Bang zijn voor 'JVM's en meerdere JRE's' die elkaar niet ondersteunen is dus ongegrond. Daar heb je nu geen last van niet omdat alles gecontroleerd wordt maar omdat slechte implementaties het niet overleven. JSR's implementeren blijft net zoals nu de verantwoordelijkheid van de bouwer. Aan 'controlerende' instantie(s)/personen veranderd verder toch niks 'omdat Sun iets opensource gaat maken' of wel?

[killercow]

Dat lijkt mij sterk,

Java is een standaart, en elke client die java claimt te kunnen lezen zal hier dus aan moeten voldoen.

Ms heeft al eens een eigen implementatie geschreven die bewust brak was. (en heeft daar sun 300 miljoen dollar "boete" voor betaal als schikking)

Voor de rest zijn er al lang andere jvm's (bijvoorbeeld blackdown), maar deze zijn helaas nog niet helemaal 100% correct doordat het allemaal bijzonder veel werk is.

Nu de source open is, kunnen dat soort projecten ook gemakkelijker 100% standaart compliant worden.


(als in, het zijn geen browser!, MS mag volgens mij namenlijk geen JVM meer bouwen volgens de schikking, en dus zitten we betrekkelijk veilig)

[J.J.J. Bokma]

"Each version of Jikes represents our best effort at the proper interpretation of the language specification. Although Jikes is designed to work with all but the earliest versions of the JDK, we make no claim that any particular version supports precisely the same language as any particular version of the JDK. Since some products are designed to work with specific versions of the JDK, the compilers associated with them may not always recognize the same programs as Jikes."
http://jikes.sourceforge....er-index.shtml#compatible

Zelfs als er een standaart [sic] is, wil dat nog niet zeggen dat elk product dat volgens zeggen die standaard volgt ook precies hetzelfde werkt. Ook standaarden hebben vage punten.

[Verwijderd]

Dat heb je nu ook al nml:
- sun java
- ibm java
- blackdown java
(die van ms reken ik hier even niet mee )

Het is wel belangrijk dat de partijen de specificaties op de letter uitvoeren en er een goede referentie implementatie is. Kijk hierbij bvb naar het J2EE traject voor nieuwe ontwikkelingen.

[Terracotta]

Dat wordt dan ook als reden aangehaald dat het tot nu toe nog niet open source is, de licentie zal dan ook geen GPL zijn, maar ik denk dat als er standaardspecificaties voor zijn dat het geen probleem is moest er een wildgroei komen. Zolang de spelers zich aan de standaarden houden, en de spelers opensource moeten zijn kan er geen MS langskomen om ff dezelfde trucs uit te halen als ze met html hebben gedaan. Plus het gesloten karakter zorgt er ook voor dat sommige distributies het niet meeleveren, en dat het op sommige platformen/browsers niet werkt. Een bedrijf zelf kan nooit alle platformen ondersteunen als iets gesloten is. De platformen daarentegen kunnen wel de voornaamste features installeren als iets open is, zodat de productdevelopers zich daar niet mee moeten bezig houden (als ze een beetje deftig kunnen programmeren tenminste).

[zordaz]

Forking *kan* ontstaan als een produkt open source wordt. Maar inderdaad zijn er nu ook al allerlei smaken Java. Daarnaast hangt het ook sterk samen met de licentie waaronder de code wordt vrijgegeven en daarover is nog weinig duidelijk.

Forking hoeft trouwens helemaal niet verkeerd te zijn, want vaak voorziet het in een behoefte (kijk bijv. naar x.org). Ook zijn er genoeg projecten waar forking helemaal geen issue is of niet / nauwelijks voorkomt (mysql, samba etc.).

Ik maak me geen zorgen, ik vind het op dit moment echt geen issue.

[Verwijderd]

Inderdaad, zo was de angst voor forking een van de redenen waarom TrollTech terughoudend was in het uitbrengen van Qt onder een opensource-licentie. Uiteindelijk hebben ze het toch gedaan, en tot op heden is er geen fork van Qt gemaakt.

[YaPP]

forking van een open source project onstaat pas als er iets niet goed loopt in het project. Hoe krijgt een eigenwijze ontwikkelaar anders een hele community aan mensen en support overstag voor zijn fork? is dit er niet, zal de fork een snelle stille dood hebben.

de GNOME desktop is bijvoorbeeld geforked.. hebben we daar ooit echt iets van gezien?

[killercow]

Yeah!

Dit is dus een dag om feest te vieren.

Een open source Java virtual machine zal voor iedereen erg goed zijn, en ook de open source swing kan alleen maar voor goede ontwikkeleingen zorgen.

De jvm kan sneller en sneller gemaakt worden, en ook beveiligings bugs kunnen gevonden en opgelost worden door de open source community.

Swing zal misschien eindelijk eens aangepast kunnen worden zodat het er Native uit ziet, dus gebruik maken van GTK,QT of Cacao.

Verder staat niets linux distro's nog in de weg om de jvm standaard correct mee te leveren.

Ook het laatste negatieve puntje omtrent Openoffice (dat grote delen in een gesloten taal geschreven zijn) is zo dus opgelost.!

Opensource FTW!

[Verwijderd]

Grotendeels ben ik het met je eens, alleen wat betreft de bugs moet ik je er op wijzen dat je die al een tijdje zelf kunt oplossen want alle code is al lang beschikbaar (alleen niet "open/free") en sinds de laatste versies kun je zelfs patches opsturen naar Sun. De Sun-developers moeten zelfs voorrang geven aan patches die worden opgestuurd door mensen buiten Sun.

[The - DDD]

Euh, wat je nu beschrijft heeft met de API te maken en niet met de VM.

In verhouding is de VM het kleinste onderdeel van de hele Java stack. De API, daar zit jaren arbeid in. Alles wat je beschrijft is eigenlijk allemaal API gerelateerd.

[DLGandalf]

Swing zal misschien eindelijk eens aangepast kunnen worden zodat het er Native uit ziet, dus gebruik maken van GTK,QT of Cacao.

uhmm wat ze dus eerst hadden met de AWT klassen in windows omgeving (via de windows api dus), maar daar kwam juíst Swing voor in de plaats zoek zelf de motivatie maar op via google

[Little Penguin]

Vooral het vrijgeven van de source van de JVM zelf zou Java wel eens heel erg ten goede kunnen komen. Op die manier is het namelijk mogelijk (mits de juiste OS licantie word gebruikt) om de JVM te porten naar excentriekere platformen...

(Zoals bijvoorbeeld OpenBSD/NetBSD of BeOS of ...)

[The - DDD]

Ik denk eerder omgekeerd. Goede opensource Java VM's zijn er al lang. Maar de hele standaard API eromheen, daar zit het echte werk in. Je kan de API code nu al wel gewoon inzien, maar je mag het niet aanpassen, herdistribueren of wat dan ook. Enkel herdistributie in de vorm van Sun's eigen installer/RPM/package is toegestaan.

Moet je nagaan wat het betekent als je als opensource VM bouwer gewoon de standaard API implementatie mag hergebruiken.

[spone]

Waar staat dat de Java Virtual Machine/Swing open-source wordt? Wat er in dit nieuwsbericht staat is dat bepaalde gedeeltes van de broncode van de JVM/Swing openbaar gemaakt worden. In mijn beleving betekent dat, dat er vrije inzage in de code is, maar waar staat dan dat het ook daadwerkelijk open source wordt?

[Snake]

Ik begrijp eigelijk niet wat voor 'zin' het heeft de broncode vrij te geven?

[Verwijderd]

Open source is de norm aan het worden. Bij het bepalen van de toekomstvastheid van een pakket, is het tegenwoordig een pre als blijkt dat het pakket open source is.

Dat dwingt Sun uiteindelijk tot een strategiewijzing: maak het de standaard, geef het vrij. De concurrentie is moordend. Als Sun het niet vrijgeeft, loopt het de kans dat Java aan relevantie verliest, en daarmee Sun zelf.

(Aan de andere kant, Java is het nieuwe COBOL. In grote bedrijven zal het nog decennia lang te vinden zijn, wat er ook gebeurt.)

[mjtdevries]

En is een pakket dan daadwerkelijker toekomstvaster als het open source is?

Ik durf te beweren van niet.
Open sources versies van software worden echt niet langer ondersteunt dan closed source versies. Met name de laatste tijd blijkt dat heel duidelijk.

[tommy320]

In het geval van Sun lijkt me dat niet opgaan, Sun verkeert in behoorlijke financieele problemen. Voor Java zou het zeer slecht zijn als Sun niet langer kan betalen voor de ontwikkeling ervan.

[Verwijderd]

> En is een pakket dan daadwerkelijker toekomstvaster als het open source is?

Dat hoeft natuurlijk niet, maar er is wel een kentering te bespeuren in het beeld dat men van open source heeft. Voorheen was open source niet te vertrouwen, en dat beeld is duidelijk bijgesteld.

Natuurlijk zal niet ieder sourceforgeproject direct in aanmerking komen, maar als het een onderdeel is van een gerenommeerde organisatie, zoals de Apache Foundation of de Eclipse Foundation, dan biedt dat zeker wel vertrouwen voor de toekomstvastheid. Meer dan bijvoorbeeld een proprietary oplossing van een partij die geen marktleider is.

Een simpel voorbeeld: kies een Ajax-toolkit. Ga je voor Backbase, closed source, prima ondersteuning maar al met al een kleine partij, of kies je voor Dojo, open source maar op de achtergrond gesteund door het Open Ajax Initiative, waarachter onder meer IBM schuilt? Misschien is het voor Dojo nog net iets te vroeg, maar dat het een mooie toekomst heeft lijkt zeker.

En uiteindelijk zal OpenSolaris Sun wel goed bevallen, denk je niet?

[YaPP]

En is een pakket dan daadwerkelijker toekomstvaster als het open source is?

Doordat het Open Source is ben je niet meer afhankelijk van 1 support partij. Mocht die interesse in het product verliezen of om een andere reden de boel verlaten of rare dingen gaan eisen, kunnen anderen de support overnemen.

Mocht je geld hebben, kun je zelf zelfs hierin investeren. Dit argument lijkt steeds meer te gaan leven, dat je bij Open Source meer vangnetten hebt, ofwel meer toekomstvast maakt.

[Verwijderd]

Misschien heeft Sun geleerd van de MS affaire...
Ze verkleinen ze natuurlijk ook kansen op boetes door de Europese Commissie enzo vanwege geheime broncodes enzo.

[killercow]

Zijn ze monopolist dan?
En misbruiken ze hun monopolie?