Apache schrapt Harmony-project

De Apache-stichting heeft besloten om het Harmony-project stop te zetten. Harmony is een opensource-Java-implementatie, waarvan een deel is gebruikt in de Java-vm van Android. Eerder stapte Apache al uit de Java-stichting.

Twintig van de 22 Apache-bestuursleden stemden volgens Zone-H voor het verplaatsen van het Harmony-project naar de zogenoemde Apache Attic, de plaats voor projecten die zijn afgestoten. Alleen als het project opnieuw wordt gestart, kan Harmony weer als officieel Apache-project terugkeren. Opnieuw starten kan op verschillende manieren, bijvoorbeeld door het creëren van een fork. Iedereen is echter vrij om de broncode van Harmony te gebruiken als basis voor verdere ontwikkeling.

In december stapte de Apache Software Foundation al uit het bestuur van het Java Community Process, het overlegorgaan dat de Java-specificatie vaststelt. Volgens Apache was er van alles mis met de licentievoorwaarden voor nieuwe Java SE-versies, zoals een verbod op de distributie van opensource-Java-implementaties. Harmony wordt rechtstreeks getroffen door een dergelijk verbod. Wat ook zal hebben meegespeeld bij het besluit om te stoppen, is dat IBM aankondigde niet meer mee te helpen aan de ontwikkeling van Harmony.

Harmony was bedoeld als een opensource-implementatie van Java, maar er werd al jaren gesteggeld over de licentievoorwaarden van de Java Compatibility Kit. Die toolkit kan worden gebruikt om te testen of een opensource-Java-implementatie compatibel is met de officiële toolkit. Sun, dat inmiddels door Oracle is overgenomen, stelde strenge eisen aan de toolkit. Zo mocht deze niet worden gebruikt om een Java-implementatie te testen op andere hardware dan een normaal workstation. Bijvoorbeeld kiosken en medische apparatuur vielen hierdoor buiten de boot.

Reacties (20)

[Verwijderd]

Reactie op het programmeertalen debacle in de diverse post's hierboven...

Zolang de management mannen met stropdas de keuzes maken op basis van hipheid of mogelijke juridische aansprakelijkheid zonder te weten of willen (/ kunnen) begrijpen wat de consequenties van hun keuzes zijn moeten veel programmeurs met schroevendraaiers hameren.

Het in de ijskast zetten van dit soort open source alternatieven is gewoon bijzonder jammer en zonde van al het reeds verzette werk.

IMO is Java net als C++ en bijvoorbeeld Delphi pascal gewoon een taal als Engels Duits of Frans waarbij het leren en beheersen van de taal niets te maken heeft met het feit of je als mens / programmeur (qua analogie met een "gewone taal") er een goed boek in kunt schrijven.

Dan is er nog het onderscheid of je er als schrijver een goede roman / triller of wat mij betreft kookboek in kunt schrijven. Een 10 voor dictee (de basis waarop veel programmeurs worden aangenomen en gecertificeerd worden) zegt niets over de kwaliteiten van de programmeur die de taal toepast. Dit ongeacht of de betreffende taal zich beter leent voor een bepaalde toepassing dan een andere.

Een nadeel van de "hogere" programmeertaal legoblok mentaliteit die ik in het velt tegenkom is dat er blind van uit word gegaan dat de gebruikte blokken daadwerkelijk doen wat ze zouden moeten doen en dat er gelijk nog 298384 andere blokjes mee geïnstalleerd worden die niet worden gebruikt maar in deze zelfde lib / jar / whatever worden mee geladen met alle beveiligings- en stabiliteitsconsequenties die daar bij horen.

Ik persoonlijk werk nog altijd veel met delphi en fpc. Object georienteerd met fatsoenlijke string afhandeling en waar nodig de mogelijkheid om inline assembler toe te passen. Resultaat 1 enkele exe van een paar MB zonder behoefte aan obscure dll's en voorgeinstalleerde runtimes van exact de juiste versie en taal e.d.

Kortom ieder zijn ding...

[sambalbaj]

Dus als ik het goed begrijp heeft Oracle hier middels de licentievoorwaarden op een succesvolle manier er mede toe bijgedragen dat een concurrent voor het eigen Java beëindigd wordt.

