Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 49 reacties

Sun gaat het ook laatste restant van de broncode van Java onder een opensource-licentie vrijgeven. Met deze actie wil het concern dat Java meer gebruikt gaat worden in Linux-distributies.

SunHet Californische bedrijf heeft al gesprekken aangeknoopt met linux-distributeurs om een volledige opensource-variant van OpenJDK, gebaseerd op Java Platform Standard Edition 6, te integreren in hun software zoals Opensuse, Ubuntu en Fedora. In eerste instantie zal een bijgewerkte versie van OpenJDK geleverd worden die nog niet helemaal opensource is, maar Sun zal later de plooien gladstrijken. Rich Sands, hoofd developermarketing bij Sun verwacht dat op de Java One-conferentie over twee weken in San Francisco al nieuws te melden valt op het gebied van Linux-distributies.

Sun bracht eind 2006 al het grootste deel van Java uit onder de gpl-v2-licentie, maar enkele componenten zoals encryptie-libraries, grafische code, de geluidsengine en snmp-beheersoftware konden vanwege rechtenkwesties nog niet onder de gpl worden vrijgegeven. Deze componenten maken ongeveer vier procent uit van het Java-platform. "Afgelopen jaar hebben we de meeste problemen opgelost, maar er wordt nog gewerkt aan de geluidsengine van Java en aan snmp-code. Die projecten zullen naar verwachting dit jaar worden afgerond", aldus Sands.

Sun heeft zelf een deel van zijn Solaris 10-besturingssysteem als opensource-software uitgebracht onder de naam Opensolaris en volgens analisten is het bedrijf erbij gebaat om Java op zoveel mogelijk platformen uit te brengen. Ze zien kansen voor Sun om Java-ondersteuning, -diensten en -systemen te leveren aan een nieuwe klanten die Linux draaien.

Moderatie-faq Wijzig weergave

Reacties (49)

Is dit de hete adem van .net / mono die Sun Microsystems voelt? Ooit las ik een artikel dat onder linux behoefte is voor een hogere programmeertaal. Het bezwaar aan c# met mono was dat de standaard van Microsoft was, het bezwaar aan Java was dat er geen goede open implementatie van was.

@pruts0r
Dat is waar, maar C# / .net heeft een hoop voordelen ten opzichte van Java. Daarbij is C# veel minder lang in de running, dus je vergelijking is niet helemaal eerlijk. Ik denk dat als je een grafiekje zou maken van de afgelopen jaren, C# harder in populariteit aan het stijgen is dan Java.

Evenzogoed ben ik blij met deze acties van Sun.

@Little Penguin
"hogere" is niet de correcte benaming, maar dat artikel had het over hoger dan c++. Dan bedoel ik dus zaken als memory management. Over de exacte voordelen weet ik weinig, maar ik meen me te herinneren dat mono efficienter is. Bovendien kan je met c# native code maken en is de integratie met Microsoft Windows aanzienlijk beter (vergelijk het met de acceptatie van Internet Explorer en Silverlight)

[Reactie gewijzigd door 84hannes op 24 april 2008 20:10]

Ik denk niet dat ze daar heel erg bang voor zijn, java is immers al goed geworteld in de vorm van mobiele applicaties, browser applets en full fledged applicaties. Daarbij heeft Java veel meer een open source image dan C#, zie dan ook C# vs. Java in de google code search:

C#: ~1.000.000
Java: 7.190.000+

Maar natuurlijk is het een goeie actie van Sun, die in de open source community goed zal worden ontvangen!
http://www.tiobe.com/inde...paperinfo/tpci/index.html

Volgens bovenstaande link is Java toch meer vertegenwoordigd op het net (meer aantal lijnen code) dan andere talen zoals vb. C#
Java bestaat dan ook vťťl langer dan C# ;) Daarnaast is er meer .Net dan alleen C#. (Ik ben een VB.Net/C#/Java programmeur)

[Reactie gewijzigd door sanderev66 op 25 april 2008 08:34]

