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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door Dimitri Reijerman, , reacties: 62, views: 14.229 •

Oracle wil zowel een betaalde 'premium'-versie als een gratis versie van de Java Virtual Machines uitbrengen op basis van code uit het OpenJDK-project. Het is nog niet geheel duidelijk welke extra's de betaalde versie te bieden zal hebben.

OracleDe plannen die Oracle heeft met de Java Virtual Machines werden vorige week op het QCon-congres in San Francisco bekendgemaakt. Daar liet Adam Messinger van Oracle weten dat het bedrijf een premiumversie van de JVM zal uitbrengen. Een gratis versie blijft echter ook beschikbaar.

Beide JVM's zijn het resultaat van een combinatie van features afkomstig uit de JRockit VM en de Hotspot VM. Hoewel officieel nog onduidelijk is welke extra's in de betaalversie aanwezig zullen zijn, gaat het volgens The Register mogelijk om verbeterde prestaties ten opzichte van de gratis JDK. Ook zou een betere integratie met andere software van Oracle tot de mogelijkheden behoren. Evenmin is al bekend welke prijs Oracle voor de premiumeditie van zijn JVM zal vragen.

Onderwerpen

Gerelateerde content

Alle gerelateerde content (22)

Reacties (62)

Reactiefilter:-162061+148+25+30
Platte weergave•Sorteer aflopend•Faq
1 2
+1 br men
8 november 2010 13:22
Gelukkig is er nog openJDK en zijn er nog zat andere talen om in te coden.
Betalen om een taal goed te kunnen gebruiken.. bah.
+1 84hannes
@br men • 8 november 2010 13:31
Een paar jaar terug las ik dat er behoefte is in de Open Source wereld aan een Higher Level Programming Language, zoals .Net en Java. Beide hadden toen hun nadelen door het commerciele karakter. Ik vermoed dat er op deze manier geen credits gewonnen worden door Oracle, maar Microsoft ook nog steeds geen favoriet is. Voorlopig zullen grote OS projecten dus wel in C geschreven blijven.

Niet dat Java erg aantrekkelijk is voor bivoorbeeld een kernel, maar voor veel toepassingen zou een wat hogere programeertaal wel fijn zijn denk ik.

@Korben, ik bedoelde met "OS" inderdaad Open Source. Maar een managed OS, ik zie er wel brood in. Hogere programmeertalen staan of vallen namelijk bij het valide zijn van 1 stelling:
``Hardware wordt steeds sneller, een programeur niet''
Dus als de hardware het veel zwaarder krijgt en de software daardoor iets sneller ontwikkeld kan worden, is dat iets waard. Dan moet de gebruikte taal echter wel een beetje eigendom van het collectief zijn. Daar zie ik echt geen kandidaat voor, en zo lang blijft het bij experimentele platformen als JNode en Singularity.

@Jeanpaul145
Java is veel meer dan een objectgeorienteerd multiplatform programeertaal. Java heeft garbage managment, houdt je variabelen beter in de gaten, doet nog het nodige werk runtime etc. Dit alles geld ook voor.net talen, maar daarnaast zou ik geen taal weten die deze features op vergelijkbaar niveau bied (maar ik ben dan ook geen informaticus)

@Antipater
Een groot deel van de talen die je noemt ken ik niet, dus bedankt voor de toevoeging. Scripttalen als Python en Ruby zie ik op een heel ander vlak praktisch zijn dan programeertalen

[Reactie gewijzigd door 84hannes op 8 november 2010 15:20]

+1 Herko_ter_Horst
@84hannes • 8 november 2010 13:44
Say what? Open Source is wel iets meer dan (de) Linux (kernel). Java en C++, C# e.d. zijn het stadium van "behoefte aan" al wel een tijdje gepasseerd, er zijn duizenden Open Source projecten in elk van die talen.

Een operating system in een managed taal schrijven heeft niet zoveel zin zolang er geen hardware is die de bytecode kan draaien (*). Anders heb je namelijk een tussenlaag (VM) nodig, die ook weer ergens op moet draaien.

* van Java weet ik dat er een hardwareoplossing is (geweest) die Java native kan draaien, maar die is nooit populair geworden
+1 Korben
@Herko_ter_Horst • 8 november 2010 13:48
Ik denk dat 84hannes met 'OS-projecten' open source-projecten bedoelt. Overigens kun je een OS wel degelijk (deels) in een managed taal schrijven; je hoeft dan alleen een stukje DMA, bootloader, wat low-level hardware-dingen en een JIT-ter in een non-managed taal te schrijven.
+1 NetForce1
@Herko_ter_Horst • 8 november 2010 13:52
JNode is dus een OS dat geschreven is in Java. Ze hebben een nanokernel geschreven in assembly, en een VM deels in assembly en deels in Java. Een aardig project, maar voorlopig zie ik het nog niet echt gebruikt gaan worden.

