Sun gaat met IBM in gesprek over open source Java

Enkele weken nadat Eric S. Raymond pleitte voor het open-source maken van Java, opent ook IBM de discussie over dit onderwerp. In een open brief aan Sun stelt het bedrijf voor om samen te werken aan een vrije implementatie, zo meldt eWeek. Op dit moment is de broncode wel beschikbaar, maar onder een licentie die ervoor zorgt dat Sun's versie van Java niet als vrije software beschouwd kan worden. Hoewel Sun het standpunt inneemt dat het door de code onder deze licentie beschikbaar te stellen genoeg vrijheid biedt, heeft het bedrijf toegezegd op korte termijn met IBM aan tafel te gaan zitten. De voorzitter van een vereniging van Java-ontwikkelaars ziet drie voordelen in het voorstel van IBM:

"One, if an independent, certifiably compatible implementation of the Java core libraries is available, then third parties can focus on competitive performance enhancements in the VM [virtual machine]," Ross said. "Two, the barriers to Java being distributed as part of standard Linux distributions would be lowered. And three, Sun competitors who are presently unwilling to invest in the Java platform would finally be able to view Java as a platform that is independent of Sun, rather than as Sun's tool."

Reacties (20)

[whitebunny]

Naast de voordelen die Open Source ongetwijfeld zal bieden, moet m.i. echter ook niet onderschat worden hoezeer de commitment en strakke controle van Sun tot nu toe in het voordeel van Java heeft gewerkt.

Ik ontwikkel al sinds versie 1.02 met Java, en ik moet zeggen dat ik sindsdien erg onder de indruk ben van de continue inzet, prestaties en het beleid van Sun m.b.t. de ontwikkeling en verbetering van Java; ik heb geen enkel moment de indruk gehad dat Java beter af zou zijn als Sun het niet zo strak in de hand had gehouden.

Denk alleen maar aan het feit dat Sun in staat is geweest om Microsoft's poging een "eigen" Java-variant te introduceren, te blokkeren, waarmee is voorkomen dat er verschillende, incompatible versies van Java zouden ontstaan. Helaas is dit ook een sterke klap geweest voor Java op de desktop die tot op vandaag nog doorwerkt, maar ik denk toch dat Sun hier een juiste keuze heeft gemaakt.

Ook de snelheid waarmee de afgelopen tijd nieuwe versies van Java zijn uitgebracht, was waarschijnlijk onhaalbaar geweest als de beslissingen daarover door een hele groep van betrokken bedrijven en individuen hadden moeten worden genomen, met elk hun eigen (meestal commercieele) belangen en bedoelingen.

Dankzij Sun is Java in een tamelijk korte periode volwassen geworden, en dankzij het JCP (Java Community Process) is er toch de nodige speelruimte voor andere bedrijven (bedenk dat dit vaak direkte concurrenten van Sun zijn!) en geinteresseerden gekomen, en zijn er nu al enorm veel ontwikkelaars van buiten Sun projectmatig bezig met interessante verdere ontwikkelingen aan Java (kijk bijvoorbeeld maar eens naar de nieuwe features die in de 1.5 release "Tiger" gaan komen).

Open Source en concurrentie tussen verschillende VM's komt mogelijk de performance en kwaliteit ten goede, maar het risico wordt ook groter dat er incompatibiliteiten gaan komen, of de ontwikkelingen van de taal uiteindelijk langzamer zullen gaan vanwege het moeizamere beslissingstraject.

Ik ben benieuwd wat deze gesprekken gaan opleveren. Feit is, dat IBM meer ontwikkelaars op Java heeft zitten dan Sun zelf, dus een grotere rol voor Big Blue is wellicht op zijn plaats, maar open source is volgens mij voor Sun nog een stap te ver. Maar we zullen zien...

[Verwijderd]

volgens mij is het niet zo dat op het moment dat Sun Java onder de GPL gaat verspreiden, ze alle controle kwijtraken. Zij zitten nog steeds in de 'driver seat' als het gaat om releases van versies, maar GPL geeft anderen de vrijheid om ten eerste verbeteringen aan te brengen en bugs te verwijderen en ten tweede om het bijvoorbeeld in Linux/ of *BSD distributies te stoppen.
De linux kernel is ook nog steeds onder streng toezicht van een handjevol ontwikkelaars, met Linus Torvalds aan de leiding.

[Little Penguin]

Wildgroei van verschillende Java VM's kan voorkomen worden door een instantie (dat kan Sun zelf zijn of een onafhankelijke stichting) te laten controleren of men aan de voorwaarden voldoet om het product Java versie x te mogen noemen.