wel leuke vergelijking die met google search, maar Java is een eiland, de naam zit ook in javascript etc. Dus eigenlijk best logisch dat je dan meer resultaten krijgt.
Ik zou eerst eens kijken voordat je reageert, hij zoekt namelijk op google code search met lang:, dus alleen maar de goede resultaten
Naast wat jurp5 zegt moet je eens kijken hoeveel Java er op sourceforge, freshmeat en dev.java.net staat.
Vooral in opensource wordt er veel Java gebruikt, waarschijnlijk omdat het in de academische wereld veel gebruikt wordt.
Over 'de hete adem'. Sun is een bedrijf dat initieel enorm open source gericht was. Van de eerste versies van Java werd de code ook gewoon verspreid. Wat Sun nu doet is de logische verderzetting van hoe Java gestart is, open.

Daarbuiten: Onder linux is er tans al jaren support voor hogere programmeertalen. Het is voor veel ontwikkelende talen ook aantrekkelijker om zich op linux te storten, gezien het een matuurder platform is met eenvoudige syscalls.

PS: Ik ben geen Java-programmeur, heb het jaren gebruikt en ben blij dat ik beter gevonden heb.

@Little Penguin: Common Lisp (ruby is ook tof, dat ziet er wat traditioneler uit)

[Reactie gewijzigd door madnificent op 25 april 2008 12:02]

Volgens mij is ook een groot deel van de classes in Java 5 gewoon te verkrijgen met broncode, alleen van de VM was er vziw geen broncode beschikbaar.
PS: Ik ben geen Java-programmeur, heb het jaren gebruikt en ben blij dat ik beter gevonden heb.
En wat is er dan wel beter, is zoiets niet relatief? Voor kernel development is C een mooie taal, maar om er een grote ingewikkelde applicatie in te schrijven is een stuk lastiger... Het is dus maar net hoe je 't bekijkt.
Lastig, maar niet onmogelijk.

(Kijk maar naar Gnome / Xfce)
gnome en Xfce? Dat zijn eigenlijk gehele omgevingen :) Je bedoeld eigenlijk Nautilus, gedit, totem, evolution, GTK, gimp, pidgin, maar ook Thunar, mousepad etc etc.

Kijk dan ook is naar, mplayer, VLC volgens mij ook, vim en ga eigenlijk zo maar door.

Er zijn een groot tal van applicaties, volgens code search meer C dan C++ die gewoon in C zijn. Je kan in C net zoveel als in java, als niet meer. Een goede developer pakt gewoon een taal en maakt daarin wat nodig is.

Ik persoonlijk heb gemerkt, dat een goede dev het meeste gewoon in C schrijft. Waarom niet in C++ of java? Waarom wel.

Ik ken genoeg mensen die roepen 'ja Classes, objecten, bla bla kan niet in C, bla bla, moeilijk dit moeilijk dat pointers bla.

Als je serieuze software developer bent/wilt worden, dan moet je dat toch zonder poespas kunnen? Een pointer is niet een raar moeilijk iets, het iets geweldigs, als je het correct weet te gebruiken.
Trouwens, 'object oriented' programmeren kan je prima in C. Een 'class' is gewoon een C file, public en private dingen heb je ook gewoon door je functie calls in de header van die C file te zetten, so, das public, private zijn dingen dus dan al direct, en niet meer extern benaderbaar als je er 'static' voor zet. Structs en vooral structs met function pointers kunnen zelfs je 'variable methodes' zijn als je dat nou echt graag wilt. Object oriented programmeren is een state of mind, niet een taal. C++ en java helpen je wel hierin en daarom is het ook goed dat scholen hier in les geven (naast gewoon C hopelijk). Dr zijn uiteraard wat dingen die wat lastiger worden in C (nog steeds mogelijk, immers is C++ een extensie van C) maar wie gebruikt er nou dagelijk templates e.d. een int overal in je applicatie declareren, iets dat de C++ compiler je gewoon laat doen, kan handig zijn om snel even iets te doen, maar word erg snel onoverzichtelijk voor anderen die je code na lezen en proberen te snappen.

