Apache Foundation gaat eigen Java-implementatie maken

De Apache Foundation die zich bezighoudt met de ontwikkeling van open-source software zal een eigen implementatie van J2SE ontwikkelen waarvan de broncode openbaar zal zijn, zo is bekend geworden. Opvallend is dat dit zal gebeuren met de goedkeuring van Sun zelf. Project Harmony, zoals het project gedoopt werd, heeft tot doel het volledig van nul ontwikkelen van een Java-VM die voldoet aan de J2SE-standaard, inclusief libraries en testsoftware. Sun zelf weigert al jaren in te gaan op het verzoek van de open-source gemeenschap om de broncode van zijn virtual machine vrij te geven, maar lijkt nu dus positief gestemd te zijn als een andere organisatie de ontwikkeling van een eigen openbare implementatie op zich wil nemen. Sun blijft echter zijn vragen stellen bij de noodzaak voor een dergelijk project, maar stelt dat het graag op een of andere manier wil bijdragen aan het project.

Reacties (39)

[Norm2782]

WEER een Java implementatie... -_-'
De hele kracht van Java gaat zo naar de kl*te. Java hoort portable te zijn, dus op elk willekeurig platform te kunnen draaien omdat elke VM t zelfde is (zou moeten zijn). Dat word door al die verschillende Java implementaties onmogelijk gemaakt.

Een voordeel is wel dat ze de broncode vrijgeven. Dan kan de ontwikkeling tenminste ondersteund worden door de OSS community. Zolang maar niet een stelletje enthousiastelingen aan HUN eigen implementatie gaan werken...

[LauPro]

In principe zou elke VM even goed moeten werken. En ik denk dat verschillende VM's bepaalde voor- en nadelen gaan hebben. De ene VM zal snel zijn met relatief veel geheugengebruik, de andere weer andersom. Een andere VM is misschien meer gericht op het snel renderen van de GUI etc. Zo krijg je concurrentie en heb je dus de keus.

[wzzrd]

We zijn het niet altijd eens, LauPro, maar hierin heb je volstrekt gelijk. De post waar je op reageert lijkt overigens verdacht veel op een flamerige post over dit onderwerp op Slashdot.

Het bestaan van verschillende Java-implementaties doet niets af aan de portabiliteit van Java. En deze specifieke implementatie al helemaal niet, want deze gaat voldoen aan de Sun-standaarden en zou dus 100% compatible moeten zijn.

Dit in scherpe tegenstelling tot de VM die Microsoft tot voor kort meeleverde met Windows. Dàt was wel een crippled versie, en die was inderdaad niet compatible op alle vlakken en wat die VM betreft had Norm2782 gelijk gehad. Maar gelukkig wordt die VM tegenwoordig niet meer meegeleverd, dus dat probleem is niet zo groot (meer)

[LauPro]

Ik ben me verder niet bewust van een flamerige post. Over het algemeen zie ik op Slashdot niet al teveel inhoudelijks verschijnen overigens.

[phusg]

Oh en op tweakers is het allemaal flame-free goed doordacht verwijzing doorspekte discussie?!?

[Remus]

Dit gaat om een implementatie van de J2SE specificatie. Als deze dus voldoet (en dat kan gecertificeerd worden), dan draait ieder java programma dat voor de J2SE specificatie is geschreven, op een virtual machine die voldoet aan die specificatie.

[Verwijderd]

Het is juist beter dat er zo veel mogelijk VM implementaties zijn. Je hebt van Application Servers (J2EE, die technisch gezien niet perse op de aanwezige J2SE VM hoeft te bouwen), ook enorm veel aanbiedingen die allemaal J2EE compliant zijn.

Het grotere voordeel van meerdere VMs is dat je een grotere kans hebt dat jouw platform gesupport wordt. Sun zelf wilde eigenlijk alleen maar Solaris/Sparc en Windows versies van de VM maken. Onder grote druk van de communitie is daar later Linux aan toegevoegd, maar daar houdt het wel bij op.

Hoe zit het met BSD? Hoe zit het met Irix? Voor deze platformen is het enorm lastig om een goed werkende VM te krijgen: of hij loopt achter (en met achter lopen zit je dan ook meteen op een tijdspanne van enkele jaren), of hij is redelijk op te date maar zo buggy als ik weet niet wat.

Zeker voor BSD, wat veel in server omgevingen wordt gebruikt, is Java momenteel dus eigenlijk geen optie.

Voorts zit je met het feit dat Java niet vaak in Linux distributies zit (eigenlijk bijna nooit). Java moet altijd met de hand worden geinstalled. Moeilijk is dit niet, maar de beginnende gebruiker heeft echt totaal geen idee hoe dit moet.

Als er een goede opensource VM zou zijn, die gewoon met apt-get uit de standaard repository te installen valt, dan zou dit echt een groot voordeel zijn.

Apache heeft overigens best wel een enorme Java libray: J2EE met Tomcat, JSF met MyFaces, een grote alternatieve/aanvullende class library met Commons en in de toekomst wellicht ook een J2SE implementatie.

[robin1979]