[Reactie gewijzigd door NetForce1 op 8 november 2010 13:53]

+1 roy-t
@NetForce1 • 8 november 2010 14:34
Ook Microsoft experimenteert al met managed talen. Er is onder andere een C# gebaseerd OS. Zal nooit gereleased worden, maar de test resultaten waren interessant.

http://en.wikipedia.org/wiki/Singularity_(operating_system)
+2 Jeanpaul145
@84hannes • 8 november 2010 13:47
Als er zo'n behoefte is aan high-level languages, wat is er dan mis met C++ i.c.m. Qt? Toegeven, het is niet WORM (write once run anywhere) maar als je je programma goed opzet kan je zonder aanpassingen aan je codebase het programma compilen voor Linux, Windows en Mac OS X, om nog maar te zwijgen over mobiele platformen zoals MeeGo en Symbian.
De syntax van C++ is, voor zover dat opgaat (C++ ondersteunt een hoop dingen die Java waarschijnlijk nooit zal ondersteunen, zoals operator overloading), redelijk analoog aan Java, wat niet zo moeilijk is gezien de Java ontwerpers de syntax hebben afgeleid van o.a. C/C++.
En anders is er altijd LISP nog; als je je eventjes over de "rare" syntax heen kan zetten blijkt het een zeer flexibele en krachtige taal te zijn.
0 masterpoi
@Jeanpaul145 • 8 november 2010 13:54
WORM = Write once Read Many (CDROM enzo) en heeft niks met programmeertalen te maken, of wordt doorgaans toch niet in die context gebruikt.

http://en.wikipedia.org/wiki/Write_Once_Read_Many
0 SizzLorr
@Jeanpaul145 • 8 november 2010 15:40
Tja als we dan toch gaan recompilen, wat is er dan mis met POSIX?
+1 Goderic
@SizzLorr • 8 november 2010 22:50
AFAIK is Windows niet POSIX compatibel en laat dat nu heel toevallig een vrij groot deel van de markt zijn.
0 BeosBeing
@Goderic • 9 november 2010 15:25
Windows WAS wel POSIX-compatible, althans Windows NT. Daarna hebben ze dat gelijdelijk maar bewust laten vallen, waarschijnlijk omdat ze wel mensen wilden laten overstappen van Unix naar NT, maar niet meer van Windows ... Server 200x naar Unix/Linux toe, dat moet niet te makkelijk gemaakt worden.

De compatibiliteit moet voor Microsoft niet te groot zijn.
0 cibrhusk
@BeosBeing • 10 november 2010 19:51
Volgens mij was dat alleen wanneer je microsoft services voor unix installeerde ?
Ik weet dat deze soms nog wel eens gebruikt wordt, maar de voorkeur is meestal cygwin (de wine tegenhanger voor unix on windows :-p)
+1 Antipater
@84hannes • 8 november 2010 15:12
Python wordt veel gebruikt in open source, en ruby vaak voor web applicaties. Deze talen hebben beide een sterke OS community en zijn higher level dan Java en C#. Er zijn natuurlijk nog meer alternatieven die geschikt zijn - afhankelijk van de eisen, zoals mono, perl, scala, diverse lisps, haskell, D, Vala, Clojure etc. Op zich valt het dus wel mee wat gemis aan programmeertalen betreft :)
+1 redfox314
@Antipater • 8 november 2010 21:30
python higher leven dan Java of C# vind ik toch een gedurfde uitspraak. Ik vind een indeling in high level en higher level al vreemd. Aan welke criteria voldoet python dan wel waar java niet aan voldoet om een higher level te zijn?
+1 wheez50
8 november 2010 13:26
Na OpenOffice wordt de volgende geldbron geprobeerd aan te boren: Daaag Java-van-Oracle...

Als ze er al mee wegkomen zal binnen no time de gratis versie ofwel een slak zijn, ofwel bloatware/adware...
+1 buzzin
@wheez50 • 8 november 2010 13:32
Even ter informatie: Er is altijd al een betaalde versie geweest van openoffice.org, namelijk star office. Oracle is daar niet mee begonnen.
+1 i-chat
@buzzin • 8 november 2010 14:07
payware en freeware kunnen prima naast elkaar bestaan, maar op het moment dat je patches (en dan heb ik het dus niet over features) wel in je eigen versie en niet in de free versie verbeterd, gaan er dingen haperen.


