Apache Software Foundation stapt uit Java Community Process

De Apache Software Foundation stapt uit het Java Community Process-overlegorgaan. De stichting is het niet eens met de beslissing om Oracles roadmap voor Java 7 en 8 goed te keuren. Oracle vraagt Apache het besluit te heroverwegen.

Binnen het Java Community Process overleggen de betrokken partijen al sinds 1998 over toekomstige versies van het Java-platform. De Apache-stichting doet al tien jaar mee aan het overleg, maar maakte donderdag in een mededeling bekend uit de Java Standard and Enterprise Edition Executive Committee te stappen. De stap is een opmaat naar een volledig afscheid van het JCP, hetgeen binnenkort moet plaatsvinden, zegt de president van de Apache-stichting, Jim Jagielski, tegen The Register.

De stichting is ontevreden over het besluit van het Java Standard and Enterprise Edition-orgaan om Oracles roadmap voor Java 7 en 8 goed te keuren. Alleen Apache, Google en het onafhankelijke lid Tim Peierls stemden tegen. Peierls gaat de commissie overigens ook verlaten. "De stemming was de laatste kans voor de commissie om te tonen dat ze het Java Community Process als open-specificatieoverleg willen verdedigen en om te demonstreren dat de geest en de letter van de wet ertoe doen", staat in de mededeling. Hiermee doelt de stichting op de Java Specification Participation Agreement: de regeling die het reilen en zeilen van het JCP omschrijft.

Volgens de stichting was er van alles mis met Oracles Java SE 7-specificatie en -licentie, waaronder het ogenschijnlijke verbod op de distributie van onafhankelijke opensource-implementaties van de Java-versie. Onder andere Apache implementeert dergelijke onafhankelijke Java-versies, namelijk bij  Harmony, dat van Oracle geen licentie krijgt.

Adam Messinger, vice-president ontwikkeling bij Oracle, roept Apache op te blijven: "We moedigen Apache aan zijn positie te heroverwegen en deel uit te blijven maken van het proces om Java verder te helpen. De Apache Software Foundation en veel opensourceprojecten die er deel van uitmaken, vormen een belangrijk deel van het Java-ecosysteem."

Reacties (89)

De discussie tussen (vroeger Sun en nu) Oracle en Apache gaat over het überhaupt kunnen schrijven van een open source implementatie van in dit geval de Java specificatie. Dat is nu niet mogelijk, omdat je, om een open source implementatie Java te mogen noemen de TCK moet passeren. Die TCK mag je alleen passeren als je je conformeert aan de Field Of Use restricties die Oracle je oplegt (je mag je implementatie nooit op embedded of mobiele devices gebruiken) en dat is weer direct in conflict met zo'n beetje alle open source licenties.

Kortom, daar kom je niet uit.

Het alternatief is om het dan maar geen Java te noemen, maar dan ontstaat er een ander probleem. Oracle bezit allerlei patenten op Java en je kunt vinden van patenten wat je wilt, maar zonder de patent bescherming die alleen gekoppeld zit aan het passeren van de TCK loop je als gebruiker het risico dat je door Oracle wordt aangeklaagd. Je snapt dat dat voor Apache en alle gebruikers van hun projecten ook geen aantrekkelijk alternatief is.

Er is dus geen enkele legale manier om een open source implementatie van Java te maken.

Neem daar nog eens bij dat in het verleden zo'n TCK wel, zonder FOU restricties, beloofd was aan Apache en je snapt een beetje wat het probleem is. Het is niet alleen een conflict tussen Apache en Oracle, maar meer tussen de complete open source gemeenschap en Oracle, want ook andere open source projecten kunnen nooit een JVM implementeren onder de bestaande licenties. Pikant detail is verder dat Oracle hun eigen "OpenJDK" wel beschikbaar stelt zonder die FOU restricties, dus zelf hoeven ze zich niet aan die regels te houden.

Zolang de JCP het spec leads toestaat om specificaties te ontwikkelen waaraan allerlei restricties verbonden zijn die onafhankelijke implementaties het leven zuur maken heeft het volgens Apache ook geen zin meer om hieraan mee te doen. Bill Joy van Sun riep eens "Most smart people don't work here... for an definition of 'here'" waarmee hij een pleidooi hield voor open innovatie. JCP had dat moeten zijn, maar is dat in de praktijk nu niet. Dat is jammer voor de hele Java gemeenschap.

Wat mij opvalt is dat iedereen hier Oracle loopt af te branden. Terecht of onterecht, er is nu in iedergeval wel een duidelijke lijn met betrekking tot Java. De visie is ook aanwezig, iets welke ver te zoeken was met Jonathan Schwartz.

Ik denk dat dit in zn geheel allemaal een beetje uitvergroot wordt. Waar MS vroeger gebasht werd, is nu Oracle de "zondebok"; nogmaals.. terecht of onterecht.

Wat ik wel interessant vind is dat Google bij voorbaat al wist dat ze met hun Java implementatie "iets" zouden schenden. En als Google netjes een licentie had genomen om per verkocht mobiel toestel een X bedrag af te staan aan de Java eigenaar (Vroeger Sun, nu Oracle) dan was er niets aan de hand geweest.

Maar kennelijk had Google niet veel zin om te betalen aan een verzwakt Sun die toch de juridische strijdt niet aan zou gaan. Nu Google met zijn succesvolle Android nieuw leven in de taal Java inblaast worden de rollen zelfs omgedraaid; Sun/Oracle zou Google juist DANKBAAR moeten zijn voor de exposure

Erg merkwaardig allemaal dus. Plus, Google heeft altijd al het imago gehad van "Vriendelijk, betrouwbaar" en "voor de developer!" dus het kopt lekker om de "geldwolf" Oracle aan te vallen; zo moet ook de ASF gedacht hebben.