Ben benieuwd wat dit voor gevolgen zal hebben voor OpenOffice.org dat sterk op Java gebaseerd is en sinds kort vanaf Oracle bij Apache onder gebracht is.
http://incubator.apache.org/openofficeorg/

[Dreamvoid]

Java applicaties gaan het niet merken, als de VM Java-compliant is, moet het gewoon draaien. Het gaat hier om de VM zelf: Oracle is niet zo blij dat hun eigen software tegen de licensievoorwaarden in wordt gebruikt om de concurrentie te helpen een Java-kloon te maken.

In de praktijk maakt de beslissing van Apache niet zoveel uit - de boel is open source, en de enige grote gebruiker van (delen van) Harmony is Google, en die gaan rustig door met het ontwikkelen ervan, en het verder knokken met Oracle in de rechtzaal.

Wie er gelijk heeft - ik zou t niet weten. Er is wat te zeggen voor allebei de kanten van de zaak, Google en Oracle hebben allebei genoeg centjes om een dure advocaat hun verhaal goed uit de verf te laten komen, laat de rechter maar lekker een uitspraak doen.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 14:55]

[ronaldmathies]

Staat hier helemaal los van. OpenOffice kan met de standaard JRE werken. Volgens mij werd de Harmony JRE ook niet meegeleverd.

[Verwijderd]

java is een gedrocht dat niet meer thuishoord in deze wereld....

Dat valt reuze me, er zijn nog steeds legio mogelijkheden om Java te gebruiken, zowel in de professionele wereld als in de hobby sfeer zonder enige licentie te overtreden.
Er zijn ook in de java wereld zat erg mooie frameworks die je zo kunt gebruiken om ook closed source projecten te maken, zonder dat je met licentie problemen te maken heeft, dus het iz zeker geen gedrocht.

Als je voor de business wereld applicaties wilt maken met een unix type als OS, kom je in 8 van de 10 gevallen eigenlijk alleen maar uit op Java, net zoals je .NET zo kiezen op het moment dat je weet dat Windows je onderliggende OS is (we hebben het dan niet over een website, maar business applicaties).

[ATS]

Als je voor de business wereld applicaties wilt maken met een unix type als OS, kom je in 8 van de 10 gevallen eigenlijk alleen maar uit op Java, net zoals je .NET zo kiezen op het moment dat je weet dat Windows je onderliggende OS is (we hebben het dan niet over een website, maar business applicaties).

Leg eens uit? Waarom kom je dan "8 van de 10 gevallen" uit op java, en niet op, bijvoorbeeld C++? En waarom kies je precies perse .NET als je op windows werkt?

[Dreamvoid]

In het algemeen wil je een cleane, high-level taal hebben met veel ingebouwde veiligheid en rijke libraries (geen dubbel werk). Dan kom je eigenlijk automatisch bij C#/.NET en Java uit. Welke je dan kiest hangt voornamelijk af van het platform waarop het moet draaien. Heb je een Unix/Linux serverpark, dan Java, is het Windows, dan .NET. Laten we maar geen flamewar beginnen over Java vs C#, maar het is duidelijk dat beide platforms hun fans hebben, en dat in de praktijk ze niet idioot veel van elkaar verschillen.

Een unmanaged taal als C of C++ is mooi als je de laatste druppels performance eruit moet persen, maar het is allemaal wat minder gestructureerd en levert in het algemeen wel wat complexere en moeilijkere code op - wat toch lastig is als er veel verschillende developers aan moeten werken.

In de praktijk levert men bij de meeste enterprise server-side projecten graag wat performance in voor snellere development, betere onderhoudbaarheid en de veiligheid van een managed code omgeving. Aan de client/consumenten kant is het een compleet ander verhaal, daar is UI responsiveness heilig, worden alle 'native code' shortcuts en trucs uit de kast gehaald, zijn die strikte, trage managed talen bijzonder impopulair, en is het C en C++ wat de klok slaat. Het zijn allemaal clichees, maar wel een beetje waarheid.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 14:55]

[Leejjon]

C++ = Technisch Lego
Java/.net = Lego
Script talen = Duplo

Als je een grote toren moet bouwen ben je met duplo het snelst klaar. Als je een molen wil bouwen gebruik je lego, en als je een achtbaan wil bouwen gebruik je technisch lego. Ik denk dat .net iets sneller ontwikkeld dan Java omdat visual studio beter is dan gratis ide's als eclipse/netbeans. Maar Java draait beter op verschillende platformen en doet alsof het open source is