C++ is een leuke extentie op C, maar voor mijn gevoel blijft ie altijd 'trager' dan puur C. Of dat nou aan de programeurs, of puur aan de taal licht, durf ik niet helemaal zeker te zeggen. C++ kan in sommige specifieke gevallen sneller uit de bus komen (vaak inefficente C code vs optimized C++ code) Als ik echter naar dingen kijk als OpenOffice, Firefox (of windows :p) of QT (vs gtk) lijken die toch stukje logger/trager.
Maar ergste merk ik het nog steeds aan OpenTTD. Dat was vroeger een spelletje wat makkelijk op een 486SX kon gespeeld worden. Maar nu ... *zucht* ik heb het beetje gevolgd en zag dat ludde toen een mooie reverse cleanroom achtig iets gedaan had en de hele game had her-geschreven in puur C. was toen super smooth alles te gek. Toen zijn er aantal mensen dingen gaan toevoegen en 'verbeteren'. Op een gegeven moment kwam er een nieuwe pathfinder die in C++ geschreven was en duurde niet lang meer of alles (dus gewoon ordinaire C code) werd ook met de C++ compiler gecompileerd. Toen was ik eigenlijk gestopt met het volgen van het project, maar mn laptop (P-m 1.7ghz) liep continue op 70% of zo te ratelen en vond ook 100% load niet erg. Nou zijn de graphics exact de zelfde (zijn nog steeds van die pixelated images, volgens mij nog steeds zelfs 256 kleuren, helemaal als je enkel met de origneel graphics set speelt) en het zal vast ook met de 'extra' features te maken hebben, is het spel van af het begin ontzettend lomp geworden.

Sindsdien kijk ik spijtig genoeg naar C++ programeurs die niet per see slecht zijn, maar het toch niet helemaal hebben. (sorry voor iedereen die zich hierdoor aangevallen voelt). Niet iedereen en allemaal natuurlijk, maar goed, zo ondervind ik het, dit is mijn mening :)

Sorry for the long rant, wel trusten aan allen nog wakker :)
Het kost wat koffie, maar dan haal je het einde van deze rant.

C wordt ook wel "near assembly" genoemd, omdat je iedere regel vrijwel direkt in assambler code kan omzetten. Maar is het daarom ook zoveel efficienter?

Ooit heb ik een EM-veld simulator in C++ geschreven, gebruik makende van pure virtuele functies. Wat mij opviel was dat geheugenbeheer cruciaal is voor de snelheid. C++ nodigt heel sterk uit om het geheugenbeheer in je constructors/destructors te stoppen. Maar dat vele aanvragen/teruggeven van geugen kost tijd. Doe je het niet dynamisch maar statisch, dat is het in een keer veel snellier

Maar verder zou je toch denken dat het niet veel uit moet maken.
Dat is waar, maar C# / .net heeft een hoop voordelen ten opzichte van Java. Daarbij is C# veel minder lang in de running, dus je vergelijking is niet helemaal eerlijk. Ik denk dat als je een grafiekje zou maken van de afgelopen jaren, C# harder in populariteit aan het stijgen is dan Java.
Oh ja, wat voor voordelen heeft C# / .NET dan ten opzichte van Java?

C# / .NET en Java lijken heel sterk op elkaar: een programmeertaal die naar bytecode wordt gecompileerd die draait op een virtual machine. Het idee is precies hetzelfde. Alleen bestaat Sun's Java virtual machine langer dan Microsoft's CLR, en is daarom meer volwassen. Sun's JVM is heel geavanceerd, met de Hotspot just-in-time compiler en geavanceerde garbage collection algoritmen.

C# / .NET is van Microsoft, een bedrijf wat erom bekend staat niet erg vriendelijk te zijn t.o.v. open source en met name Linux, terwijl Sun duidelijk pro-open source is.