Deze Java standaard moet dan door een onafhankelijk institiuut worden vastgesteld, zodat er geen sprake is van het opleggen van eisen door Sun. Dit kan door een bestaand instituut, zoals ANSI of ECMA gedaan worden of door een stichting waar o.a. Sun, IBM en andere Java fabrikanten/gebruikers zitting in hebben.

Als er een standaard is en een controle op deze standaard als men het Java logo en de naam 'Java' wil gebruiken, dan hoeft een product niet per difinitie onder een sterk copyleft (GPL) uitgebracht te worden, maar kan men ook kiezen voor een minder sterke copyleft licentie. Mogelijkheden zijn dan BSD-licentie, Mozilla Public License, Apache-Style license of een combinatie van bijvoorbeeld de MPL en de GPL (dual license).

Overigens moeten we wel bedenken dat Sun hiermee een hoeveelheid geld weggeeft, men heeft namelijk veel tijd en geld gestopt in de ontwikkeling van Java. Maar wellicht dat ze zelf ook wel inzien dat open source mogelijk voordelen biedt, zoals blijkt uit o.a. Mozilla, Linux, NetBSD (*BSD...) en GNU.

[Verwijderd]

Is het mogelijk om vrije software te maken zonder dat iemand patent erop aan kan vragen?

anders komt straks MS misschien weer die iets patenteert omdat ze weer iets nieuws voor Java hebben uitgevonden en dan is het in principe weer geen vrije software

[Verwijderd]

Het voorstel was om dit juist te voorkomen door java te verspreiden onder de bekende GPL. Deze stelt dat het product dat gebruik maakt van iets dat onder de GPL valt ook open source moet zijn. En microsoft gaat echt geen open source software maken.

[jb044]

Wat een gelul zeg, als dat zo was Linux en andere OSS commercieel gezien volstrekt kansloos.

Als wat jij zegt klopt moet je een boek geschreven in zeg KOffice onder de GPL uitbrengen!! De GPL zegt iets heel anders: je mag opensource niet omzetten in closed source. Dus tenzij je GPL source in een of andere vorm gebruikt of aanpast zit je helemaal niet vast aan de GPL.

Zo moe wordt je ervan de GPL beschermd slechts de opensource software zelf, het door Microsoft benoemde opensource 'cancer' bestaat helemaal niet!

Kortom een opensource java sluit closed source toevoegingen helemaal niet uit.

[Verwijderd]