Ik ben zelf een Java developer en heb zelfs mijn eigen Android game gemaakt maar ik vind wel ere wie ere toekomt. Gratis meeliften op iemand anders zijn succesen is makkelijk maar niet juist.

Soms denk ik wel eens dat ik de enige ben die Jonathan Schwartz's blog post gelezen heeft vlak nadat Google Android werd aangekondigd, maar ik vond en vind 'm opvallend: http://blogs.sun.com/jonathan/entry/congratulations_google . De korte samenvatting is dat hij Google feliciteert en hoopt dat Sun snel support voor Android in NetBeans inbouwt. Naar mijn mening getuigt dat van visie.

Hoewel we als buitenstaanders natuurlijk nooit precies weten hoe de gesprekken tussen Sun en Google over Android verlopen zijn, kan ik me voorstellen dat er niet alleen discussies waren over licentievoorwaarden. Als je kijkt naar de architectuur van Android dan zijn er een aantal verschillen ten opzicht van Java. De meest in het oog springende is waarschijnlijk de compleet andere UI toolkit. Ik vraag me af of Sun die wijzigingen überhaupt wel wilde accepteren. En laten we wel wezen, J2ME met hun UI toolkits konden toen al niet meer meekomen.

Hoe meer java verspreid raakt, hoe meer het op linux gaat lijken. *tig verschillende implementaties uiteindelijk, waar geen compatibiliteit meer in te vinden is.

Java was een prachtig initiatief, en ik hoop dat dit probleem bijgelegd wordt zodat dit geen bedreigde taal hoeft te gaan worden.

Even afgezien van het feit dat linux slechts een kernel is (met overigens een zeer brede compatibiliteit, breder dan ieder ander os op de markt) is die stelling ook onzin wat betreft linux distributies (het feit dat je je software op iedere distro kunt draaien is juist een van de redenen dat het vrije markt model zo goed werkt voor linux - dat is juist een teken dat de compatibiliteit wel goed zit)

Overigens was dit overleg/proces juist bedoeld om alles in goede banen te leide mbt compatibiliteit, orcale is daarmee opgehouden dus je zult hoogstens 2 implementaties gaan krijgen, een open versie en een gesloten (orcale) versie, het zou me zelfs niet verbazen als het enigzins de kant zal opgaan van openoffice.

vziw is het toch nog steeds zeer compatibel met elkaar (linux).
Staaf eens met voorbeelden?

Probeer maar eens een rpm op een debian installatie te instaleren. Of oracle op ubuntu. Er zijn grote verschillen tussen red hat omgevingen suse en debian gebaseerde systemen.

Dat zijn niet meer dan packages die de installatie van software vergemakkelijken. De binaries die in een .deb of .rpm zitten zijn bijna identiek aan elkaar.

Als je een .deb uitpak op, ik zeg maar, opensolaris, dan kan je die binaries normaal gewoon draaien (mits alle libraries aanwezig zijn, maar daarom maak je ook gebruik van packages )

Offtopic...

Ja, dat is misschien wel waar.
Maar dat is natuurlijk wel hoogst irritant. Wie gaat dat nou "even" doen?

Ik zeg: de concurrentie positie van Linux zou BETER zijn met minder distro's.
Er is gewoon teveel discrepantie tussen de distro's.
Het is onzin te zeggen dat dat niet zo erg is want het is allemaal "linux".
Het moet WERKBAAR zijn.

Nu zal er in goede UNIX traditie wel een gedacht achter zitten van "tools, not policy" maar volgens mij is policy PRECIES wat Linux nodig heeft.

[Reactie gewijzigd door lenny_z op 10 december 2010 17:38]

Als de UNIX community ging voor een concurrerende marktpositie had je gelijk. Daarvoor moet er inderdaad meer policy komen. Echter, OSS bouwen gaat niet direct om klanten/gebruikers te winnen. Het gaat meer om software te bouwen die je zelf zou willen gebruiken. En niet om het grootste aantal gebruikers.

De LSB is al universeel en wordt bijna overal (door alle 'grote') toegepast. Verder heb je dat de X server overal zo goed als identiek is, en dat als je voor een GUI gaat, GNOME en KDE ook gewoon hetzelfde zijn.

Werkbaar is het allemaal, als je kennis hebt. Als je geen kennis hebt, moet je gewoon in desktop land blijven bij Mac OS X of Windows, want dat is voor mensen met minder kennis ontworpen. (niet op de man af bedoeld)

Vaak zitten de verschillen in de GUI, maar niet zo zeer in de CLI, waardoor je gewoon je linux systeem altijd, distributieonafhankelijk kan gebruiken.

Je moet het niet "even" doen. Een voorbeeldje: Van OpenTTD heb ik gewoon de binaries in mijn dropbox staan. Daardoor kan ik het zowel onder ubuntu als opensuse draaien.

Maar voor de meeste programma's gebruik ik wel een package manager omdat dit een stuk gebruiksvriendelijker is. Op dat vlak verschillen die packages niet veel van een setup onder windows, ze doen exact het zelfde!

Toegeven, er zijn véél distributies, maar de grote kan je op één hand tellen die je in veel bedrijven terug vind. De andere zijn voor een specifiek doel (denk maar clonezilla, antivir rescue, knoppix) of voor fanatiekelingen.

Zo, weer iemand die denk het probleem met linux op te lossen. Maar niet heus, geef jij ze even een paar miljard per jaar voor marketing en hou het een jaar of 3 vol, wedden dat er weinig mensen windows meer draaien! Vooral niet met een distro als ubuntu. Dat is het enige wat linux kernel mist, een paar miljard