Dus wat zijn het dan voor voordelen?
Is dit de hete adem van .net / mono die Sun Microsystems voelt? Ooit las ik een artikel dat onder linux behoefte is voor een hogere programmeertaal.
Er zijn genoeg hogere programmeertalen beschikbaar voor Linux hoor: C++, Perl, Ruby, Python - c# is dus niet direct 'het antwoord'. Hoewel het wel het antwoord zou kunnen zijn voor GNOME, omdat zij namelijk nog in C aan het ontwikkelen waren - ondanks dat C++ al tijden beschikbaar was...
Dat is waar, maar C# / .net heeft een hoop voordelen ten opzichte van Java.
En welke voordelen zijn er dan in C# en het dotnet framework?
Gnome werd ontwikkeld omdat KDE (toen de enige linux DE eigenlijk) op QT gebaseerd was, QT was alleen niet volgens de GPL gelicencieerd en dat was een doorn in het oog van RMS. RMS heeft toen (opdracht tot? uitdaging tot?) Gnome in het leven geroepen en deze de GTK toolkit laten gebruiken, die voor de GIMP al geontwikkeld was. Deze was al in C. Er zullen vast nog meer redenen geweest zijn om gnome in C te houden, met name lagere CPU overhead.

Wat betreft C# voor gnome, ik hoop het toch niet. Als straks de C# hype weer voobij is (volgens code surveys was C# alweer langzaam aan het dalen, java nog steeds aan het stijgen, en #1 en C #2 (C++ #3) ben te moe om nu ff link te zoeken, maar ze worden anually gehouden) zitten we weer met iets wat niemand moet. Verder is C# trage poep en om een hele DE in C# te gaan doen lijkt me geen verstandig idee. (buiten het feit dat volgens mij C# voor de widgets in linux toch gtk/qt gebruikt)

Het is gnome zn kracht, dat ze C gebruiken, en zeker niet hun zwakte. Al helemaal niet 'het antwoord' waar gnome op zit te wachten ;)
Hoewel het wel het antwoord zou kunnen zijn voor GNOME, omdat zij namelijk nog in C aan het ontwikkelen waren - ondanks dat C++ al tijden beschikbaar was...
Een antwoord op een niet-bestaand probleem bedoel je?
C++ is echt niet per se beter dan C, zeker in combinatie met GLib. De kernbibliotheken van Gnome gaan echt niet zomaar herschreven worden.

Voor allerlei hogere programmeertalen waaronder Java, C++, Ruby en Python zijn er goede bindings. Als je voor Gnome wilt ontwikkelen heb je dus ruime keuze.
Mss een domme vraag, maar haalt sun zijn winst dan uit ?
Ze verkopen servers van het type 'serieus', hebben een hoop waardevolle kennis (supportcontracten), hebben StarOffice/OpenOffice, en doen MySQL er ook nog voor de leuk bij.

En op Wikipedia zie ik dat ze ook in de virtualisatie en de supercomputers zitten.

[Reactie gewijzigd door DOT op 24 april 2008 20:21]

een non-profit project om naambekendheid te verwerven dus .. (en ook expertise)
Dat, en het is ook een tool voor hun eigen programma's, en operating system. Java startte geloof ik als een project om een "betere C++" te worden. Het werd in-house door Sun gemaakt en gebruikt, om consumer elektronica mee te programmeren.

Later werd het de bedoeling om het internet ermee te veroveren, in de vorm van applets. Dat is nooit echt gelukt. Nu wordt het door grote enterprise-projecten gebruikt. Daar zal Sun echt wel meer dan slechts een droge boterham aan overhouden. ;)

[Reactie gewijzigd door DOT op 24 april 2008 21:41]

Java is tot stand gekomen door Sun en IBM, op het moment en al voor lange tijd is IBM degene die enorm veel investeerd in de ontwikkeling van de Java VM en runtime library (bij mijn weten zelfs meer als Sun, dit is al lange tijd een heikel punt bij IBM)
Managers willen zekerheid. Bij wie vraag je support als het om Java gaat?
Sun Microsystems. En dan kan je maar beter een door Sun gecertificeerde implementatie gebruiken. Mede daarom zal versnippering ook wel meevallen.

Edit: Woops, dat was een retorische vraag geloof ik. Nouja, hierbij het antwoord... :P