Juist voor dat soort dingen hebben ze een compatibility test suite gemaakt. Dat jouw moederbord niet van IBM is, wil toch niet zeggen dat je er geen IBM-compatible software op kan draaien?

http://www.jcp.org/en/resources/tdk

[MisterData]

Voorzover ik weet heeft Sun wel degelijk regels voor implementaties; implementaties die zich niet aan de standaarden houden mogen gewoon de naam 'Java' niet dragen dan. De MS VM bijvoorbeeld was qua taal wel compliant, maar had gewoon een aantal extra API's die niet aanwezig waren in andere VM's, en dat mag gewoon. Wat Apache gaat doen is alleen de VM maken, de API's zullen wel van GNU Classpath komen ofzo

[Tjeerd]

Sun blijft echter zijn vragen stellen bij de noodzaak voor een dergelijk project, maar stelt dat het graag op een of andere manier wil bijdragen aan het project.

Hun JVM open-source beschikbaar stellen?

[rtgo]

Waarschijnlijk gokt Sun erop dat de opensourceversie in eerste instantie minder goed is dan hun eigen VM. Ze hebben dan dubbele winst: mensen willen nog steeds de VM van Sun hebben en Sun krijgt toch goodwill omdat ze dit open-sourceproject steunen.

[drm]

Ben ik het niet mee eens. Ik denk eerder dat Sun aan Apache wel medewerking wil verlenen, omdat Apache ook aan de weg timmert met bijvoorbeeld Tomcat als Java Server. Gezamenlijk kunnen ze veel beter de strijd aanbinden tegen het opkomende .NET, en aangezien Apache niet snel de commerciele richting op zal gaan, is een stap richting open-source van Sun een min of meer logische.

Verder is Apache vooral op webdevelopment-gebied zo'n beetje de grootste open-source naam die er bestaat; dan lijkt me dat niet zo'n gekke keuze (t.o.v. andere opensource projecten).

[CyBeR]

Sun zelf weigert al jaren in te gaan op het verzoek van de open-source gemeenschap om de broncode van zijn virtual machine vrij te geven

Huh, die kun je toch al een tijdje gewoon downloaden?

edit:
hier: http://java.sun.com/j2se/1.5.0/download.jsp kun je 'm onder twee verschillende licenties downloaden.

[_JGC_]

Ja, onder de sun licentie, welke niet open is. Je moet je ten eerste al registreren en vervolgens moet je akkoord gaan met een hele restrictieve licentie die erop neerkomt dat alles wat jij doet met dat ding eigendom van Sun is.

Edit: overigens vind ik het vreemd dat ze dit vanaf de grond aan opbouwen ipv een project als GNU classpath of kaffe steunen. De GNU java compiler die bij gcc 4.0 zit kan bijvoorbeeld al de java delen van OpenOffice.org 2.0 compilen zonder problemen.

Edit: De VM zelf is ook niet open. Als jij de sourcecode downloadt bij sun, daar een binary compileert en vervolgens die binary als pakket uitgeeft, ben je in overtreding van de sun licentie. Je mag de code inzien, je mag het zelf gebruiken, maar meer ook niet. Dat noem ik niet een open source licentie.

[deathz0rz]

het gaat niet om de compiler maar om de VM

[robin1979]

We hebben al Kaffe, IKVM, GNU ClassPath, SableVM en nu ook nog Harmony.. Lijkt erop alsof er al genoeg OSS Java activiteit is. Laat ze daar maar eens op focussen, in plaats van nog een project op te starten (wat waarschijnlijk pas volledig J2SE1.5 compatible is in 2012 ofzo).

[Verwijderd]

Misschien is het beter je eerst een beetje in de materie te verdiepen ipv zomaar wat te gaan brullen.

quote uit de FAQ:
13) Does this compete with Kaffe and Classpath?
-----------------------------------------------
People from Kaffe and Classpath are helping start this project!(...)

FAQ

edit: autom. link herkenning lijkt niet zo te werken met alle typen links...

[mindcrash]

Niet alleen mensen van Kaffe (Dalibor Topic) en Classpath (Mark Wielaard) zullen meehelpen, ook onder meer Jeroen Frijters (IKVM) heeft zijn hulp toegezegd. Daarnaast hebben Mark en Dalibor aangegeven alleen iets met design en architectuur te doen.

Zie de Proposal voor Harmony die Geir naar de Incubator mailinglist heeft gestuurd voor meer info.

[robin1979]

Het kan wel zo zijn dat ze helpen met het opstarten, maar dan nog doen ze dubbel werk (hetzelfde implementeren onder een andere OSS licentie).

[Verwijderd]

of het wordt een combinatie van de al beschikbare implementaties, de sterke punten uit elk project samen nemen. in theorie een van de goede kanten van OSS, maar iemand moet er wel de moeite voor nemen al die broncode naast elkaar te leggen. misschien is dat wat nu gaat gebeuren.

[robin1979]

Nee, dat kan dus niet, aangezien de licenties danig anders zijn. Het dient dus een volledige herimplementatie te worden.

[Verwijderd]

Met toestemming kun je code herlicenseren

[robin1979]