Patenten staan compleet los van al dan niet opensource ontwikkeld is. De enige probleem bij free software wat betreft patenten zijn de volgende:
- Het is niet zo duidelijk wie men moet aanklagen als een patent geschonden wordt, omdat er geen echte eigenaar van de software is, dit is toch meestal zo. Het enige wat men eventueel kan doen is de software laten verbieden.
- Als er effectief een schending van de patenten is kan men zich niet zo makkelijk vrij kopen. Een commercieel bedrijf dat een gepatenteerde techniek 'steelt' kan gewoon licenties kopen omdat ze weten hoeveel kopies er zijn. Omdat free software gekopieerd mag worden zonder iemand daarvan op de hoogte te brengen zou men zelfs niet kunnen een symbolische cent per kopie geven. Het enige wat men eventueel zou kunnen doen is het patent overkopen en dan `vrijgeven'.

Maar zowiezo neem je geen patent op Java, maar op iets dat in Java gebruikt wordt of dat je met Java kunt doen. In beide gevallen maakt het dan niet uit of Java nu free/open is of niet. Het probleem blijft net hetzelfde, alleen is het niet meer duidelijk wie er nu verantwoordelijk voor is.

[himlims_]

van de ene kant is 't goed nieuws (zie o.a. de reacties hierboven)
echter verwacht ik wel een probleem wat zich nu al een beetje voordoet; sun java, microsoftjava, en straks ook ibm java, buurman java, europa java ... ik bedoel hiermee aan te geven dat de consument straks de bomen door 't bos niet meer ziet.
want welke java MOET ik nu hebben?

[YaPP]

sun java, microsoftjava, en straks ook ibm java, buurman java, europa java ... ik bedoel hiermee aan te geven dat de consument straks de bomen door 't bos niet meer ziet.
want welke java MOET ik nu hebben?

Als SUN zijn deel vrijgeeft, kan iedereen op ieder OS zonder beperkingen Sun-java gebruiken dat is nu niet het geval, en door de koppige houding van Sun hebben een aantal fabrikanten (IBM/Microsoft) zelf een JVM in elkaar gezet, aangezien ze met SUN niet om de tafel konden zitten.

* Wildgroei vind in OSS-land pas plaats als een groep een compleet andere doelstelling heeft dan de auteur/projectgroep die het product ontwikkeld. Pas dan vind er een 'fork' plaats, zodat het product dus weer wordt doorontwikkeld. Koppige projectteams houden vaak juist de verdere ontwikkeling tegen van een product. (een fork help dan juist)
* Verschilldende linux distro's zijn er omdat verschillende mensen verschillende meningen hebben. (en doelgroepen)
* Van de linux kernel zelf zijn er geen echte forks in het wild, omdat iedereen Linus Torvalds ook waardeerd om de manier waarop hij het linux-kernel-project beheerst.

m.a.w. Niet OpenSource, maar de verschillende doelstellingen/of koppigheid van projectteams leid tot wildgroei van versies.

Als SUN zijn werk goed doet, zal iedereen met SUN om de tafel kunnen zitten met nieuwe voorstellen en is er maar 1 java: sun-java.

[Verwijderd]

Two, the barriers to Java being distributed as part of standard Linux distributions would be lowered

Ik denk dat dat de populariteit van Java wel eens behoorlijk ten goede kan komen. Er is dan niets meer dat linuxgebruikers tegenhoud om een java-programma te gebruiken. Je hoeft er niet eerst eea (de VM) voor te installeren zoals nu het geval is.

Een vergroting van het gebruikersgemak dus.

[klakkie.57th]

Maar het loopt nog steeds voor geen meter.

Java is en blijft gewoon traag.
Tenzij iemand ervoor zorgt dat er eindelijk is een VM komt, die maar 1% snelheidsverlies met zich meebrengt kan het mij voor geen meter boeien.

[roelio]

Onderbouw dat soort opmerkingen eens een keer, dat Java traag is, is soms waar en soms niet waar

[Verwijderd]

De eerste versies van Java waren inderdaad nogal traag vergeleken met andere talen.
Dat is echter ALLANG niet meer het geval en het wordt dan ook hoog tijd dat dit fabeltje niet eeuwig rondgebazuind blijft worden.

De JIT-compilers, geheugenmanagement- en garbage-collection strategieen zijn echt ontzettend verbeterd en Java-code performed gemiddeld genomen echt niet slechter dan C++ of wat voor taal dan ook. Het is zelfs zo, dat Java-code tegenwoordig vaak SNELLER is dan bv C++, Delphi of VB-code.

Dit komt niet alleen door de hierboven genoemde technische ontwikkelingen, maar ook door de voortgaande optimalisatie van veelgebruikte interne objects (bv collections), xml-parsers, specifieke IO-afhandeling, multi-threading, etc.

Daarnaast wordt vaak vergeten dat JIT-compilers weliswaar een extra laag vormen en daardoor in principe iets extra tijd (kunnen) kosten, maar dat de JIT-compiler uiteindelijk on-the-fly gecompileerde code genereert die SNELLER kan zijn dan gewone compiler-code: juist OMDAT de JIT-compiler pas compileert tijdens het runnen en niet vooraf, "weet" de JIT-compiler vaak meer dan de gewone compiler.

Bijvoorbeeld:
Van veel variabelen waar een vooraf-compiler niet weet wat voor waarden ze gaan bevatten, heeft de JIT-compiler al WEL een runtime waarde beschikbaar en kan die kennis dus gebruiken om de gecompileerde code daarvoor te optimaliseren; hetgeen dus SNELLERE code oplevert dan een vooraf-compilatie ooit zou kunnen genereren.
Daarnaast weet de JIT-compiler precies op welke processor er wordt gedraaid, dus kunnen er processor-specifieke optimalisaties worden gebruikt, en ook is de hoeveelheid beschikbaar geheugen bekend en ook daar kan rekening mee worden gehouden. En zo zijn er nog vele voordelen van een JIT-compiler t.o.v. een gewone compiler.

Daarnaast is de extra laag die Java vormt tussen OS en applicatie, in een flink aantal gevallen geen vertragende factor, maar werkt het juist versnellend omdat een aantal zaken sneller intern kunnen worden afgehandeld dan door het OS.

[Verwijderd]

Dat wil ik graag onderbouwen ja. Java is traag door de manier waarop het werkt. Het is namelijk zo, dat Java over de hardware van jou (en andere) computers een schil bouwt. Hierdoor is de hardware van alle computers voor het Java-programma hetzelfde.

Het grote voordeel hiervan is, is dat java vrij onafhankelijk wordt van de onderliggende architectuur. Op alle systemen waarvoor zo'n schil bestaat (en die schil is dus de virtual machine), draait alle java-code. Java code is dus, als het eenmaal is geschreven, overdraagbaar op veel andere architecturen (portable).

Maar, er is ook een groot nadeel. Omdat er om de eigenlijke hardware een schil ligt, moeten Java instructies door die schil vertaald worden naar de hardware spifieke instructies. Dit vertalen kost tijd. Hierdoor is java niet in alle gevallen de ideale taal.

[klakkie.57th]

Hoe moet ik dit nu onderbouwen.
Gewoon eigen ervaring, nog nooit een applicatie tegengekomen die sneller draait onder java dan onder bv. assembler of zelfs c en c++.
Java is gewoon een "truukje" om je code niet te vaak hoeven te compileren, is dus eigenlijk uitgevonden door/voor luie programmeurs.
Ik zie het echte nut er niet van in.
hercompileer je programma gewoon ipv iets universeels te willen maken.
Java wordt toch meestal als front-end gebruikt, kan je netzo goed allemaal verschillende front-ends maken.

[iKiddo]

Maar, er is ook een groot nadeel. Omdat er om de eigenlijke hardware een schil ligt, moeten Java instructies door die schil vertaald worden naar de hardware spifieke instructies. Dit vertalen kost tijd. Hierdoor is java niet in alle gevallen de ideale taal.

Je kan ook de hardware-specifiek gecompileerde bestanden verspreiden, dan is het net zo snel als c, c++ en de rest.
Dat je Java realtime kan omzetten m.b.v. een VM betekent niet dat je het niet van tevoren kan compileren.
En dan heb je ook nog JIT, wat een mengsel van de twee is en qua performance dus ook ergens in het midden zit.

[.oisyn]

Het is zelfs zo, dat Java-code tegenwoordig vaak SNELLER is dan bv C++, Delphi of VB-code.

hahaha, sorry hoor, maar Java zal nooit kunnen tippen aan een goed geoptimaliseerde C/C++ of Delphi applicatie, dit komt niet alleen door de VM (die je weg zou kunnen werken door het bijv. te compileren), maar door het feit dat je bijvoorbeeld geen objecten aan kunt maken op de stack, of dat array indices altijd gecontroleerd moeten worden.

Je hebt gelijk dat Java niet meer zo traag was als het ooit geweest was, maar je moet geen onzin gaan zitten verkondigen dat het soms zelfs sneller is dan C++ (voor zover je die vergelijking kunt trekken, ik kan idd een java applicatie sneller maken dan een C++ applicatie, maar dan heb ik voor die C++ applicatie iig niet mijn best gedaan ).

Wat java ook niet heeft is deterministic finalization, je kunt dus nooit voorspellen wanneer iets opgeruimd kan worden. Dit wordt vaak als "truucje" gebruikt in bewijzen om aan te geven dat java sneller is, maar eigenlijk is dat helemaal niet eerlijk: je kunt dat in C++ ook wel inbouwen, en bovendien zal iets toch ooit opgeruimd moeten worden, of je dat nu meteen doet of pas nadat je applicatie voor een aantal uur heeft gedraaid (zou ook wat zijn als de performance ineens enorm dropt omdat er niet genoeg geheugen meer vrij is waardoor de GC ineens enorm aan het werk moet).

If there's no garbage in a language there's no need to collect it

[Verwijderd]

Je hoeft de VM echt maar 1 keer te installeren. Net zoals je de shockwave flash plugin ook moet installeren om flashmovies te kunnen zien.

[Verwijderd]

Dat is zeker goed nieuws.
En IBM ontwikkeld zoveel voor Java dat ze serieus genoeg zijn om in gesprek mee te gaan.

En als je ziet hoeveel open-source java programma's er zijn is het eigenlijk verwonderlijk dat de taal zelf niet open-source is maar van Sun.

[Verwijderd]

Het beste artikel wat ik hierover gelezen heb wordt niet genoemd:
http://linuxtoday.com/news_story.php3?ltsn=2004-02-24-023-26-OP-CY-DV

We are not going to ask Sun to do something for Open Source (at least, not directly). We will show Sun how they can help themselves by making Java even more widespread than it is, and by harvesting it commercially. We will also show that if they continue to do nothing, they will pay a heavy price.