Google is met Chrome OS en Android druk bezig een boel geld in te pompen en het lijkt ook effect te hebben.

@IStealYourGun: En toch geeft het blijkbaar teveel chaos met al die verschillende distro's en verschillende complexiteiten, anders zouden wel meer programma's (zoals o.a. games) goed op linux draaien en zouden meer mensen linux gebruiken.

@Leipepo: Met alleen centjes kom je er niet hoor, ook al zijn het er een paar miljard. Linux is nog steeds te complex voor de huis- tuin- en keuken gebruikers. Er moet iets fundamenteel anders in de presentatie van linux naar de eindgebruiker en de (goede!) ondersteuning voor hardware.

[Reactie gewijzigd door ravenamp op 11 december 2010 11:25]

Het zijn gewoon dezelfde pakketten anders ingepakt. Soms is er ook nog wat aan getweaked maar dat is meestal zeer weinig.

LSB is er een, een standaard voor alles wat je noemde, en dan heb je inderdaad de twee grote packaging verschillen, DEB vs RPM. Met alien kan je RPM op een DEB-systeem gebruiken.

Verder is het verschil tussen SuSE, Red Hat en Debian niet zo groot, en bedoel je waarschijnlijk de GUI die dan toch minder van belang is, om dat non-desktop linux vooral voor performance gebruikt wordt die je met Windows of Mac OS X niet kan halen.
Ook hebben de mensen die perfomance een belangrijk punt vinden vaak de kennis om gewoon de CLI fatsoenlijk te gebruiken, en daar is bijna alles hetzelfde.

Iedereen schiet nu in de verdediging voor Linux maar dit topic gaat over Java.

Maar wat je zegt klopt ook voor Java niet. Oracle heeft het over certificering van Open Source Java implementaties. Dit weigeren ze. De implementaties zijn echter wel degelijk volledig met elkaar compatible. Je Java implementatie draait op alle Java Virtual Machines.

Helaas hebben sommige fabrikanten virtual machines gebouwd die lijken op Java maar dat niet zijn. Voorbeelden zijn Dvorak, de Android VM van Google, en MS-J )of hoe het precies heet) de MS specifieke Java afgeleide van Microsoft. Deze werden/worden door Sun en Oracle bestreden en mochten zichzelf geen Java VM's noemen (terecht imho).

Voorbeelden zijn Dvorak, ...

Dalvik (niet Dvorak, dat is heel wat anders). Microsoft's versie van Java is al tien jaar geleden "gestorven" nadat Microsoft door Sun werd aangeklaagd en Microsoft die rechtszaak verloor.

Dalvik (niet Dvorak)

Excuses je hebt gelijk.
Echter zit er nog steeds iets in .NET wat J# heet en op Java 'lijkt'...

Ik ken anders maar één linux.
Dat er vele distributies zijn van GNU Linux is niet eens zo erg en een zegen voor hardware fabrikanten die een embedded linux kernel gebruiken (en een zegen van de community die daardoor die hardware kan modden) .

Het is dus een bewuste keuze van Linux om het OS gedeelte over te laten aan andere. Bij Java is dat niet zo.

<kanweg>

[Reactie gewijzigd door ravenamp op 11 december 2010 11:21]

Gek eigenlijk dat er zoveel java gedoceerd wordt op hbo's en zeker op zo gek op uni's. Het is eigenlijk helemaal niet zo open als het lijkt. Nu al helemaal niet meer. C(++) is veel opener, maar de drempel ligt te hoog om mee te beginnen of iets snel uit te kunnen leggen.

Stel dat het helemaal de verkeerde kant op gaat met java en het een gesloten proprietaire standaard wordt, wat zou een mooie standaard zijn om java te vervangen op uni's? Ruby/Python zijn nette script talen, wel totaal open en draaien eigenlijk ook op een vm. Maarja, script taal is weer wat anders. Didactisch is het wel handig, maar het is totaal niet industrieel toegepast.

[Reactie gewijzigd door DeuTeRiuM op 10 december 2010 16:33]

Python vindt toch zeker wel toepassing in de productie-omgevingen. De performance is slechter dan Java, maar beter dan scripttalen als Ruby. Voor alles is een library en als je meer performace nodig hebt, programmeer je een deel in C.
Didactisch zou dat ook een leuke opmaat geven.

Ik weet niet wat er aan de onderwijsinstellingen onderwezen wordt. Kan me voorstellen dat een cursus programmeren in ??? buiten het bestek van een universiteit valt, maar op HBO zal dat natuurlijk wel gebeuren. Waarom geen python? Afhankelijk van hoe je kijkt is het om en nabij de op 5 na populairste taal en de meest populaire scripttaal.

Er wordt voornamelijk java gebruikt. Mijn (slechte) ervaring is dat je op het HBO begint met knoppen neerzetten en daar wat achter programmeren en op de uni (hoor ik) dat je begint met de basis principes.

HBO is dan ook meer een leerfabriek om later je baas blij te maken met dingen die leuk ogen. Niet om echte dingen te maken, dat doet de software architect die boven je staat dan.

Op de Uni leer je programmeren, en leer je niet arbeider worden.

Wat een onzin. Ik heb zelf op de HBO informatica gedaan en ook veel in de dagelijkse praktijk samengewerkt met mensen die van de uni kwamen. Wat mij opviel was dat veel mensen die van de uni kwamen erg veel praktijk ervaring miste en vaak zeiden ze ook dingen als 'programmeren ligt mij niet zo'.

Begrijp me niet verkeerd er komen ook veel goede programmeurs van de uni en als zo iemand het graag wil leren dan lukt dat ook snel maar op de uni is men veel abstracter en theoretischer bezig. Terwijl het met programmeren ook voor een groot deel oefening is dat kunst baart.

