Open Source Initiative: code van Java moet openbaar

Een dag nadat Scott McNealy, CEO van Sun Microsystems, had laten weten dat hij de open source-community beschouwde als een vriend van zijn bedrijf, heeft Eric S. Raymond, president van het Open Source Initiative, Sun opgeroepen de broncode van Java openbaar te maken. Volgens Raymond moet Sun een keuze gaan maken tussen controleerbaarheid van de broncode en een zo snel mogelijke verspreiding van de software. De open source-voorvechter meent dat de controledrang van Sun op de broncode de belangen van het softwarebedrijf op de lange termijn schaadt. Dit wordt enerzijds veroorzaakt door de restrictieve bepalingen die Sun aan ontwikkelaars en verspreiders van software oplegt en anderzijds doordat andere programmeertalen, zoals Python en Perl, in de toekomst meer invloed zullen krijgen als Java gesloten blijft. Raymond's opmerkingen zijn een reactie op een speech van McNealy van afgelopen woensdag. In deze toespraak had de CEO van Sun laten weten het open source-model als een vriend te zien.

Sun liet in een reactie aan Eric S. Raymond weten dat het bedrijf naar eigen zeggen de juiste balans heeft gevonden tussen de controle op de Java-broncode en het risico dat andere bedrijven de software zouden kunnen ondermijnen. Er is een middenweg mogelijk tussen enerzijds de optie om zoveel mogelijk mensen aan Java mee te laten werken en anderzijds de mogelijkheid dat Sun volledige controle houdt over de broncode, zo liet een woordvoerder van Sun afgelopen vrijdag weten. Een van deze middenwegen is het Java Community Process, een structuur waarin enkele grote bedrijven, zoals IBM en Motorola, hun zegje kunnen doen over de features van Java in de toekomst. Analist Shawn Willett, werkzaam bij Current Analysis, heeft in een reactie laten weten dat Java anders is dan open source-software. Hij geeft echter wel aan dat Sun goed naar signalen uit de open source-markt zou moeten luisteren om daar marktaandeel te winnen.

Reacties (33)

[himlims_]

dit vind ik een hele mooie ontwikkeling
aangezien java zo goed als platform onafhankelijk is, zijn de mogelijkheden erg groot. en hoeven ontwikkelaars niet (al te veel) moeite te doen om een programma op zowel linux mac windows etc. te draaien
en wanneer dit als OS toegankelijk is denk ik dat dit wel eens een grote sprong voorwaards kan betekenen. denk bijv. aan het Java Desktop pakket van sun

[zwippie]

Java als OS is m.i. niet aan de orde; het zou veel te langzaam zijn. Misschien als het OS op een speciale java-chip zou draaien, maar dan nog.

Een gecompliceerde taal/verzameling technologieen als Java heeft iig geen baat bij wildgroei van verschillende implementaties die onderling incompatible zijn; zie bv het MS Java VM verhaal.

Ook al zouden meer mensen inzage krijgen in de broncode, het lijkt mij in het belang van de ontwikkeling van Java dat er 1 instantie (Sun in dit geval) de toon blijft zetten. Zolang ze dit goed doen en goed luisteren naar andere developers kan de huidige aanpak heel succesvol blijven.

Sowieso vind ik Java al best een goed gedocumenteerde (semi-)open standaard.

[BM]

Ik denk dat in deze context met OS, Open Source bedoelt wordt, en geen Operating System

[himlims_]

idd ... beetje verwarrend hoor al die afkoringen

[Verwijderd]

Ik wist het ....

Windows is geen OS

[Verwijderd]

Je kunt met C++ en wxwindows (www.wxwindows.org) gewoon multiplatform oplossingen aanbieden. Dus 1 broncode wat compileert naar Windows, Linux en Apple.

Java is leuk voor Internet applicaties, maar voor standalone is C++ gewoon beter.

[Verwijderd]

Java is leuk voor Internet applicaties, maar voor standalone is C++ gewoon beter.

Dan zitten al die banken, verzekeringsmaatschappijen e.d. er zeker flink naast met hun J2EE gebaseerde omgevingen.

De vergelijking tussen een cross-platform library met een volledige omgeving als java slaat de plank volkomen mis. Sterker nog: ik weet wel zeker dat een groot zakelijk project beter in java dan in C++ met wat niet-gestandaardiseerde libs gedaan kan worden.

[Skinkie]

Dat klopt ook wel, als je bijvoorbeeld naar een LogicaCMG gaat en je vraagt om een applicatie zeggen ze recht in je gezicht dat een java applicatie makkelijker te maken is en dat het goedkoper is om een snellere machine in te zetten dan een langzame machine met applicatie in C of C++.

Persoonlijk walg ik van dit soort dingen, ik zou zelf voor een goedkope en milieuvriendelijke (!) applicatie gaan. Als een reken engine werkt op een 486 of pentium 1 waarom dan een XEON inzetten omdat er een virtual machine omheen moet zitten?
486 is natuurlijk weer extreem vanwege spare parts, maar het punt kan begrepen worden.

