Oracle wil met gratis en betaalde JVM-uitvoeringen komen
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.
De 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.
Reacties (62)
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.
Betalen om een taal goed te kunnen gebruiken.. bah.
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
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]
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
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
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.
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]
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)
http://en.wikipedia.org/wiki/Singularity_(operating_system)
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.
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.
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
http://en.wikipedia.org/wiki/Write_Once_Read_Many
WORA, niet WORM.
Tja als we dan toch gaan recompilen, wat is er dan mis met POSIX?
AFAIK is Windows niet POSIX compatibel en laat dat nu heel toevallig een vrij groot deel van de markt zijn.
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.
De compatibiliteit moet voor Microsoft niet te groot zijn.
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)
Ik weet dat deze soms nog wel eens gebruikt wordt, maar de voorkeur is meestal cygwin (de wine tegenhanger voor unix on windows :-p)
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 
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?
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...
Als ze er al mee wegkomen zal binnen no time de gratis versie ofwel een slak zijn, ofwel bloatware/adware...
Even ter informatie: Er is altijd al een betaalde versie geweest van openoffice.org, namelijk star office. Oracle is daar niet mee begonnen.
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.
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]
IBM heeft gelukkig een gratis OpenOffice gezant
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)
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.
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]
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 )
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 )
aan de andere kant ... verdeel en heers??
Ik geloof niet dat Philippus ooit in zijn hoofd had dat je jezelf moest verdelen om te heersen.
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.
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.
Er bestonden al honderden JAVA VM's voor Oracle hier mee kwam hoor. Ze maken er nu enkel eentje extra.
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.
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.
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.
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.
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.
Een aardig lijstje is hier te zien.
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.Waarom een extra VM introduceren als je m.i. veel beter kan werken aan één VM die voor alles en iedereen geschikt is?
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.
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.
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.
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)Precies ook het (een van de) probleem van Linux; simpelweg teveel keuze.
Keuze is leuk, maar teveel keuze is overweldigend en kan daardoor juist een minpunt zijn. 't is maar net wie je doelgroep is.
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.
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]
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.
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.
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.
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]
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.
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).
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.
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.
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.
Dat juist niet... ze weten wel dat ze er geld mee willen verdienen maar nog niet precies waarmee.
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
)
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
)
JRockit was niet van Sun, maar van BEA wat al eerder is overgenomen door Oracle (http://en.wikipedia.org/wiki/JRockit)Beide JVM's zijn gebouwd op basis van de JRockit VM en de Hotspot VM, twee projecten van het voormalige Sun.
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.
zolang je de software van de betaalde versie maar wel kan draaien op de gratis versie, dan vind ik het minder erg.
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.
Zal mij inderdaad benieuwen hoe lang ze dat volhouden met deze ontwikkeling.
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...
Niet dat ik de splitsing een goede zaak vind...
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)
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.
Of met openjdk/icedtea (blijven) werken
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.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Xbox E3 2013 Mobiele telefoons Google Sony Microsoft Apple Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