ik denk dat oracle daar zo'n beetje van werd beschuldigd (gokje), als dat nu ook met java gaat gebeuren zullen we als de donder op zoek moeten naar een java alternatief het probleem is namelijk dat andere java (byte code) implementaties nu al door oracle de nek worden omgedraaid.

[Reactie gewijzigd door i-chat op 8 november 2010 14:08]

0 Ramoonus
@buzzin • 8 november 2010 14:14
IBM heeft gelukkig een gratis OpenOffice gezant
+1 Mellow Jack
@wheez50 • 8 november 2010 14:01
Dus jij weet nu al wat het verschil is tussen de betaalde en de gratis versie? Misschien nemen ze het oude open source business model wel aan waardoor ze alleen geld vragen voor support en dat premium noemen (ik verwacht het niet hoor maar het is een mogelijkheid)
+2 Cloud
8 november 2010 13:31
Ik kan me niet voorstellen dat dit soort bijzondere initiatieven goed zijn voor de Java community. Ik ben geen expert in Java maar ik voel een beetje een Linux situatie aankomen, waarbij je dus meerdere VM's hebt. De ene betaald, de ander niet. De ene compatible met dit, de ander niet. Precies ook het (een van de) probleem van Linux; simpelweg teveel keuze. Als je het aantal Java-applicaties onder de gewone gebruiker wilt verhogen dan lijkt me dit toch vrij destructief? Of is dat geen doelgroep meer van het eens zo mooie Java?

Als je dit dan vergelijkt met het .NET framework; toegegeven ze lopen op Linux/Mac wat achter met de ontwikkeling, maar er is maar één framework. Meerdere versies ja, maar er is verder géén keuze.

Ik wil dit niet in een Java vs .NET framework discussie laten verzanden, maar het verschil mag duidelijk zijn. Wat is de gedachte van Oracle achter dit alles? :? Naast meer geld verdienen dan.

[Reactie gewijzigd door Cloud op 8 november 2010 13:32]

+1 arjankoole
@Cloud • 8 november 2010 13:36
Ik snap ook niet waarom Oracle hun eigen markt zou willen fragmenteren. het moge toch duidelijk zijn dat dat het laatste is wat je wilt.

vooral als straks blijkt dat niemand die betaalde versie wil, en ze dus steeds meer dingen uit de gratis editie naar de betaalde versie gaan hevelen, in een wanhoopspoging dat op te krikken. ( dat is geen gekke voorspelling, heus )
+1 i-chat
@arjankoole • 8 november 2010 14:09
aan de andere kant ... verdeel en heers??
+1 snirpsnirp
@i-chat • 8 november 2010 15:17
Ik geloof niet dat Philippus ooit in zijn hoofd had dat je jezelf moest verdelen om te heersen.
+1 OddesE
@snirpsnirp • 8 november 2010 17:37
Touche.

Zomaar overhevelen van spullen uit de gratis versie is wel degelijk een gekke voorspelling aangezien alles in de Open JDK Open SOurce is en dus niet zomaar ineens gesloten kan worden. Wel kan Oracle natuurlijk besluiten om toekomstige versies niet langer als Open Source te releases maar dan komt er wel een fork van de OpenJDK. :)
+1 Rizon
@Cloud • 8 november 2010 13:37
Er bestonden al honderden JAVA VM's voor Oracle hier mee kwam hoor. Ze maken er nu enkel eentje extra.
+1 Cloud
@Rizon • 8 november 2010 13:40
Ik wist dat er meerdere waren, alleen niet honderden. Maar dan nog blijft m'n punt staan, al zou ik het misschien iets anders moeten formuleren:

Waarom een extra VM introduceren als je m.i. veel beter kan werken aan één VM die voor alles en iedereen geschikt is?

Zoals arjankoole ook al zegt, marktfragmentatie lijkt mij echt niet bevorderlijk voor de positie van een taal.
+1 Rizon
@Cloud • 8 november 2010 14:07
Je bewijst enkel dat je punt niet geldig is. Jijzelf kent er maar één, dus je hebt makkelijk gekozen. Anderen kennen wel de extra mogelijkheden en kunnen er gebruik van maken.

Hetzelfde werkt zo bij Linux en zowat al de rest in de wereld. Zolang fabrikanten niet alles naar eindgebruikers pushen, is er geen verwarring. En als er verwarring is, dan heb je hun maar even iets aan te leren. 'T zijn geen domme apen.
+2 merethan
@Cloud • 8 november 2010 14:07
Microsoft, IBM, en Sun hadden allemaal een eigen JVM. En dan zijn er nog talloze geweest voor bijvoorbeeld mobieltjes etc.

Een aardig lijstje is hier te zien.
+1 YopY
@Cloud • 8 november 2010 14:39
Waarom een extra VM introduceren als je m.i. veel beter kan werken aan één VM die voor alles en iedereen geschikt is?
Omdat dat gewoon niet mogelijk is. De keuze voor een specifieke VM is afhankelijk van wat je ermee doet. De ene VM heeft een beter / sneller geheugenbeheer, de ander is weer beter met multithreaded applicaties, en op een bepaald moment moet je voor één van die twee kiezen - het ene heeft invloed op het andere.

Voor de meeste toepassingen is de standaard JVM van Sun / Oracle voldoende, maar hoe meer je ermee doet, hoe specifieker je (performance, security) eisen worden - en dan kan de standaard JVM niet meer voldoen.

Er is vast wel ergens een goed overzicht van de verschillende JVMs die er zijn, evenals hun voor- en nadelen.
+1 jwvirtual
@Cloud • 8 november 2010 13:39
Er zijn altijd al meerdere VM's geweest (Sun, Oracle, IBM,...). Het aantal wordt nu dus zelfs één minder. Het gevaar dat je schetst wordt dus kleiner in plaats van groter.

Ik heb erg goede ervaringen met HotSpot van SUN. Het idee dat die nu gaat wordt samengevoegd met een andere soort spreekt me niet heel erg aan. Maar misschien is dat koudwatervrees.
+1 blouweKip
@Cloud • 8 november 2010 16:11
Precies ook het (een van de) probleem van Linux; simpelweg teveel keuze.
Maar wel compatible onderling in 99,9% van de gevallen, keuze is iets goeds en het probleem is ook niet de keuze maar de vendor-lockins welke de marktwerking frusteren (marktfalen)
0 - peter -
@blouweKip • 8 november 2010 16:53
Keuze is leuk, maar teveel keuze is overweldigend en kan daardoor juist een minpunt zijn. 't is maar net wie je doelgroep is.
0 cibrhusk
@Cloud • 10 november 2010 20:00
Je vergelijking met Linux is volgens mij niet terecht, maar als je distributies bedoelt die linux combineren met gnu en andere open source dan misschien wel. Hoewel er eigenlijk geen compatibiliteit problemen zijn tussen de distro's als je goed programmeerd - wel versie verschillen van dependenties. Als je je programma dependent maakt (wat slim is qua performance) dan moet je hier dus ook rekening mee houden. Het is altijd nog mogelijk om de boel static te maken (wat al snel weer zijn eigen problemen oplevert, als alles static aan t worden is).

Verder ben ik normaliter niet zo bang voor een scheiding commercieel vs open, maar wel bang voor het gedrag van oracle dat ik daarbij verwacht.
Ze zullen naar mijn verwachting namelijk de opensource versie bewust opzettelijk hinderen in zijn ontwikkeling (zaken niet doorvoeren of lang tegenhouden, zoals bij open office).
Daarmee kun je je commerciële snel beter laten presteren. Het hangt er dus vanaf wat het management beslist omtrent het releases van code van commercieel richting opensource.
Ook hier is eigenlijk een onafhankelijk java foundation nodig, wat mij betreft in elk geval.

Maar laten we wel wezen, echte compatibiliteit problemen mogen niet optreden wanneer de java standaarden gehanteerd blijven. En de ontwikkeling van java moet dan ook primair op die standaard gericht zijn, daarna pas op de technische implementatie. Ik heb ook zelden of nooit problemen met mijn java apps als ik ze in een andere java vm stop.

[Reactie gewijzigd door cibrhusk op 10 november 2010 20:04]

+1 Rob Coops
8 november 2010 13:33
De verbeteringen (op basis van een presentatie van Oracle af gelopen week) zullen waarschijnlijk ook een mogelijkheid bevatten om met meer dan 24 threads te gelijk te werken in de betaalde versie. Op dit moment is dat de limiet en met een processor die op dit moment z'n hand niet omdraait voor 64 threads is dat natuurlijk een beetje vreemd.

Ook ga ik er van uit dat een betaalde versie inderdaad een betere hotspot optimalisatie heeft en andere verbeteringen met zich mee zal brengen. In principe zou ik zeggen een gewone gratis JVM voor de desktop markt en kleine server setups en een betaalde versie voor de many core grote servers war performance ook best wel wat mag kosten.
+1 Herko_ter_Horst
@Rob Coops • 8 november 2010 13:48
Dat 24 threads de huidige limiet zou zijn is onzin. Ik kan (gegeven voldoende geheugen) makkelijk honderen, zoniet duizenden threads starten. Een operating systeem kan wel limieten opleggen aan hoeveel native threads een proces (en dus ook een Java applicatie) mag starten.