[Reactie gewijzigd door Leejjon op 25 juli 2024 14:55]

[Dreamvoid]

Das een mooi voorbeeld als je van low-level naar high-level talen loopt, maar qua structuur/onderhoudbaarheid gaat die analogie een beetje de mist in - de meeste script talen zijn helemaal niet zo netjes gestructureerd, managed en strict en die vrijheid/blijheid levert (even generaliseren) vaak een veel grotere codesoep op dan een Java/C#. Javascript bijvoorbeeld is tegenwoordig een grote chaotische lappendeken van libraries en extensies waar een Java/C# purist van gruwelt, maar wat in de praktijk bijzonder performant en succesvol is geworden.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 14:55]

[Verwijderd]

Omdat je tegenwoordig het snelst ontwikkelt met een "managed" taal als .NET of Java.

De ontwikkel cyslus is korter.
Er is Java op ieder OS.
En met Mono is er ook .NET op ieder OS mogelijk.

Zo zijn er nog wel een stapel redenen te bedenken. Neemt niet weg dat C/C++ geen markt heeft. Voor reken intensieve taken kun je nog steeds het beste een gecompileerde taal gebruiken.

[GrooV]

Omdat C++ te low level is daar voor. Kijk maar eens wat voor stappen .NET te laatste jaren heeft gezet. Als programmeur wil je zo efficiënt mogelijk werken en dan ga je geen intranet sites in C++ maken.

[wica]

Niet om te trollen hoor, maar dat men 8 op de 10 keer op java uit komt heeft voornamelijk met de type ontwikkelaars die mijn kiest voor bepaalde projecten.

Projecten zouden perfect in een andere taal geschreven kunnen worden en meestal nog goedkoper ook.

Mijn ervaring met het beheren van JAVA platformen is dat ze onnodig veel resources vreten, dat de ontwikkelaars zich beter voelen dan programmeurs in andere talen. En om niet te vergeten, kunnen de meeste JAVA ontwikkelaars niet out of the box denken, als het niet op hun manier gaat, dan niet.

En dan vragen ze zich bij de overheid af, waarom een project duur wordt

[Janoz]

Sorry hoor, maar slechts een fractie van de kosten van de implementatie van dergelijke grote projecten gaat op aan het daadwerkelijke programmeren. Het meeste geld wordt opgemaakt om uit te zoeken wat er uberhaupt gebouwd zou moeten worden. Bij de overheid is dit vaak nog weer een slag duurder omdat er daar vaak veel mensen zitten die er tegenaan willen bemoeien terwijl er juist weinig mensen zijn die verantwoordelijkheid willen nemen en knopen willen doorhakken.

Ik ben trouwens erg benieuwd naar welke talen in jouw ogen voor perfecteren en goedkopere oplossingen gaan zorgen.

[TheekAzzaBreek]

Java vreet veel resources (vergeleken met low level talen), maar te veel? Nee. De hogere programmeertalen leveren zo veel hogere productiviteit voor programmeurs en testers op, dat je die extra resources met een brede grijns betaalt.

[Dreamvoid]

Het maakt ook niet zo veel meer uit, Google heeft grote delen van het project toch al onder de Dalvik paraplu voortgezet. En IBM (1 van de originele sponsors) was er al eerder vorig jaar uit gestapt om aan de 'officiele' OpenJDK te gaan werken samen met Sun/Oracle. Voor zover ik weet werken er nu nog maar een handjevol developers aan.

So long, and thanks for all the code.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 14:55]

[Verwijderd]

En die dalvik paraplu is op het moment onderhevig aan een stevige rechtzaak tussen Oracle en Google.

[Xenan]

Het lijkt tegenwoordig de omgekeerde wereld. Microsoft legt Mono en Moonlight geen strobreed in de weg. Oracle daarentegen dwarsboomt allerlei Java alternatieven.

[Verwijderd]

Oracle daarentegen dwarsboomt allerlei Java alternatieven.

Dit was al een issue voordat Oracle in beeld kwam. De issue bestond al met Sun.

[elmuerte]

Nee hoor. Oracle lag al in de weg voordat er een Microsoft was. Maar dit nieuws artikel heeft weinig met Oracle te maken.
Apache Harmony is niet meer nodig omdat er nu OpenJDK is.