[Reactie gewijzigd door DOT op 24 april 2008 21:22]

Inderdaad een domme vraag, als het over het open source maken gaat. De Java VM en JDK waren namelijk altijd al gratis te downloaden. Het open source maken heeft weinig invloed op de inkomsten die ze van hun JDK opstrijken, want die was al 0. Ik denk niet dat ze door het opensourcen ergens inkomsten door mis lopen die ze hiervoor wel hadden.
Het nadeel hieraan is wel dat er nu 1001 verschillende VM's gereleased kunnen worden door Jan en Alleman. Nu zit ik er niet zo diep in om te weten of dat daadwerkelijk gebeurt maar dat scheen dus de voornaamste reden te zijn om niet opensource te gaan.

Voor de rest is Java een prima programmeertaal die in mijn optiek in het leven is geroepen om C++ te vervangen. Dat lukt denk ik wel prima. De performance gaat met iedere versie steeds verder omhoog maar wat belangrijker is, development tijd van projecten nemen verhoudingsgewijs af met Java omdat alles meer voor de programmeur geregeld wordt.

C#/.Net is weer het antwoord op Java. Persoonlijk, en dat is echt puur persoonlijk, neigt C# te veel naar het Drag&Drop principe (zoals DB koppelingen etc.). Nu helpt het wel qua tijd als deze delen van je applicatie geautomatiseerd worden maar zo langzamerhand begint het steeds meer een blackbox te worden. Ik vind dat een programmeertaal simpel moet zijn maar dat je nog wel alle delen zelf dient te ontwerpen en te maken zonder drag&drop componenten. Uiteraard kan dat ook wel maar we weten allemaal dat mensen lui zijn als het kan en daarnaast is het hinderlijk als mensen zich afhankelijk maken van een IDE waarin die dingen zitten voorgebakken :)

[Reactie gewijzigd door killingdjef op 24 april 2008 19:06]

Juist op dit moment worden er allemaal verschillende JVM's uitgebracht. Als Sun het met een opensource licentie uitbrengt hoeven al die klonen niet gemaakt te worden, en blijven alleen de "legitieme" versies over: de versies die echt wat anders te bieden hebben dus.

Ik neem aan dat er twee overblijven: Sun's virtual machine, en Gnu's java compiler. Dat zijn 2 fundamenteel verschillende implementaties. De VM interpreteert platform-onafhankelijke bytecode. De compiler maakt native machine code van de Java code. Beide zullen waarschijnlijk Sun's classpath gaan gebruiken.
Om je alvast uit de drom te helpen over hoeveel er over blijven, de volgende bedrijven maken hun eigen vm of passen die van Sun aan (onder licentie):

Oracle
Bea
IBM
HP
Apache
Azul Systems (Hardware matig voor grote servers)

En zo zijn er nog veel meer.
Het nadeel hieraan is wel dat er nu 1001 verschillende VM's gereleased kunnen worden door Jan en Alleman
Onder de GPL licentie mag je die andere implementaties dan geen Java meer noemen. Dat is een bescherming tegen de auteur van het origineel. Je wilt immers niet dat een afgeleide versie de naam van de oorspronkelijke maker aantast.

Om diezelfde reden heet Firefox in Debian Iceweasel. De debian developers maakten zoveel wijzigingen op Firefox - die ook tot crashes leidden - dat de Mozilla developers zich op hun rechten hebben laten beroepen.

Ik zie het probleem dus niet zo. Bovendien, nu zijn er juist door die strenge regels van Sun alternatieve Java implementaties gemaakt door o.a. Microsoft en IBM. Een eenduidige versie waar iedereen aan kan bijdragen kan dit probleem juist oplossen.

[Reactie gewijzigd door YaPP op 24 april 2008 23:20]

Onder de GPL licentie mag je die andere implementaties dan geen Java meer noemen.
Onzin. Dat is een kwestie van handelsmerk, met GPL heeft dat niets van doen.
Je mag je implementatie Java noemen, als deze geheel volgens Suns definities werkt.

MS had zijn eigen implementatie gemaakt, maar heeft van de Sun definities afgeweken. Hierdoor mochten ze de naam Java niet meer gebruiken. Uiteindelijk zijn ze ermee gestopt om MS Java mee te leveren met windows.

Door die strenge regels van Sun mogen de implementaties van IBM en BEA de naam 'java' dragen.
Waarom zou het hinderlijk zijn om een IDE te gebruiken?
Je code in Java toch ook niet handmatig via JNI naar de betreffende MASM om je GUI te tekenen?

Het grootste nadeel van C# vind ik dat er veel minder opensource libraries zijn. Het is vaak gewoon lastiger om daarmee snel applicaties te ontwikkelen.
Hij geeft niet aan dat het slecht is een IDE te gebruiken, maar dat het hinderlijk is als mensen afhankelijk zijn van een IDE.
Dus dat mensen niet meer zouden kunnen programmeren als hun favo IDE er mee zou stoppen.
Het nadeel hieraan is wel dat er nu 1001 verschillende VM's gereleased kunnen worden door Jan en Alleman.
Dat kon al, hoor. Apple heeft bijvoorbeeld al eeuwen hun eigen VM, de Mac OS Runtime for Java (MRJ, niet meer in gebruik sinds OSX). IBM heeft ook een eigen Java VM en ook een eigen Java Compiler (Jikes), de VM is een tikkie sneller dan die van Sun en de compiler slaat de normale javac compleet het veld uit. Verder zijn er de Blackdown VM's, etc.

[Reactie gewijzigd door CyBeR op 24 april 2008 23:36]

Ik was al blij toen ze begonnen met het vrijgeven van Java, maar dit laat zien dat ze daadwerkelijk van plan zijn alles van de Java-code 100% open-source te maken. Dat vind ik erg tof van ze.
Ze zullen wel moeten. Op dit moment heeft Java last van versnippering op het linux platform:
- Eclipse ECJ compiler
- IBM Jikes compiler
- GNU classpath libraries
- GNU gcj
- kaffe
- Sun java

Allemaal ondersteunen ze java, maar allemaal op een iets andere manier. Eclipse-ecj is gewoon gecertificeerd voor java6 en ondersteunt ook de opkomende java7 standaard al voor het grootste deel. IBM Jikes is al een oude compiler en compileert voor zover ik weet alleen java 1.4 source, GNU classpath is de class library die gebruikt wordt in gcj en kaffe, waarbij kaffe hopeloos achterloopt en gcj net ondersteuning heeft voor java 5.0.

Aangezien Sun linux distributies "dwars zit" met hun beperkte licenties zoeken de grote linuxdistributies zoals Redhat, Ubuntu, Debian, SuSE naar alternatieven in de vrije java projecten. Op dit moment is Redhat bezig met het IcedTea project: de GPL source van OpenJDK gecombineerd met classpath libs voor de ontbrekende elementen die niet als GPL zijn uitgegeven. Nog een versnipperd java project die niet helemaal aan de standaarden voldoet.

Op het moment dat Sun met een JDK komt die 100% uit vrije code bestaat kunnen al die onofficiele projecten aan de kant gegooid worden en kan er gekeken worden naar waar het om gaat: het verbeteren van Java als platform, ipv het namaken van java als vrij platform.
Begrijp ik het nu goed dat dit betekenet dat we plots zoals bij linux 13 in een dozijn uitvoeringen gaan krijgen van JAVA... hoe kan je dan nog schrijven in een algemene taal...
Nee.

Het was allang toegestaan om je eigen implementatie van Java te maken en dat is in de loop van de tijd ook door verschillende partijen gedaan. Apple heeft z'n eigen Java voor de Mac, IBM heeft een eigen implementatie van Java voor Windows en AIX, HP heeft z'n eigen Java voor HP-UX.

Wat er open source wordt gemaakt is Sun's eigen implementatie van Java. Dat is mooi, want Sun's implementatie is erg goed, en is de "standaard" versie die de meeste mensen (op Windows) gebruiken.

