Oracle wil met gratis en betaalde JVM-uitvoeringen komen

+2 etennapel
8 november 2010 15:50

Laat duidelijk zijn dat dit voor bedrijfsmatige toepassingen niet helemaal nieuw is.

Het doorleveren van de JRE is reeds sinds JSE 5.0 (vele jaren terug dus) betalingsplichtig. Ook SUN had dit reeds in de voorwaarden staan. Sinds Oracle SUN heeft overgenomen, is Oracle aan de slag gegaan om de gebruikers hiervan te overtuigen. Een voorbeeld hiervan :

http://webcache.googleuse...d=3&hl=nl&ct=clnk
(Uit de google-cache, want het originele artikel is de afgelopen week door Oracle verwijderd....)

Wat nieuw is, dat nu blijkbaar ook voor JVM's gebruikt voor ontwikkeldoeleinden betalingsplicht gaat komen. Afhankelijk van de gewenste functionaliteit en performance betaal je voor deze premium opties. Hopelijk dat de OpenJDK - JRE voldoende blijkt te zijn voor de meeste gebruikers.

Al met al een business-model dat door veel bedrijven wordt gehanteerd. De "gratis" versie met basis-functionaliteit; Extra betalen voor premium-content. Wel vervelend voor al die gebruikers die nu premium functionaliteit nodig blijken te hebben. Zaken zijn zaken blijkbaar voor Oracle.

+2

PolarWolf
@etennapel • 8 november 2010 16:34

Een "redistribution" is iets anders dan bedrijfsmatig gebruik. Redistribution slaat dan ook op producten die een Java runtime nodig hebben die ook (geintegreerd) meeleveren. De betalingsplicht ligt daarbij dan ook bij degene die het product ontwikkelt, cq. samenstelt en levert, en niet bij de eindgebruiker (uiteraard word het wel doorbelast, maar dat is wat anders).

Dit verhaal gaat gewoon over het hebben van twee vormen van JRE, een "gratis" en een "niet gratis" variant..en dat gratis slaat dan (voor zover ik begrijp) op het gebruik, niet op de (her)distributie.

+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

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.

+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

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.

+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 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 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 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]

+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.

+1

Herko_ter_Horst
@Jeanpaul145 • 8 november 2010 14:16

WORA, niet WORM.

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)

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

+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

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)

+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 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)

+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 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).

+1

PolarWolf
8 november 2010 15:10

Hmm...Oracle komt met een betaalde variant van de JRE. Voor thuisgebruik is dat niet zo boeiend, maar bedrijven kunnen dus een soort CAL systeem gaan verwachten voor het kunnen draaien van Oracle Webforms ofzo? Die truuk hebben ze al eens eerder geflikt met JInitiator. Niet dat je daarvoor moest betalen, maar de webforms hadden het wel nodig om te kunnen draaien.

Al maar meer redenen om Oracle links te laten liggen. Helaas worden productkeuzes niet noodzakelijkerwijs gemaakt op basis van logica, maar op basis van politiek.

+1 OpenMinded
@PolarWolf • 8 november 2010 17:03

Inderdaad, anders was Microsoft al lang failliet.
Volgens mij zijn je juist van JInitiator af, we draaien nu een aantal applicatie juist op een standaard JRE.
Ik hoop dat ze niet weer zo'n blunder maken.

+1

PolarWolf
@OpenMinded • 8 november 2010 17:57

Ja gelukkig zijn we daar vanaf. Maar dat hoeft niet te beteken dat die blunder niet nog een keer herhaald gaat worden, dit keer met een "premium", oftewel betaalde variant, van de JRE. Ik zou zo niet weten hoe ze het anders willen gaan afdwingen dat ze daar inkomsten uit gaan krijgen.

Tenzij ze goed naar Adobe kijken en gewoon het bedrijfsmatig gebruik gaan laten aftikken (Adobe Reader is niet "gratis"). Ik ben heel beniewd welke draai ze hieraan gaan geven, maar als klant wordt je er gegarandeerd niet blijer van. Dat voel ik op m'n klompen nog wel aan

+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

+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 jj71
8 november 2010 16:25

Op zich wel begrijpelijk dat Oracle probeert manieren te bedenken om geld te verdienen met Java.

Ik hoop alleen wel dat hun gratis JVM implementatie geen tweederangs ding wordt wat duidelijk gaat achterlopen op de premium JVM en op de concurrentie.

Gelukkig zijn er nog concurrenten (bijvoorbeeld .NET waar je niet apart voor hoeft te betalen), hopelijk is dat voldoende om Oracle te laten inzien dat ze de gratis JVM niet teveel moeten laten afzakken...

Het zou mooi zijn als een onafhankelijke partij (Apache bijvoorbeeld) zijn écht 100% open source JVM (Apache Harmony) kon ontwikkelen tot iets wat kwalitatief echt kan concurreren met Oracle's JVM. (Tot nu toe is Apache Harmony helaas nog niet volledig en goed genoeg).

Cookies op Tweakers

Lees meer over

Nieuwste IT Banen

Gerelateerde content

Reacties (62)

Sorteer op:

Weergave: