Red Hat ontfermt zich over OpenJDK 6
Red Hat heeft het stokje van Oracle overgenomen bij het ondersteunen van OpenJDK 6, de opensource-implementatie van Java 6. Het softwarebedrijf hoopt zo zijn klanten te kunnen blijven bedienen met beveiligingsupdates nu Oracle geen updates voor Java 6 zal uitbrengen.
Volgens Red Hat zal het besluit om de OpenJDK 6-community te gaan aansturen zorg dragen voor verlenging van de ondersteuning van het softwareplatform. Hierdoor krijgen softwaredevelopers die Java 6 gebruiken nog steeds updates aangeboden nadat Oracle de publieke updatecyclus voor Java 6 na het uitbrengen van Update 43 officieel zal staken. Oracle zal alleen nog voor Java 7 beveiligingsupdates uitbrengen of uitsluitend tegen betaling Java 6-gebruikers nog twee jaar ondersteunen.
De stap van Red Hat om de leiding te nemen in de doorontwikkeling en ondersteuning van OpenJDK 6 komt niet onverwacht. Veel zakelijke klanten van het bedrijf gebruiken software die afhankelijk is van OpenJDK 6, zoals JBoss, terwijl het bedrijf voor ontwikkelaars het opensource Java-ontwikkelplatform IcedTea biedt.
Het zou voor Red Hat relatief eenvoudig zijn om toekomstige updates voor Java 7 door middel van backports ook door te voeren in de code van OpenJDK 6. Hoe lang Red Hat nog OpenJDK 6 actief zal gaan ondersteunen, is nog niet bekend.
Reacties (42)
Daar ben ik wel enorm blij mee. Ik heb sowieso een veel hogere pet op (pun not intended) van RedHat dan van Oracle. In tegenstelling tot Oracle snappen zij imo wel hoe je met opensource software om moet gaan en dat je er best geld mee kan verdienen. Updates en fixes zullen eerder uitkomen zonder dat de halve community aan de bel moet trekken en de duimschroeven met aandraaien.
RedHat verdient met het ondersteunen van Java 6 niet direct geld...
het is meer zo dat ze zo hun klanten beter kunnen blijven ondersteunen waarbij ze service contracten hebben....
Oracle ziet het als een kosten post, het is software waar ze geld in moeten steken maar wat ze niet kunnen verkopen... kunnen ze opzich ook niets aan doen, die kregen ze erbij toen ze SUN overnamen...
het is meer zo dat ze zo hun klanten beter kunnen blijven ondersteunen waarbij ze service contracten hebben....
Oracle ziet het als een kosten post, het is software waar ze geld in moeten steken maar wat ze niet kunnen verkopen... kunnen ze opzich ook niets aan doen, die kregen ze erbij toen ze SUN overnamen...
Oracle heeft zo ongeveer hun complete DB technologie op Java gebouwd, waarom zouden ze het willen verkopen? Ze hebben juist Sun overgenomen om al die essentiele Java tech binnenshuis te trekken en te voorkomen dat iemand anders ermee aan de haal ging, ze zouden wel gek zijn om de controle aan iemand anders te geven. Uiteraard bouwt Oracle alleen verder aan de delen waar ze (=hun klanten) wat aan hebben, maar als de rest van de OpenJDK leden (IBM, Apple, Red Hat) de oude versies nog willen blijven patchen, dan is dat hun goed recht - dat is precies hoe open source werkt.
[Reactie gewijzigd door Dreamvoid op zondag 10 maart 2013 13:06]
Je verhaal is bijna goed alleen "bouwt Oracle alleen verder aan de delen waar ze (=hun klanten) wat aan hebben" is niet zoals Oracle werkt. Dit had moeten zijn: "bouwt Oracle alleen verder aan de delen waar ze (=hun klanten) het meeste geld mee afhandig kunnen maken".
Oracle is zo mogelijk de ergste in zijn soort (alhoewel IBM en Microsoft er ook wat van kunnen).
Oracle is zo mogelijk de ergste in zijn soort (alhoewel IBM en Microsoft er ook wat van kunnen).
Das natuurlijk logisch, Oracle is een bedrijf, geen nonprofit organisatie. Java is ondersteunende technologie voor hun betaalde produkten, net zoals bv Linux dat is voor Google en IBM, etc. Aan Java zelf valt weinig te verdienen, wel aan de applicaties erop. Maar zonder Java geen applicaties.
[Reactie gewijzigd door Dreamvoid op zondag 10 maart 2013 13:36]
???
Ze hebben bijna alles van SUN wat op sterven na dood was nieuw level in geblazen: Solaris, Sparc, Storage, Servers, MySQL, Java
Ze hebben bijna alles van SUN wat op sterven na dood was nieuw level in geblazen: Solaris, Sparc, Storage, Servers, MySQL, Java
Nieuw leven ingeblazen wel, maar wel op een wat kapitalistischere manier; denk aan het laten verdwijnen van OpenSolaris (en daarmee de open source ZFS code die onder andere in FreeBSD wordt gebruikt), het deels closed source ontwikkelen van MySQL (voor bepaalde functies wel de source openbaren, maar niet de bijbehorende tests die eigenlijk deel uitmaken van de source). Rond Java heerst ook nog een hoop onzekerheid.. mensen zitten gewoon te wachten tot Oracle daar een nare streek mee uithaalt.
Ze houden alleen de verkeerde dingen in leven. Solaris en Sparc zijn niche producten. Ik ken niemand die het gebruikt. En storage leveranciers zijn er al genoeg.
En MySQL en Java op sterven na dood? Dacht het niet hoor. Beiden worden veel gebruikt in de backend op servers. Als Oracle er niets meer mee zou doen is de community groot genoeg dat een ander het houtje wel overpakt, zoals in dit geval RedHat met OpenJDK6.
En MySQL en Java op sterven na dood? Dacht het niet hoor. Beiden worden veel gebruikt in de backend op servers. Als Oracle er niets meer mee zou doen is de community groot genoeg dat een ander het houtje wel overpakt, zoals in dit geval RedHat met OpenJDK6.
@Dreamvoid, de licentiekosten van oracle zijn er op gericht je zoveel mogelijk geld te laten betalen en je zoveel mogelijk te proberen dat je nog meer producten van ze afneemt. Oracle streeft complete vendor lock-in na. Aangezien oracle berucht is voor het sturen van gepeperde rekeningen, is dat uiteraard al helemaal een ongewenste situatie in terecht te komen.
Net zoals IBM, SAP, Microsoft, Google, HP, etc. Welkom in de wereld van de enterprise software vendors...
Niet hun DB technologie (is c of c++) , maar wel hun hele middleware.
Is ook de voornaamste reden geweest om Sun over te nemen, het risico data Java in handen van een concurrent zou vallen was te groot.
Is ook de voornaamste reden geweest om Sun over te nemen, het risico data Java in handen van een concurrent zou vallen was te groot.
Het geeft echter ook wel aan dat hun eigen JBoss afhankelijk is van een verouderde java versie...
Tuurlijk zal er een (geld) reden achter zitten, maar dat wil nog niet zeggen dat het niet een klein beetje nobel is. In de community zal dit toch wel wat goodwill creëren denk ik.
Aantal producten van Oracle is ook nog steeds niet gecertificeerd tegen 7, dus dat is nauwelijks een bezwaar kennelijk 
Oudere JBoss versies ja, JBoss 6 en up werken prima met Java 7. Het mooie van Red Hat is dat ze de oudere enterprise platformen ook gewoon blijven ondersteunen, en daar hoort core Java nu dus ook bij. Ik heb respect voor die mensen.
De huidige JBoss software, draait prima op Java 7 en 8. Het is waarschijnlijk eerder voor bedrijven welke nog hele oude versies gebruiken.
Oracle werkt door aan Java 7, terwijl ze Java 6 aan anderen over laten, dit is precies zoals open source werkt. Hoezo zou Oracle niet weten hoe open source werkt?
OpenJDK is allang niet meer van Oracle alleen, er zitten diverse grote server spelers in dit project (IBM, Apple, Red Hat).
OpenJDK is allang niet meer van Oracle alleen, er zitten diverse grote server spelers in dit project (IBM, Apple, Red Hat).
[Reactie gewijzigd door Dreamvoid op zondag 10 maart 2013 12:53]
Op zich heb je gelijk. Of al die andere partijen vrijwillig mee zijn gaan doen met OpenJDK betwijfel ik sterk. Niet zo lang geleden had IBM bijvoorbeeld een groot aandeel in Apache Harmony, een clean room implementatie van Java. Na flinke druk van Oracle heeft IBM zich uit dat project teruggetrokken. Ik denk dat al die andere partijen meedoen omdat Oracle dat wil en ze afhankelijk zijn van Java. Dit is voor hun de enige optie.
IBM die zich zomaar even laat dwingen?
Je kan samenzweringstheorieen op los laten zolang je wilt, maar m.i. is het gewoon logisch dat de diverse Java vendors zich verenigen in 1 OpenJDK project ipv elk hun eigen JVM te maken. Natuurlijk knokken ze met elkaar om marktaandeel binnen het Java ecosysteem, maar de grote vijand zijn andere ecosystemen van Microsoft en Google. Samen staan ze sterker.
Je ziet hetzelfde bij Linux, waar grote concurrenten als IBM, Novell, HP en Oracle gebroederlijk samenwerken aan 1 opensource OS, niet omdat ze elkaar nou zo aardig vinden, maar omdat er een grotere gezamenlijke vijand rondloopt en hun eigen (Unix) OSsen in hun eentje niet veel potten meer breken.
Je kan samenzweringstheorieen op los laten zolang je wilt, maar m.i. is het gewoon logisch dat de diverse Java vendors zich verenigen in 1 OpenJDK project ipv elk hun eigen JVM te maken. Natuurlijk knokken ze met elkaar om marktaandeel binnen het Java ecosysteem, maar de grote vijand zijn andere ecosystemen van Microsoft en Google. Samen staan ze sterker.
Je ziet hetzelfde bij Linux, waar grote concurrenten als IBM, Novell, HP en Oracle gebroederlijk samenwerken aan 1 opensource OS, niet omdat ze elkaar nou zo aardig vinden, maar omdat er een grotere gezamenlijke vijand rondloopt en hun eigen (Unix) OSsen in hun eentje niet veel potten meer breken.
[Reactie gewijzigd door Dreamvoid op zondag 10 maart 2013 13:30]
Voordat je verder gaat met je conspiracy theory: Apple zit er ook in, en is niet afhankelijk van Java. Apple heeft geen in java geschreven software. Je aluhoedjes verhaal snijdt geen hout.
Jammer alleen dat Oracle nog wel de trademarks op Java bezit: kunnen ze mooi RedHat narren door te verbieden het ding Java te noemen. Java is inmiddels minder een technisch dan een politiek en juridisch platform geworden.
Waarom zou Oracle het erg vinden dat Red Hat de niet-winstgevende oude delen van Java onderhoudt, zeker als RH dat netjes binnen het OpenJDK project doet?
zegt dalvik je iets, een cleanroom variant van java - waar de nodige FUD en rechtzaken om gaan en gegaan zijn.
Er is nogal een verschil tussen aanbieden om als lid van de 'officiele' OpenJDK VM oude code te blijven onderhouden, en op eigen houtje een kloon maken.
[Reactie gewijzigd door Dreamvoid op zondag 10 maart 2013 22:27]
Misschien kan Red Hat samenwerken met Ubuntu?
De default JRE in Ubuntu 12.04 LTS is ook OpenJDK 6. Over 13 maanden verschijnt pas weer een nieuwe LTS release. Het lijkt mij sterk dat Ubuntu tussentijds OpenJDK 7 als default maakt.
De default JRE in Ubuntu 12.04 LTS is ook OpenJDK 6. Over 13 maanden verschijnt pas weer een nieuwe LTS release. Het lijkt mij sterk dat Ubuntu tussentijds OpenJDK 7 als default maakt.
In Ubuntu 12.10 is OpenJDK 7 al de default, dus dat blijft voorlopig zo.
Je overschat OpenJDK6. Uit eigen ervaring weet ik dat je beter OpenJDK7 kan installeren. Draait veel meer software met betere performance. Zelfs software die officieel geen java 7 ondersteund werkt er beter op dan op OpenJDK6. Ik snap niet dat ze die oude troep nog in leven willen houden.
Wat ik mij dus afvraag is hoe relevant Java op Linux nog is eigenlijk. Ja tuurlijk als je op linux Android software wilt ontwikkelen ofzo, maar voor Linux zelf? Een paar jaar geleden was er best veel java spul op linux, maar het meeste is ondertussen vervangen door betere applicaties die gewoon weer in good old C(++) zijn geschreven. Of waar het server-side spul betreft , juist door scripting spul als Node, Twisted, Django etc. M.a.w, er lijkt eigenlijk niet zo veel plek meer voor Java op Linux tussen C(++) aan de ene kant en asynchoon scripting aan de andere kant. Dat gecombineert met de bad-press van de laatste tijd, waardoor security aware mensen de JRE van hun systeem afdonderen, vraag ik mij echt af wat RH bezielt.
Java is een van de meest gebruikte server talen en veel servers draaien op Linux. Dus in die zin is Java nog heel erg relevant op Linux.
Java 'was' een van de meest gebruikte server talen. Nu is Java vooral een veel gebruikt mobiele taal.
Dat is het nog steeds. Tenminste het aanbod van werk wat me wekelijks naar mijn hoofd geslingerd wordt liegt er niet om.
Kan je dat concreet maken? Ik denk namelijk dat je je vergist in hoeveel partijen nog Java draaien in de backend (denk alleen al aan het gebruik van Apache Hadoop) maar ook aan Google Adwords, Gmail, etc. Zelfs Bing van Microsoft heeft voordat Microsoft het kocht op Java gedraait. Dat werd na de overname wel geport naar .Net maar dat was lijkt me meer een politiek verhaal. Daarnaast is .Net met C# in feite MS Java...Een paar jaar geleden was er best veel java spul op linux, maar het meeste is ondertussen vervangen door betere applicaties die gewoon weer in good old C(++) zijn geschreven.
Wat is technisch het verschilOf waar het server-side spul betreft , juist door scripting spul als Node, Twisted, Django etc.
Dat ging puur over Java op de desktop. Je denkt toch niet dat RedHat een zier geeft om Java op de Desktop? Al deze "bad press" ging er allemaal over hoe je de Java sandbox kon omzijlen wat dan gebruikt werd in combinatie met applets (wie gebruikt die dingen uberhaupt nog). Dat is helemaal niet van toepassing bij server applicaties.Dat gecombineert met de bad-press van de laatste tijd, waardoor security aware mensen de JRE van hun systeem afdonderen
Met C(++) heb ik het dus over de golf van desktop apps in Java die we een paar jaar geleden hebben gezien. Instaleer voor de gein maar eens een 5 of 6 jaar oude Linux distro en kijk hoeveel packages de JRE toen als dependency hadden, en vergelijk het maar eens met een recente versie.
Voor de backend zou het kunne dat ik als ontwikkelaar inderdaad niet besef hoeveel apps er nog steeds op Java draaien. Wat ik echter wel zie is dat de laatste jaren de ontwikkeling van nieuwe Linux based systemen voor het overgrote deel gescript worden.
Node.js heeft een tijdje geleden laten zien dat een trage inefficiente taal als JavaScript, puur door gebruik te maken van een asynchroon IO model, voldoende (en vaak beduidend beter dan synchrone multi-threaded Java frameworks) schaalt voor een veelheid van server toepassingen. Met die ontdekking heeft Java grotendeels z'n meerwaarde boven script talen verloren. Vanuit mijn perspectief heeft dat vervolgens een enorme impact gehad op de vraag voor nieuw te ontwikkelen Linux based server systemen.
Voor de backend zou het kunne dat ik als ontwikkelaar inderdaad niet besef hoeveel apps er nog steeds op Java draaien. Wat ik echter wel zie is dat de laatste jaren de ontwikkeling van nieuwe Linux based systemen voor het overgrote deel gescript worden.
Node.js heeft een tijdje geleden laten zien dat een trage inefficiente taal als JavaScript, puur door gebruik te maken van een asynchroon IO model, voldoende (en vaak beduidend beter dan synchrone multi-threaded Java frameworks) schaalt voor een veelheid van server toepassingen. Met die ontdekking heeft Java grotendeels z'n meerwaarde boven script talen verloren. Vanuit mijn perspectief heeft dat vervolgens een enorme impact gehad op de vraag voor nieuw te ontwikkelen Linux based server systemen.
Het aantal packages dat Java als dependency heeft in de door jouw gebruikte distro? Zegt dat niet meer iets over hoeveel Java packages er onderhouden worden bij jouw distro? En hoe zie je dan dingen zoals Azureus en rssowl welke geprecompiled (ie. van Java direct naar machinecode) worden met GCJ waar dus geen Java runtime voor nodig is maar gewoon een executable uitkomt?Met C(++) heb ik het dus over de golf van desktop apps in Java die we een paar jaar geleden hebben gezien. Instaleer voor de gein maar eens een 5 of 6 jaar oude Linux distro en kijk hoeveel packages de JRE toen als dependency hadden, en vergelijk het maar eens met een recente versie.
Java is nooit aangeslagen op de desktop. Zeker niet onder Linux omdat voordat Java geopensourced werd de Java-Trap bestond; Je had altijd een non-opensource JRE nodig om de opensource Java applicatie te draaien. Het gescript van dingen in de Linux desktop is zeker niet ten koste gegaan van Java want Java was daar zowiezo al niet.Voor de backend zou het kunne dat ik als ontwikkelaar inderdaad niet besef hoeveel apps er nog steeds op Java draaien. Wat ik echter wel zie is dat de laatste jaren de ontwikkeling van nieuwe Linux based systemen voor het overgrote deel gescript worden.
Je haalt hier 2 dingen door elkaar. Je hebt het over de taal en de implementatie (interperter van de taal). Een taal anzich kan niet traag zijn. Een taal is een taal. Java gebruikt (meestal) Hotspot als interperter/VM (maar er zijn er meer) en node.js gebruikt altijd V8.Node.js heeft een tijdje geleden laten zien dat een trage inefficiente taal als JavaScript, puur door gebruik te maken van een asynchroon IO model, voldoende (en vaak beduidend beter dan synchrone multi-threaded Java frameworks) schaalt voor een veelheid van server toepassingen.
Kan je me uitleggen wat een "synchrone multi-threaded Java framework" is (liefst een voorbeeld)? Ik denk dat je bedoelt te zeggen dat het makkelijker is om applicaties met veel concurrency te programmeren in node.js dan in Java. Maar dat heeft enkel met de vermeende ontwikkel snelheid te maken en niks met het uitvoeren van de code. Ik zeg vermeend omdat dat persoonlijk is. De een werkt in Java, de ander in Scala, de ander in Node.js of .net met C#, etc.
"Kan je me uitleggen wat een "synchrone multi-threaded Java framework"
In Java, zo'n beetje ieder web framework dat niet op Netty draait. Als je een applicatie maakt die opzich niet zo CPU intensief is, maar wel heel erg IO intensief (heel veel concurrent connections), dan zijn er twee manieren om daar mee om te gaan. Of je gebruikt synchrone operaties i.c.m threads voor de IO afhandeling, of je gebruikt asynchrone IO. Het tweede schaalt een stuk beter en kost minder OS resources. Node en andere asynchrone frameworks (zoals Netty) maken het gebruik van asynchrone IO triviaal, waardoor je simpelweg voor minder centen een IO-wise schaalbare applicatie kunt maken. Dan blijft dus bijvoorbeeld de vraag 'Netty of Node?'. Als je al dik betaalde Java programeurs in dienst hebt moet je vooral Netty pakken, moet je inhuren, dan is Node vermoedelijk een stuk goedkoper.
In Java, zo'n beetje ieder web framework dat niet op Netty draait. Als je een applicatie maakt die opzich niet zo CPU intensief is, maar wel heel erg IO intensief (heel veel concurrent connections), dan zijn er twee manieren om daar mee om te gaan. Of je gebruikt synchrone operaties i.c.m threads voor de IO afhandeling, of je gebruikt asynchrone IO. Het tweede schaalt een stuk beter en kost minder OS resources. Node en andere asynchrone frameworks (zoals Netty) maken het gebruik van asynchrone IO triviaal, waardoor je simpelweg voor minder centen een IO-wise schaalbare applicatie kunt maken. Dan blijft dus bijvoorbeeld de vraag 'Netty of Node?'. Als je al dik betaalde Java programeurs in dienst hebt moet je vooral Netty pakken, moet je inhuren, dan is Node vermoedelijk een stuk goedkoper.
Je bedoelt waarschijnlijk Java NIO (non blocking IO). Daar Netty enkel een framework is om ontwikkelen met NIO makkelijker te maken. Net zoals Apache Mina. Ik ken overigens geen enkel java webframework wat Netty gebruikt. Alle webframeworks liggen op de servlet API in Java (en die is standaard al asynchroon) en worden niet geleverd met hun eigen HTTP server. NIO (en daarmee Netty) is een API om oa async over ruwe sockets te communiceren. Het is een heel low level API welke de meeste Java devs nooit te zien krijgen. Dus als het al gebruikt werd zou het door Jetty, Tomcat,Glassfish ed gebruikt moeten worden. Maar die gebruiken wel NIO maar geen Netty.
Je vergelijkt node.js met Java en gebruikt termen waar je de klok wel van hebt horen luiden maar niet weet waar de klepel hangt. Komt op mij over alsof ik een echo hoor van een node.js sales presentatie...
Je vergelijkt node.js met Java en gebruikt termen waar je de klok wel van hebt horen luiden maar niet weet waar de klepel hangt. Komt op mij over alsof ik een echo hoor van een node.js sales presentatie...
In Java kun je kiezen voor zowel synchrone als asynchrone IO (met NIO). Het schaalt daarmee beduidend beter dan Node.js.Node.js heeft een tijdje geleden laten zien dat een trage inefficiente taal als JavaScript, puur door gebruik te maken van een asynchroon IO model, voldoende (en vaak beduidend beter dan synchrone multi-threaded Java frameworks) schaalt voor een veelheid van server toepassingen. Met die ontdekking heeft Java grotendeels z'n meerwaarde boven script talen verloren
Tuurlijk 'kan' Java beter schalen dan JavaScript en 'kan' Java asynchone IO doen, en kunnen script talen op het synchrone vlak nouwlijks in de buurt komen van Java. Alleen moet je in Node echt heel erg je best doen als je iets synchroon wilt doen, en hey, dat blijkt nu net de clue te zijn om heel eenvoudig heel behoorlijk te kunnen schalen voor IO intensief spul.
Java zit nu gewoon in de positie t.o.v script talen waar C++ een aantal jaren geleden zat t.o.v. Java. Lastiger, duurdere programeurs, langere ontwikkeltijd, ja sneller en schaalbaarder, maar guess what, m.u.v. een paar niche situaties niet waar het uit maakt.
Java zit nu gewoon in de positie t.o.v script talen waar C++ een aantal jaren geleden zat t.o.v. Java. Lastiger, duurdere programeurs, langere ontwikkeltijd, ja sneller en schaalbaarder, maar guess what, m.u.v. een paar niche situaties niet waar het uit maakt.
De Tweakers redactie geeft hier zelf een prima antwoord op:) :
reviews: Tweakers 7: waarom een eigen Java-back-end?
reviews: Tweakers 7: waarom een eigen Java-back-end?
Java wordt vaak gebruikt in de backend. De frontend kan dan best in iets anders geschreven zijn, zoals node.js, ruby on rails, php of django, maar vaak praten ze tegen API services aan, die uiteraard niet in een frontend taal geschreven zijn.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