Uiteindelijk maakt het heel weinig uit welke taal je gebruikt. Je kunt in alle talen broddelwerk maken. Java beschermt je tegen een aantal veel voorkomende problemen maar daar krijg je weer andere voor terug. C++ is krachtig maar staat je ook toe jezelf krachtig in de nesten te werken. Als je denkt dat een taal heel belangrijk is om goed programmeerwerk te leveren, of als je denkt dat goede programmeurs de ene taal gebruiken en slechte programmeurs een andere, dan zegt dat denk ik meer over jou dan over die mensen. Je kunt mensen niet in vakjes opdelen: Slimme uni mensen vs domme HBO mensen of Slimme C++ mensen vs domme Java code monkeys.

Python vindt toch zeker wel toepassing in de productie-omgevingen

ubuntu.....

ik vrees dat de grootste tegenhanger van java gebaseerd is op een andere niet vrije constructie namelijk .net (met mono) scripttalen zoals php ruby python en dat soort meuk zijn gewoon veel te beperkt. leuk voor een website, maar verder eigenlijk niet.

ik denk dat QT misschien nog de meeste kans maakt op dan uit te groeien tot een platfrom maar die draait (vooralsnog) geloof ik niet in een vm. de open java implementaties etc zullen een mogelijk probleem worden als Oracle met patenten gaat lopen schermen.

ik houd m'n hart vast.

Nogmaals. Ubuntu staat BOL van de Python.
En websites zijn nou niet echt een voorbeeld om een taal op af te zwakken.
Enig idee hoe kritiek de executie snelheid is op websites als Facebook?

Dus hoezo "leuk voor een website" ?

Ja, maar ubuntu is toch geen productie in de zin van een embedded apparaat? Java is soms door processoren native ondersteund. Of scripttalen zijn gemaakt in java, sommige plcs draaien zelfs java.

QT is geen programmeertaal. Dat is een widget toolkit. QT heeft bindings naar zo ongeveer elke taal.

Python is beperkt in wat? Google kan er prima mee uit de voeten en anderen die er oa robots mee doen ook! Mono/.net is ook geen programmeer taal. Er zijn talen die deel uitmaken van mono/.net.

Facebook is nou niet echt een goed voorbeeld; dat is echt php prakwerk ten top! php omzetten in c, dat wordt omgezet in asm en dat in binarycode. Dat is compleet uit de hand gelopen! Voordeel van php is dat er zo ontzettend veel ontwikkelaars zijn.

[Reactie gewijzigd door DeuTeRiuM op 10 december 2010 17:56]

Ik heb hierboven al iets vergelijkbaars gezegd maar herhaal het hier maar even: De taal maakt geen ruk uit. Echt niks. Je kunt in C++ een trage but applicatie maken en in Python of PHP een razendsnelle.

Een domme fout in je algoritme kost tienduizenden of miljoenen CPU cycles, terwijl de executiesnelheid van een goed script vs een C++ applicatie die hetzelfde doet meestal maar marginaal is. Dit komt doordat het zware werk in script talen vrijwel altijd uitbesteed wordt aan lower level componenten, zoals OpenGL libraries, Regular Expression libraries etc. Die zijn gewoon in native code geschreven en of je dan in C++ zegt:

parser->parse(expression)

of dat je in Java zegt

parser.parse(expression)

maakt echt geen zak uit.

Vrijwel elk algoritme kan beduidend sneller worden gemaakt, met een lagere footprint wat betreft geheugengebruik, maar meestal gaat dit zwaar ten koste van de onderhoudbaarheid en begrijpelijkheid. Een simpel sorteer algoritme kan iedereen snappen, maar de echte snelle algoritmes zijn zwaar ingewikkeld. Maar wel sneller. Simpel de juiste componenten kiezen is veel belangrijker dan welke taal je kiest. Bubble sort blijft traag, of je het nu schrijft in C++ of in Python.

De taal maakt wel degelijk uit. In sommige talen is een efficiente oplossing simpelweg onmogelijk. Dit heeft te maken met het ontwerp van de taal.

Je maakt allerlei aannames die M.I. geen stand houden in de echte wereld. De meeste serieuze programmas die ik ken doen meer dan de standaard componenten gebruiken. Bovendien worden de meeste standaard componenten in de taal geschreven waarvoor ze gemaakt zijn. Traagheid van de taal zit dus ook in de componenten.

Je argument over algoritmes is leuk, maar nutteloos. Je zegt eigenlijk dat een goed algoritme sneller is dan een slecht algoritme... wel duh, ik zie niet wat dat met de taal te maken heeft. Als ik een hybrid quicksort met three way partitioning in C++ implementeer is die toch echt een stuk sneller dan in Ruby. Dit is niet alleen een gevolg van de compiler/VM technologie, maar ook van de (on)mogelijkheden van de taal.

Ik kan je op een blaadje geven dat over een array lopen in C _altijd_ sneller is dan in PHP, puur omdat de PHP versie meer werk moet doen vanwege het ontwerp van de taal (elke array is intern een hashtable).

[Reactie gewijzigd door naikon op 11 december 2010 05:21]

Wat de poster boven u bedoeld is dat de traagheid van een programma voor het grootste deel aan de programmeur ligt. In de praktijk blijkt nu eenmaal dat de meest vertragende factor de programmeur zelf is. Er kan een hoop gewonnen worden door code zo efficiënt en goed mogelijk te schrijven en dat gebeurt vaak niet. Ik wil hier trouwens niet zeggen dat dit gebeurt omdat ze dat niet willen. Vanwege tijdsdruk/andere bedrijfsbelangen kan het gewoon soms niet.