Een mogelijke beperking zou het aantal processor cores kunnen zijn waar de JVM gebruik van kan maken.

[Reactie gewijzigd door Herko_ter_Horst op 8 november 2010 13:51]

+1 YopY
@Herko_ter_Horst • 8 november 2010 14:40
Misschien bedoelt hij 24 threads die daadwerkelijk tegelijkertijd draaien? Want je moet ook honderden, zo niet duizenden cores hebben om die echt parralel (ipv scheduled) te laten draaien.
+1 latka
@YopY • 8 november 2010 16:25
Hmm, dan ben ik heel beniewd naar die presentatie want afaik is onder Linux een Java thread een Linux thread en daar zitten geen beperkingen op (1-1 threading).
0 morrowyn
8 november 2010 13:36
Vooral het Het is nog niet geheel duidelijk welke extra's de betaalde versie te bieden zal hebben is erg grappig.

Doet me een beetje denken aan iemand die een eigen bedrijf wilt beginnen,maar nog niet weet wat en hoe hij er geld mee wilt verdienen.
+1 B-Man
@morrowyn • 8 november 2010 13:40
Met dien verschille dat Oracle waarschijnlijk al bepaald heeft wat ze gaan doen, maar dat niet in een keer aan de markt willen communiceren. Dat het in dit geval nog niet duidelijk is zegt bar weinig over de strategie van Oracle, maar over het gebrek aan publieke informatie hierover.
+1 dvogel
@morrowyn • 8 november 2010 13:40
Dat juist niet... ze weten wel dat ze er geld mee willen verdienen maar nog niet precies waarmee.
+1 HAL 9000
@morrowyn • 8 november 2010 15:18
Tweakers redacteur weet het niet != Oracle weet het niet.

Goed mogelijk (zeer waarschijnlijk) dat ze het intern al wel redelijk goed weten, maar dat ze dit niet communiceren naar buitenaf (tot het wat meer af is, of totdat de marketing slides klaar zijn ;) )
+1 NetForce1
8 november 2010 13:39
Beide JVM's zijn gebouwd op basis van de JRockit VM en de Hotspot VM, twee projecten van het voormalige Sun.
JRockit was niet van Sun, maar van BEA wat al eerder is overgenomen door Oracle (http://en.wikipedia.org/wiki/JRockit)

Overigens zijn er allang Java VM's waar je voor moet betalen, JRockit was vroeger niet gratis volgens mij, en Azul Systems heeft onlangs ook een betaalde VM uitgebracht (Zing).

Ik zie het probleem niet zo van een betaalde VM, zolang er maar geinvesteerd blijft worden in de gratis versie, probleem is alleen nu dat Oracle beide producten in huis heeft terwijl Sun zich alleen focuste op het gratis Hotspot.
+1 dvogel
8 november 2010 13:41
zolang je de software van de betaalde versie maar wel kan draaien op de gratis versie, dan vind ik het minder erg.
+1 sys64738
@dvogel • 8 november 2010 13:46
Wat was de slogan van Sun ook al weer: Write once, run anywhere.

Zal mij inderdaad benieuwen hoe lang ze dat volhouden met deze ontwikkeling.
+1 Herko_ter_Horst
@sys64738 • 8 november 2010 14:19
Zoals gezegd: er waren al lang meerdere VMs (betaald en onbetaald). Deze ontwikkeling gaat niet ineens verandering brengen in WORA.

Niet dat ik de splitsing een goede zaak vind...
+1 YopY
@sys64738 • 8 november 2010 14:41
Ligt er maar net aan - kan me goed voorstellen dat de beide JVM's alle Java software draaien, maar dat de betaalde bijvoorbeeld meer threads of geheugen aan kan sturen (alhoewel dat meer een instelling is dan een daadwerkelijke feature)
+1 YopY
8 november 2010 14:35
Beuh, dat zal wel betekenen dat de gratis versie afgekapt wordt - limieten aan aantal threads, geheugen, dat soort grappen. Dan moeten alle Java webapp hosters wel over naar de betaalde variant. Nee dank u.
+1 ACM
@YopY • 8 november 2010 14:41
Of met openjdk/icedtea (blijven) werken ;)
0 bozotheclown
8 november 2010 14:59
Ik had al niks met Java en ga er als dit de bedoeling is zeker niet meer mee krijgen. Ze doen maar wat ze niet laten kunnen.
1 2

Op dit item kan niet meer gereageerd worden.