Het herlicenseren van code is een tijdrovend proces, destijds bij het mozilla proces (waar minder personen iets aan hebben bijgedragen dan aan kaffe), heeft dit ruim twee jaar geduurd eer iedereen toestemming had gegeven, danwel de overige code was herschreven.

Dit kan dus geen serieuze optie zijn...

[Verwijderd]

In plaats van een vrije Java implementatie te gaan maken kunnen we ook gewoon nog even wachten op QT4.

QT4 is cross-platform, C++, open source, en zelfs voor commerciele toepassingen vrij en gratis te gebruiken.

Mijn vraag: Waarom nog in Java ontwikkelen??

[Remus]

Waarom kies je een bepaalde taal? Omdat jij dat fijn ontwikkelen vindt, omdat het het beste aansluit bij je probleem of omdat er misschien al vergelijkbare (deel)oplossingen zijn voor jouw werkgebied in die taal.
Daarnaast neemt Java je op bepaalde punten werk uit handen, waar je bij ontwikkelen in een taal als bijvoorbeeld C++ wel rekening moet houden.
Daarnaast is C++ misschien cross-platform, maar niet platformonafhankelijk. Java bytecode is daarentegen wel platformonafhankelijk: je hoeft het niet te hercompileren voor een ander platform waar ook een VM opdraait.

Met assembler kan je ook prima ontwikkelen, waarom gebruikt er uberhaupt nog iemand een programmeertaal.....

[lvh]

Waarom vergelijken we hier een window toolkit (Qt) met een programmeertaal (Java)? Waarom beginnen we niet ineens met Windows vs Intel?

Qt heeft sowieso bindings aan andere talen. Er is geen enkele reden waarom je geen C-programma zou maken dat Qt als frontend gebruikt.

Gewoon omdat Qt(4) platform independent is en dus mogelijk maakt om abstracte (Qt-specifieke) commando's te geven betekent nog niet dat het concurrentie wordt voor Java.

[MisterData]

Qt is een windowing library die je in principe ook vanuit Java zou kunnen aanspreken Niet helemaal vergelijkbaar he...

[LauPro]

Ik geef ze groot gelijk. Als Sun hun code vrij geeft dan zetten ze een project dat miljoenen en misschien wel miljarden heeft gekost zo op straat. Het lijkt me beter dat Sun gewoon iets maakt dat 'de standaard' is en altijd werkt. En dat 3rd parties concurrerende oplossingen maken. Zo blijft de markt goed, want als Sun de code vrij geeft wordt dat waarschijnlijk de enige serieuze VM.

[robin1979]

Webwereld maakt er een wel heel mooi verhaal van.
http://www.webwereld.nl/articles/35211

[SWINX]

Diegene had hiervoor nog nooit van Java gehoord ofzo..
Laat hem iig bij deze link vandaan blijven.

[REDFISH]

Ik vind het sowieso een beetje overdreven. Als je JSP wilt draaien op je apache dan moet je eerst een 120 MB installatie van java sdk installeren. Okay, je kunt er dan ook echt veel mee, maar ik vind die grootte een beetje overdreven.

[MaZeS]

Je kunt ook alle documentatie weggooien enzo, dan zal het een stuk kleiner zijn.
Servlets hebben trouwens geen sdk nodig om te kunnen draaien(alleen JRE nodig), maar JSP's inderdaad wel. Deze moeten namelijk worden gecompiled bij de eerste aanroep.

[Gert]

Je kan je jsp's ook prima van te vorencompileren, is niet zo prettig als de eerste bezoeker van een nieuwe versie eerst even je site gaat lopen compileren.

[Verwijderd]

Die eerste aanroep veroorzaak je meestal zelf.
Of maak jij altijd je sites en kijkt er nietmeer naar?

[MisterData]

Voorzover ik weet worden JSP's sinds een tijd in Tomcat optioneel (standaard) door de Eclipse compiler gecompileerd, die in een los .jarretje er gewoon bij zit. Je hebt de SDK dus niet nodig, zelf heb ik 'em op m'n server ook niet

[phusg]

Mooi, kan er misschien is eindelijk Azureus onder Debian GNU/Linux gedraaid worden! Althans, zonder closed source software. Kaffe en SableVM zijn zo ver ik weet (nog) geen valide JRE's voor Azureus.

Er is natuurlijk bittornado-gui, maar ja, je wilt als Linux gebruiker natuurlijk niet 2 stappen terug doen kwa functionaliteit/gebruiksvriendelijkheid t.o.v. Windows.

[Soultaker]

Het lijkt er op dat een heleboel mensen niet weten of vergeten te vermelden dat de broncode van de Sun's JDK al tijden beschikbaar is. Het is alleen geen open source project in de zin dat men op de code verder mag bouwen; de code blijft dus van Sun.

Maar het is onzin dat Sun haar code niet openbaar gemaakt zou hebben; dat is wel gebeurt alleen onder een licentie die de OSS-community niet aanstaat.

Een aantal belangrijke bezwaren tegen closed source software, zoals het niet kunnen verifiëren van de integriteit van de software, zijn dus niet van toepassing, omdat je de broncode gewoon kunt downloaden.