[Reactie gewijzigd door MaestroMaus op 11 december 2010 11:31]

Ruby en python zijn zeer zeker niet beperkt, als je al kan spreken van beperkte talen dan zou het eerder Java zijn. Maar dat woord zegt niets, in elke programmeertaal kan je alles doen wat je in elke andere programmeertaal kan. Er zijn een paar uitzonderingen zoals drivers schrijven, maar daar gaat het hier niet over.

De vraag is eerder hoe geschikt een taal is voor complexe projecten. Ruby en python worden soms beschreven als scripttalen omdat je er eenvoudig en snel scripts in kan schrijven. Ze zijn echter ook geschikt voor grote, complexe projecten. Er wordt al gigantisch veel daarvan in die talen geschreven, twitter bijvoorbeeld is voor een groot deel ruby code. Voor php geldt dat niet.

Java is (gedeeld met C) wel de meest gebruikte programmeertaal in het bedrijfsleven dus wat dat betreft valt er wat voor te zeggen dat Java gedoceerd wordt.

Hangt van je doel af. Als je gewoon klaargestoomd wil worden om een codemonkey voor een baas te worden moet je inderdaad nadoen wat de rest ook al kan.

Stel dat je iets aan het leren bent en iets wil weten, dan zal je eerder naar talen kijken die je in staat stellen grote dingen te doen. Je kan bijvoorbeeld een Java VM schijven in C++, maar zonder C(++) kan je geen Java VM maken. (Dat kan natuurlijk wel, maar ter illustratie doen we even alsof Java op C drijft)

Dan heb je nog assembly en de scripttalen, en de kleinere talen en oudere talen (lisp, haskell, D, G, enz enz) die misschien voor je doel een stuk beter werken. Misschien kan je heel goed typen en heb je een zeer goede manier van denken, en werkt dat het beste met Forth, dus dan ga je alles in Forth schrijven, en kan je daar alles wat je wil doen mee doen.

Als een HBO je Java oplegt, of C, of Microsoft-only crap, dan is dat te snappen, maar op een Uni mag ik er toch van uit gaan dat je een breed scala aan talen gepresenteerd krijgt om wat basiskennis over op te doen, alvorens je meteen een of ander "standaard" dingetje leert wat gewoon bij de massa hoort.

Vaak zijn echt goede programmeurs auto-didact, om dat ze zelf gekozen hebben, en zelf alle motiviatie hadden om iets te leren, en vaak ook grondig te werk gingen bij het leren, ontwerpen en de meest curieuze dingen uit de verste hoeken van de taal weten te halen. De ontwerppatronen die ze tegen komen en nieuwe dingen die ze leren komen veel beter geintegreerd terug in hun werk, en de software is vaak ook stukken sneller, onderhoudbaarder en logischer (om dat ze geen compromissen door te weinig kennis hoeven te maken).

je hebt over ruby/python en java... dat is hetzelfde een intel core i7 adviseren voor een groot bedrijf terwijl ze toch allemaal xeons nemen?

Als studententaal is Java erg geschikt, omdat het nogal strikt is met syntax en typing, en alles expliciet moet worden gedefinieerd. Je kan er heel goed het klassieke OOP principe met al zijn eigenschappen mee uitleggen (inheritance, polymorphisme, dynamic binding, etc.), en je wordt overal op de vingers getikt als je iets fout doet.

Dus als taal om de principes mee te leren is het perfect eigenlijk. Dat je later misschien over moet op een andere taal in het bedrijfsleven is ook niet zo heel erg, de meeste taalconstructies zijn hetzelfde en dus moet het geen probleem zijn om een iets andere syntax eigen te maken en de unieke eigenschappen van de taal aan te leren. Voor een dergelijke vaardigheid word je tenslotte opgeleid

Bij Technische Informatica kregen we ook een vak Programmeertalen, waarin de achtergrond en fundamentele eigenschappen van de talen door de jaren heen werden uitgelegd... als je dat weet, kan je in principe elke taal vrij snel eigen maken.

[Reactie gewijzigd door Sfynx op 10 december 2010 17:30]

Aan de andere kant, Java is niet echt leuk om mee te beginnen. Daarbij leer je maar een heel beperkt scala aan programmeertechnieken omdat Java zo eenzijdig is. Ik snap wat dat betreft niet dat universiteiten niet allang zijn overgestapt op python als eerste taal. Misschien is het gewoon academische traagheid en gaat dat nog gebeuren.

Ik ben geen Java programmeur en lees er alleen zijdelings af en toe eens wat over. Maar heb ik het goed als ik de conclusie kan trekken, aan de hand van dit artikel en wat artikelen van de afgelopen maanden, dat er zich een splitsing aan het vormen is binnen het Java wereldje

Oracle wil geld verdienen met Java. Ze willen eerst en vooral dat er geen onafhankelijke Java versies mogen gebouwd worden (vroeger was er bijvoorbeeld Blackdown voor Linux maar ook Apache, IBM en Microsoft hebben hun eigen Java implementaties en compilers gebouwd). Daarnaast wil Oracle een 'betaalde' versie van Java verspreiden en een soort 'demo' versie van Java. De Java puristen willen echter een open specificatie die kan geïmplementeerd worden door iedereen.

Oracle doet echter hetzelfde met Solaris. Ze sluiten Solaris weer op en beginnen weer met Solaris Express waar enkele jaren al vanaf gestapt was (met OpenSolaris als het gevolg).