Dit geld overigens voor meer zaken als webservers, als bij het schrijven van een website echt wordt geoptimaliseerd voor processortijd en bandbreedte hoef je niet op tig webservers te draaien... ok tis al laat

[Verwijderd]

"k weet wel zeker dat een groot zakelijk project beter in java dan in C++ met wat niet-gestandaardiseerde libs gedaan kan worden."

Ga je nog vertellen waarom?

Java applicaties zijn traag en iedere gebruiker heeft zijn eigen vitual machine.

[Janoz]

Java is al lang niet meer alleen die applets van vroeger hoor.

Jij vraagt je daadwerkelijk af waarom een groot zakelijk project liever in java wordt gedaan dan in 1 of ander non standaard lib icm c++? Misschien ondersteuning of continuiteit?

Kijk voor de gein eens waar de meeste bugs vandaan komen? Veel wordt veroorzaakt door memory managment en buffer overflows. Dit zijn dingen die bij java niet voorkomen door het memory managment. Bij consumentenprodukten kun je die extra debug en patch tijd nog wel terug verdienen door het vaak genoeg verkopen van je applicatie (of gewoon een nieuwe versie uitbrengen), maar als je over maatwerk praat dan wordt dat onbetaalbaar.

Mij 2 weken code laten optimaliseren of bugs laten fixen is net zo duur als een goede pro webserver.

Verder hoeft een tussenliggende virtuele machine niet per definitie te zorgen voor vertraging. Het 'java is traag' sprookje wordt veroorzaakt door de vroegere awt. Omdat het overal moet werken werd al het GUI gebeuren door java zelf getekend. Er werd dus geen gebruik gemaakt van de locaal aanwezige widgets. Dat is nu eenmaal wat trager. Een console applicatie (wat een server of webapp eigenlijk is) verschilt kwa snelheid nauwelijks met andere mogenlijkheden.

Het is wel redelijk tekenend dat MS voor zijn .NET de opbouw en structuur van het java platform overgenomen heeft ..

[reinouts]

Java applicaties zijn traag

Alle recente benchmarks laten zien dat Java-progjes met een recente JRE zeker zo snel zijn als C++ zo niet sneller.

en iedere gebruiker heeft zijn eigen vitual machine.

Je hebt het misschien over een remote server waarop meerdere gebruikers tegelijkertijd java-programma's draaien? Er zijn genoeg andere setups te bedenken hoor. En dan nog, wat is er mis met aparte VM's voor aparte gebruikers? Voorkomt vast een boel security-problematiek.

[Verwijderd]

Toon mij deze benchmarks.

[Verwijderd]

Misschien krijgen we dan ook de mogelijkheid om fatsoenlijk een seriele poort aan te spreken onder linux/freebsd. Maar er zal wel 1 "java" moeten blijven, niet allerlei ranzige dialecten. Ik heb alleen het vermoeden dat dat wel los zal lopen als ze zouden besluiten om het echt open source te maken.

[Verwijderd]

Als zij Java standaardiseren voorkom je dat probleem van het hebben van dialecten, maar standaardisatie kan alleen plaatsvinden als je de code vrijgeeft.

Wat dat betreft houdt Sun zijn eigen innovatie tegen.

[reinouts]

Standaardisatie en broncode openbaar maken zijn echt twee heel verschillende dingen.

Overigens stelt Sun de broncode van Java nu al gratis beschikbaar, alleen niet onder een OpenSource licentie.

[-RenE-]

Beetje misleidend artikel. De broncode van Java is al lang open source. Weliswaar niet als GPL, maar wel vrij toegankelijk. Je hoeft zelfs de wijzigingen die je aanbrengt niet terug te geven.

http://wwws.sun.com/software/communitysource/j2se/java2/index.html

[Verwijderd]

de SDK is open-sourced, niet de JRE. de SDK is de development kit, de JRE is de code die de java virtuel machine implementeert.
Sun Java is dus niet open-source.

[RvdH]

http://java.sun.com/j2se/1.4.2/scsl/build-linux.html

Hier staan buildinstructies voor de JVM, die dus als source bij de SDK zit.

[Verwijderd]

Het gaat hier om de impelentatie van de "standaard classen" niet om de source code van de native bindings met de JVM (de source code van de JVM)

Als zijn de specs daar wel van openbaar

[Belial_666]

De grootste zorg van SUN is echter dat MS er met Java van door gaat en een eigen Java ontwikkeld dat alleen op Windows werkt.

Zoals ze ook met de MS-java VM gedaan hebben

[Beaker]

Dat zal niet meer nodig zijn. Ze hebben zelf al een variant gemaakt -> Microsoft.NET. Dus ik denk niet dat Microsoft nog erg geïnteresseerd is in de source van de JVM e.d.

[Alex]

Microsoft heeft diezelfde software allang via reverse engineering geanalyseerd. Een bedrijf van 150.000+ werknemers heeft echt weel een teampje van 10 man die assemlby kunnen lezen. Dat weet ik zeker. Hiervandaan hebben ze echt wel inzicht gekregen hoe de VM werkt. Het is wel zo dat Microsoft wel graag een eigen VM zou willen schrijven die 100% compitable is met alle .class bestanden maar toch 100% MS is, zodat ze niet afhankelijk zijn van Sun. De JVM van Sun is immers de trojan in het windows systeem
Dat ze dit nu nog niet kunnen komt meer door het feit dat ze met licenties e.d. zitten. Als Java straks van niemand meer is, kunnen ze vrij hun gang gaan...