Met name op Linux werd tot nu toe Sun's Java implementatie niet meegeleverd omdat het niet open source was. Nu het volledig open source wordt, kan Sun Java standaard meegeleverd worden met Linux in plaats van slechte / onvolledige implementaties zoals GNU GCJ.
Nee, dan begrijp je niet hoe open source werkt. Dat je de code aan mag passen zegt niet dat iedereen ineens een eigen versie gaat onderhouden. Je hebt toch ook niet 10 verschillende versies van de linux kernel, gnu tools, x.org, openoffice.org, firefox, gnome, pidgin, etc? En nee, die debian versie van firefox telt niet, want die heet dan ook geen firefox meer.

[Reactie gewijzigd door kozue op 25 april 2008 11:57]

Die hete adem zal wel meevallen, er zijn weinig projecten die overstappen van java
op .net. Het zijn meer windows oplossingen die nu specifiek in .net worden ontwikkelt.
Danwel met windows forms, danwel asp applicaties die in VB .net worden herschreven
voor IIS. De java serverside applicaties stappen eigenlijk niet over op .net.
Ik denk dat je slechts ten dele gelijk hebt, voor nieuwe projecten kan er namelijk weer een vrije keus gemaakt worden. Als er veel Java expertise aanwezig is, dan zal men zeer waarschijnlijk wel bij Java blijven, maar het is ook mogelijk dat er voor .net gekozen wordt.

Aangezien dotnet indirect aan het ms-windows monopolie gekoppeld wordt zal het langzaam wel [geforceerd] verder groeien - verder heb je nog een categorie mensen (managers e.d.) die nu eenmaal een voorkeur hebben voor Microsoft en alles op MS willen hebben...
Mooi, komen we eindelijk eens af van de versnippering onder Linux. Als ze dan ook eens zorgen voor een goede ondersteuning van OSX dan heef MS echt wel wat te doen.
Ik verwacht eigenlijk alleen maar problemen. Als je iedereen toestaat naar eigen inzicht een JVM te implementeren en de core API te wijzigen dan is het snel gedaan met de compatibility en platformonafhankelijkheid.

Van mij mag het blijven zoals het altijd was: iedereen mocht zelf een implementatie van de JVM en de APIs maken, maar men mocht het alleen Java noemen als Sun de implementatie heeft gecertificeerd. Certificering hield in dat de implementatie zonder fouten door de test framework van Sun komt. Hiermee wordt voorkomen dat er implementaties zijn die afwijken van de specificatie.

Op zich mag Sun hun code best open source maken, maar de verplichte certificering moet blijven!
Die versnippering is er al, gezien de hoeveelheid rondslingerende implementaties die voort zijn gekomen uit het closed-source zijn van java, als antwoord vanuit de OSS community. Nu kunnen projecten als blackdown, classpath, icedtea, etc mooi verdwijnen en plaatsmaken voor de officiele versie, want waarom zou je nog een niet helemaal compatible JVM willen hebben als de officiele voldoet?
Ik snap eigenlijk niet wat er nu precies nieuws is aan dit bericht (heb 't ook al op andere websites gelezen).

Is het nieuws hier dat Sun met Linux distributeurs spreekt om Sun Java meegeleverd te krijgen met de verschillende Linux distributies?

Want het feit dat Java open source wordt en dat er hard gewerkt wordt om de laatste 4% proprietary code in de JDK te vervangen door open source componenten was al meer dan een jaar bekend.
Persoonlijk zie het nut van Java niet in om in Linux geintegreerd te worden.

Mede doordat onder de "hogere" programmeer talen al een meer dan waardige kandidaat tijden feiloos onder veel Linux distro's draait: Python.

Nou wil ik niet een Java vs Python discussie beginnen maar waarom Java in distro's integreren als je Python al heb?

Ik snap de bedoeling van Sun overigens wel, tevens de wil van de vele gebruikers die Java toch heeft. Toch heb ik mijn twijfels tot in hoever Java ook daadwerkelijk ook in bijv Ubuntu zal integreren.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True