Wel interesant dat Microsoft's .NET (toch een directe tegenhanger van Java) nu opener is als Java zelf, terwijl .NET niet open-source is, mag je wel je eigen interpreters en dergelijken maken voor .NET. (Mono is daar een goed voorbeeld van). .NET heeft een ECMA/ISO specificatie. Wel is het zo dat sommige delen van .NET nog onder patenten beschermd zijn.

Achja misschien zien wel volgend jaar dus een .NET runtime van apache .

Interessante link: http://en.wikipedia.org/w...e_Java_and_.NET_platforms

[Reactie gewijzigd door roy-t op 10 december 2010 16:42]

Welke taal zal de opvolger worden? Python is open net als Google Go. Helaas is python niet static typed en Google Go niet OO zoals Java en C# dat zijn. Aan de andere kant heeft Google Go de potentie efficiënter te draaien dan C# of Java ooit zouden kunnen. En wordt er beter gebruik gemaakt van design patterns (niet zoals je in OO talen zou verwachten, Go heeft geen inheritance). Weet iemand nog een taal in de buurt van C# of Java die de moeite waard is?

Aan de andere kant heeft Google Go de potentie efficiënter te draaien dan C# of Java ooit zouden kunnen.
Ik vind dit nogal een bold statement: waarom zou dat zo zijn? Uiteindelijk wordt alles toch naar machinecode vertaald? Waarom zou de grammatica van Go dusdanig zijn dat de machinecode gegenereerd door een GO compiler de facto efficienter zijn dan de code gegenereerd door een JVM aan de hand van Java Bytecode?

Go compileer je naar machinecode en die voer je uit. De JVM of CLI moet dit nog runtime doen. In andere woorden Go heeft geen VM nodig. Go moet daarom wel voor elk platform gecompileerd worden, in tegenstelling tot VM talen, maar is daarmee binnen een fractie van een seconden klaar, dat weer in tegenstelling tot C of C++.

Ik wilde me al een tijdje in Java of C# verdiepen maar al dat gesloten gedoe staat mij niet aan. Daarom zoek ik een andere taal die enterprise ready is. En Go lokt me enorm, het is jammer dat het nog niet zo lang bestaat, maar het heeft zeker potentie. Python is een mooie taal. Het is alleen nog niet efficiënt genoeg (misschien dat PyPy verandering brengt, maar daar wil ik niet op wachten).

Nu Java op slot en grendel wordt gezet door Oracle vraag ik me af wie de opvolger wordt. Ik zie mijzelf best Go of Python programmeren voor mijn Android mobieltje als Google dat mogelijk gaat maken met een mooie SDK.

Welke taal zal de opvolger worden?

Een hele goede vraag.

Zeker voor de enterprise achtige omgevingen zijn er weinig (geen?) alternatieven voor Java. Een waardige opvolger moet ook aan een heleboel eisen voldoen. .NET is het zeker niet vanwege de Windows-only status. C++ is te low level, Python & Ruby zijn niet statically typed en Python heeft een vrij zwak (niet expliciet genoeg) OO-model vind ik, bovendien is de performance van beide talen nog niet goed genoeg.

Een opvolger moet op zijn minst automatisch memory management hebben, een zeer krachtige standard library, statisch getyped en OO zijn. Er moet ingebouwde support voor threading zijn. Applicaties in die taal moeten op 1 of andere manier in een geclusterde omgeving eenvoudig te beheren zijn met goede monitoring tools. De taal moet platform onafhankelijk zijn.

Overigens is een gecompileerde taal (Go, C++) niet per definitie sneller dan een just-in-time gecompileerde taal (Java/.NET).

Mono is geen goed voorbeeld en als je de details omtrent de patent voorwaarden zou bestuderen zou je dat ook zien. MS heeft een belofte niet aan te klagen voor de patenten die het over .NET heeft. maar de voorwaarden daarvoor zijn streng, ingewikkeld en kunnen veranderen wanneer dat MS uitkomt.