[martijnvanegdom]

Java en zijn systeem bestaat uit twee lagen in tegenstelling tot andere programmeertalen.

Als je java code en vervolgens compiled dan krijg je .class bestanden. Deze .class bestanden zijn multiplatform. De JavaVirtualMachine is niet multiplatform maar platformspecifiek. De JVM vertaalt .class naar machinetaal die uitvoerbaar is.

Met de broncode openbaar maken wordt in dit geval bedoeld dat de compiler en/of de jvm's opensource worden

[Little Penguin]

Op zich is het een goed idee om de officiele Sun JVM als open source vrij te geven.

Maar het vrijgegeven van de broncode van de JVM (daarmee bedoel ik dat gedeelte van de Java omgeving die de Java byte-code interpreteerd/uitvoerd) komt de portabiliteit van Java alleen maar ten goede.

Men hoeft echter niet per definitie alle classes als open source vrij te geven, omdat die toch al cross-platform zijn, die mogen dus gewoon closed-source blijven en slechts als bytecode verspreid worden.

[Johnny]

Met OpenSource kun je nog even veel controle uitoefenen over de broncode als voorheen, er zijn allerlei modellen mogelijk waarbij Sun het alleenrecht houdt om te verspreiden, maar derden de code kunnen inzien en verbeteringen aan Sun kunnen voorstellen.

[justice strike]

de broncode is opzich makkelijk aan te komen, sun wil alleen niet dat java een ieee standaard wordt. Als java proprierity blijft kan je veel sneller veranderingen in doorbrengen, als het een standaard is moet je heel veel moeite doen om de standaard te veranderen. Ik vind op zich niet dat sun slecht bezig is wat dat betreft.

[DJ Henk]

Ik geloof dat ik het niet helemaal snap. Sinds wanneer heeft een programmeertaal een broncode?

EDIT: Bedankt voor de antwoorden, maar waarom moet nou juist sun dingen gaan vrijgeven? Er zijn toch meerdere compilers en virtual machines voor java? Dit lijkt mij aan te geven dat java niet meer dan een set specificaties voor een programmeertaal is. Kunnen die open source-gasten met die specificaties niet zelf wat in elkaar knutselen?

[VHware]

Hiermee wordt echter de Virtual Machine bedoelt, die heb je nodig om Java-code uit te voeren. bijvoorbeelde de Sun Java Runtime environment.

[pfismvg]

Yep. Alle programeertalen met uitzondering van machinetaal lopen zonder compiler op elke processor

ik denk dat je het inderdaad niet snapt

[Onno]

De source van Java is gewoon openbaar, dus hier is of sprake van een foute interpretatie van wat Raymond gezegd heeft, of Raymond kijkt zelf niet verder dan z'n neus lang is. (ik zet in op het eerste)

Wat hij overigens natuurlijk wil is niet dat de source openbaar is, maar dat de licentie er een wordt die hem aanstaat. Dat is een compleet ander verhaal.

En voor de ongelovigen hierboven: ja, het gaat echt om de complete source; zomaar even een paar bestanden uit de community source download:

hotspot/src/share/vm/gc_implementation/shared/mutableSpace.cpp
hotspot/src/share/vm/gc_implementation/shared/spaceCounters.cpp
hotspot/src/share/vm/gc_interface/collectedHeap.cpp
hotspot/src/share/vm/gc_interface/gcCause.cpp
hotspot/src/share/vm/interpreter/bytecode.cpp
hotspot/src/share/vm/interpreter/bytecodeHistogram.cpp
hotspot/src/share/vm/interpreter/bytecodeStream.cpp

De source van de standaard Java classes zit gewoon bij elke SDK, daar heb je die community source zut niet voor nodig..

[Verwijderd]

niets let de open-source community om zelf een java implementatie te maken. dat dat niet zo moeilijk is heeft microsoft al bewezen.

en van allerhande andere zaken zijn ook open-source projecten, te beginnen met gcc en te eindigen met reactos (een NT4 kloon).

ik vind het eigenlijk nogal tamelijk arrogant van raymond.. maar ja, die gozer is nou eenmaal tamelijk arrogant.

[Skinkie]

Die implementatie is er al

http://gcc.gnu.org/java/

[Verwijderd]

interessant.. misschien niet 100 % compatible maar wel compatible te maken, zie volgende quote.

lijkt me dat sun er wijs aan doet om gewoon duidelijke specs op te stellen, en onderstreept nog maar eens dat raymond niet moet zeuren...

gcj is conceptually closer to a C or C++ compiler than the average java compiler. These procedures often aren't easy to adapt to gcj's view of the world. That's where rhug comes in.rhug is a collection of important open source java packages. The end result is a collection of executables and shared libraries suitable for execution without any supplementary java runtime environment, as well as JAR files and CNI header files

(iets ingekort voor de leesbaarheid)