Hoewel Oracle Java wellicht aan het opsluiten is is het nog lang niet zo ver dat Java geslotener is dan .NET en dat zal voorlopig ook niet gebeuren. Voor Java kun je nog altijd de Open Source OpenJDK downloaden en zijn wel alle 'echte' implementaties (dus niet Dvorak of J#) volledig met elkaar compatible, terwijl Mono bepaalde onderdelen van .NET niet mag implementeren en je dus lang niet alle .NET applicaties op Mono kunt draaien.

Dat is nu ook juist het hele probleem hier.
Oracle mag wel zelf een eigen JVM implementeren in OpenJDK, maar andere bedrijven zoals ASF mogen dat niet meer.
Gezien de opzet van Java is het kunnen maken van een eigen JVM erg interessant voor sommige bedrijven.

Oracle mag wel zelf een eigen JVM implementeren in OpenJDK, maar andere bedrijven zoals ASF mogen dat niet meer.

Oh nee? IBM brengt er anders ook eentje uit.

terwijl Mono bepaalde onderdelen van .NET niet mag implementeren en je dus lang niet alle .NET applicaties op Mono kunt draaien.

Heb je daar wat meer info over of een link?

Ik kan 123 geen link uit de hoed toveren maar dit is een algemeen bekend feit. Ik kan dat dus wel voor je beamen (voor wat het waard is).

Corrigeer me als ik het verkeerd heb, maar een ECMA/ISO specificatie maakt iets géén open standaard.

[Reactie gewijzigd door MaestroMaus op 10 december 2010 17:00]

Dat zal bij Apache nooit gebeuren, die zijn heel open, anders wordt het geen Apache-project. Dat betekend dus dat het patenten gezeur van .Net niet in aanmerking komt.

Oracle is voornamelijk is een zeer sterke/agressieve commerciële weg ingeslagen met de producten van Sun. Het koste zelfs een dreigement van EU voor het behoud van MySQL.

Nu is dat het volste recht van Oracle, maar als al je belangrijkste partners één voor één de brui aan geven, kan je wel eens nadenken of je goed bezig bent.

Dan maar geen Oracle. IBM had nog een leuke database dacht ik, dus als er iets groots en duurs nodig is krijgt dat bedrijf het geld wel. En verder kan je nog met postgres werken tot dat je daar uit groeit. MSSQL werkt niet op professionele architecturen dus daar houdt het ook op, en dan heb je alles wat groot genoeg kan zijn zo'n beetje op.

Om uit Postgres te groeien moet je wel heel goed je best doen!
Skype maakt er onder andere gebruik van met een aardig dozijn aan servers.

En er is ook de commerciële versie van Postgres, EntepriceDB wel de zelfde functionaliteit bied als Oracle alleen tegen veel lagere prijs.

MySQL is geforked omdat zijn maker Monty Widenius niet blij was met de overname van Oracle en Sun.

Nog een interessant gevonden over dit hele verhaal.
http://news.cnet.com/8301-13505_3-10033614-16.html

Bekend probleem van open-source projecten (geen rant) is inkomsten, je wilt iets maken dat kost geld en omdat het allemaal open is het moeilijker om aan geld te komen dus ga je commerciële ondersteuning bieden en daar geld mee (proberen te) verdiener of donaties van mensen vragen. Maar dat is geen garantie voor het voortbestaan.

Gelukkig zijn er ook bedrijven welk (enigszins) belangeloos meewerken aan de ontwikkeling, denk maar aan de Linux Kernel.

Sybase Adaptive Server Enterprise (ASE)?

IBM had nog een leuke database dacht ik,

DB2 is inderdaad een heel leuke database, draait op heel veel verschillende platforms.

Oracle is voornamelijk is een zeer sterke/agressieve commerciële weg ingeslagen ..

Nou, die weg bewandelen ze al een poosje.
als in: Ik ken ze niet anders.

Maar ja waarheen, Oracle bezit nu alle rechten van Sun, en hebben besloten dit zo gesloten mogelijk aan te bieden, net zoals eerdere Open Source projecten die ze opgekocht hebben. Walgelijk bedrijf

Oracle zet bij Java gewoon de lijn voort die Sun al sinds 2006 hanteert. Er is geen nieuw Oracle beleid te zien.

Toch wel toevallig dat, sinds Oracle Sun overnam, Open Office geforked is en nu Apache uit de JCP stapt, wat voor de Java wereld toch wel een enorme 'big deal' is. Verder is MySQL ook geforked sinds de overname door Oracle, wat toch suggereert dat er wel iets aan de hand is.

Het artikel zegt ook:

"De stemming was de laatste kans voor de commissie om te tonen dat ze het Java Community Process als open-specificatieoverleg willen verdedigen en om te demonstreren dat de geest en de letter van de wet ertoe doen"

Wat er dus aan de hand lijkt te zijn is dat het officiele beleid wellicht weinig gewijzigd is, maar het beleid in de praktijk als enorm beklemmend wordt ervaren door Open Source ontwikkelaars.

Onder Sun lag het al jaren stil door allerlei redenen. Nu wil Oracle stappen ondernemen en zijn enkele partijen niet mee eens.... Maar het is wel dezelfde koers die Sun voert behalve ze willen en gaan door ipv jarenlang stil zitten.

Dat Apache voor Harmony geen licentie krijgt is niets nieuws, Sun wou ook nooit een licentie afgeven. Oracle zelf wilt alle effort in Open JDK stoppen wat ik erg toejuig zodat de JVMs ook meer naar elkaar groeien en meert vaart gemaakt kan worden.

[Reactie gewijzigd door jDuke op 10 december 2010 17:28]

Ze willen vooral ook een gesloten enterprise versie uitgeven.

Ze willen vooral ook een gesloten enterprise versie uitgeven.

Wat in Opensource land de normaalste zaak ter wereld is.

Op verschillende sites las ik iets over Dalvik van Google (http://en.wikipedia.org/wiki/Dalvik_%28software%29, als alternatief voor Java. Ik kan het artikel niet meer vinden, maar sommige analysten denken dat dat in een stroomversnelling kan komen, wanneer het eenmaal volledige open source is.

Dalvik is alleen een VM (Virtual Machine). Dat maakt nog geen Java, verre van zelf. Alle standaard classes en functionaliteiten die daar in zitten maken of kraken een Java implementatie.

Oracle probeert het hele gebeuren geslotener te maken, waarschijnlijk omdat op die manier oss implementaties van VM's niet meer gecertificeerd kunnen worden en er dus (kunstmatig) minder concurrentie voor sommige van oracles eigen producten is.

Ik snap die oproep van oracle ook niet echt, als ze zich gewoon aan de afspraken gehouden hadden dan was er niemand opgestapt, en dat is ook de enige manier waarop de apache foundation kan worden binnengehouden (dat weet oracle natuurlijk ook wel, die doen gewoon net alsof om de indruk te wekken dat ze redelijk zijn)

Adam Messinger, vice-president ontwikkeling bij Oracle, roept Apache op te blijven

Ik vrees dat je er met een oproep alleen niet komt. Oracle zal, als ze oprecht zijn met toezeggingen moeten komen. Maar dat zal ze waarschijnlijk weer te veel gaan kosten.

Oracle lijkt niet bepaald een zegen voor de Open Source Community. Steeds meer door de communitie gesteunde/opgebouwde projecten worden vakkundig het leven zuur gemaakt.

Opzich is het wel weer goed dat oracle daar voortvarend mee is, nu weet je als oss developer (en eindgebruilker) tenminste dat alles waar oracle zich mee bemoeit niet open zal zijn en weet je van te voren welke beperkingen er zullen zijn, dit is imho beter dan lippendiensten te verlenen aan bepaalde waarden en ondertussen tegengestelde acties uit te voeren (zoals een bepaalde grote OS/softwate fabrikant)

Oracle probeert gewoon actiever dan Sun te voorkomen dat er allerlei forks van "Java" gaan ontstaan. Sun heeft ooit ook met succes MS aangeklaagd hiervoor.

Er zijn nu vele verschillende gecertificeerde VMs en dat is niet waar het probleem in zit.
Deze VMs zijn allemaal 100% Compatible en dus geen vreemde forks met een net ff andere werking dan wel syntax van Java statements.

Open-source of niet daar gaat het helemaal niet om. Sun/Oracle is sowieso al ver gevorderd met het volledig open-sourcen van de JDK 7.

Dat Apache en Google lopen te mouwen omdat ze allebei wèl forks van Java hebben gemaakt (Harmony, Android) snap ik best, maar als Java ontwikkelaar vind ik het eigenlijk een prima zaak dat de beheerder van Java er voor strijd dat Java niet langzamerhand in de compabitility hell van bv JavaScript/CSS/DHTML veranderd.

Jammer is echter dat Oracle zo lomp met het hele proces omgaat, en daarmee op dit moment de community en Java in het algemeen vooral schaadt.

Ik zie een verkeerde gedachte gang bij jou, jij gaat er van uit dat oracle dit doet voor de Java compatibiliteit, nee ze doen dit puur voor het geld gewin.
Sun zat al een tijdje met het idee te spelen om een aparte Java Runtime uit te brengen met een veel optimalere garbage collector en andere optimalisaties tegen betalingen en Oracle trekt dit gewoon een streep verder.
Ze gaan zover om zelfs geen concurrentie toe te laten (=monopolie), laat staan afgeleide talen (zoals die van google) die duidelijk stellen dat ze niet in de JRE van Oracle draaien.

Oracle staat al jaren bekend om een agressieve geldhongerige wolf te zijn die elke kans die ze zien zullen uitbuiten om geld te verdienen.

Mijn mening is nog altijd dat EU nooit de overname van Sun had mogen goed keuren, maar ja politiekers zijn altijd wel om te praten zelfs als ze beweren van niet.

maar ja politiekers zijn altijd wel om te praten zelfs als ze beweren van niet.

Om te... praten?

Echt niet. Lobbyen gebeurt met geld, hè. Laten we elkaar geen mietje noemen en het beest gewoon bij de naam noemen.

"...politiekers zijn altijd wel om te praten zelfs als ze beweren van niet."

'zelfs' moet je lezen als 'vooral'. Het enige dat ze doen (of proberen), is de prijs verhogen.

De Linux kernel is ook gewoon volledig compatible met zichzelf, en toch is het open source en werkt iedereen er mee zonder dat een groot bedrijf de baas is. Lijkt me dus niet zo moeilijk om dat ook voor java te kunnen doen.

Gaat lekker daar bij Oracle. Eerst OpenOffice die opstapt, nu Apache. Die overname van Sun gaat toch wat anders dan ze gehoopt hadden denk ik...

En Apple laat de ontwikkeling van een Java runtime voor OSX ook al over aan Oracle zelf:
nieuws: Apple stopt met ontwikkeling OS X-versie Java

Java wordt zo wel een erg Oracle-only project.

Wat Oracle doet, geld proberen te verdienen, is dan mischien legaal. Maar het druist wel tegen het 'open' principe in.
Ik hoop dat er snel een voor bedrijven en gebruikers aanvaardbaar 'open' alternatief gevonden word. Het liefst een geheel vrije TCK (compatibiliteitstest) vrij van toepassingsgebied.
Helaas is Oracle in dat geval dan uitgespeeld, dus zullen ze flink blijven tegenstribbelen.

Wat Oracle doet, geld proberen te verdienen, is dan mischien legaal. Maar het druist wel tegen het 'open' principe in.

Mmm.. Je kunt dus nooit tegelijk open zijn en geld proberen te verdienen? Wat een onzin. De ene kant probeert geld te verdienen door alle concurrentie te weren en hun klanten te vangen met vendor lock-in, de andere is volledig open maar mag geen rooie cent verdienen? Dat is wel een duivels dilemma he?

Ik stel voor dat we zoeken naar een middenweg waar je en geld kunt verdienen en toch je broncode inzichtelijk maakt, je standaarden documenteert en openbaart en waarin je niet op valse wijze probeert concurrentie onmogelijk te maken.

Apache is daar ook helemaal voor en daarom mag je Apache componenten ook expliciet gebruiken in je commerciële product. Je hoeft zelfs de broncode niet te openbaren van jouw stukken code. Geld verdienen is nodig, ook programmeurs moeten eten. De concurrentie op valse wijze buitensluiten is niet nodig.

Oracle is zijn eigen glazen aan het ingooien.
Het zijn gewoon geldbeluste smeerlappen die helemaal vergeten dat zonder community Java nooit zo groot was geworden.

Als zowel Apache als Google er niet mee instemmen dan zal er wat aan de hand zijn.
Beide bedrijven zijn voor openheid en zie hoe succesvol het is.

Met dit soort acties helpt Oracle Java alleen aan een slechte naam en zal het eerder omzet derven dat verdienen is mijn inschatting.

Dan zal nu wel de tijd van de opsplitsing en incompatibiliteit gaan terug komen, Bedankt Oracle.

Wellicht een detail, maar Apache is geen bedrijf maar een (non-profit) stichting. Leden van die stichting (Apache Members) krijgen geen salaris of iets dergelijks.