Cookies op Tweakers

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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 53 reacties
Bron: Reuters

Microsoft heeft samen met Sun Microsystems een plan opgesteld waarin staat hoe de softwaregigant zal gaan voldoen aan het vonnis van afgelopen december. In dit vonnis werd bepaald dat Microsoft de meest recente versies van het Windows besturingssysteem geschikt moet maken voor de Java Virtual Machine van Sun. Na een weekend van onderhandelingen werd afgelopen maandag het plan aan de rechter gegeven. De details van het stuk, waaruit de aanpak van Microsoft moet blijken, zijn nog niet bekend gemaakt. Toen Microsoft in eerste instantie geen haast leek te hebben met het ten uitvoer brengen van de in het vonnis gestelde opdracht, werd vorige week door de rechter een deadline van 120 dagen gesteld:

JAVA logoIn a Dec. 23 ruling, Motz concluded that Sun had a good chance of winning its case against Microsoft and said he would grant a preliminary injunction forcing Microsoft to include Java in its Windows computer operating system.

The judge instructed the two sides to negotiate specifics of the injunction, but they failed to agree on the terms.

Sun complained to Motz that Microsoft wanted to take up to a year before including the Java program in copies of Windows it sells. Microsoft told the judge that shipping Java with Windows was not a simple matter and a sudden change in the operating system could harm large corporate users of Windows.

After listening to arguments from both sides at a hearing last week, Motz said he wanted Java in Windows within 120 days and pushed the two sides to compromise on a handful of other issues. He also agreed to stay his 120-day requirement for two weeks to give the appeals court time to consider Microsoft's expected appeal.
Moderatie-faq Wijzig weergave

Reacties (53)

Zozo, dat werd idd tijd. Vanaf juni vorig jaar kon je geen MS java voor XP meer krijgen vanwege deze strijd. Met SP1 kwam hij pas weer beschikbaar, maar een paar maanden kon je dus alleen maar de Sun VM gebruiken in XP! Zie wat MS hierover zegt op deze pagina.

Waar het kennelijk nu om gaat, is dat XP "out of the box" (dus pre-SP1) nog steeds geen VM heeft. Die was alleen downloadbaar. Kennelijk moeten ze nu verplicht de VM meeleveren, dus het lijkt me dat het een simpele kwestie is van alleen nog maar XP SP1 in de winkels gooien? Ik geloof niet dat het gaat om het meeleveren van Sun's VM, maar "een" VM. Maar dat is wat moeilijk op te maken uit dit bericht van Reuters, dat niet al te helder is:
forcing Microsoft to include Java in its Windows computer operating system
...welke Java zeggen ze niet. Het kan nu dus gaan om een MS VM die wl in overeenstemming is met de specs van Sun; het kan ook gaan om het meeleveren van Sun's VM; en het kan ook nog gaan om het meeleveren van welke VM dan ook, als hij maar out of the box er bij zit...

Nog ff wachten op die details dus 8-)
Waar het kennelijk nu om gaat, is dat XP "out of the box" (dus pre-SP1) nog steeds geen VM heeft. Die was alleen downloadbaar. Kennelijk moeten ze nu verplicht de VM meeleveren, dus het lijkt me dat het een simpele kwestie is van alleen nog maar XP SP1 in de winkels gooien?
Alle WindowsXP doosjes die geproduceerd zijn sinds de release van SP1 hebben SP1 al ingebakken dus ik denk dat het daar niet om gaat.
MS moet de Sun VM meeleveren, aangezien de MS VM i) verouderd is (ondersteuning tot Java 1.1) en ii) grote incompatibiliteit vertoont met de standaard Java implementatie. Ik denk dat je misschien maar het vorige artikel over de gerechtelijke uitspraak moet lezen.
Ik vraag me af om welke versie van Java dit zal gaan:
Microsoft Java 1.1
Sun *compliant* Java 1.1
of de laatste versie: Java 2 versie 1.4 (dit laatste zal wel niet het geval zijn, omdat MS dan eerste een nieuwe licentie moet nemen op Java 2...)
Waarom zou dat een probleem zijn?

Als ik sun was had ik dat dan gratis verleend, hiervoor krijg je java in Windows terug en dat is veel beter dan een beetje geld.
En dan krijg je mensen die niet meer op hun internet bankier websites meer kunnen. Er zijn dus wel degelijk heel wat corporate users die hier problemen mee gaan krijgen.

De websites van banken zijn meestal voor gebruik met de Microsoft VM gemaakt (maken dus gebruik van activeX binnenin Java, iets dat de Sun Java VM niet ondersteund). Ik ben benieuwd hoe ze dat gaan oplossen.
Als je nu weer Girotel Online bedoelt..
Daar hoor ik vaker over, alleen die draait dus op JavaScript, en heeft NIETS met Java te maken.

Dat JavaScript in de meeste browsers gebrekkig is, dat is toch wel bekend?
Ik kan anders uitstekend ABN-AMRO internet bankieren met Mozilla 1.2.1 onder Linux hoor. :)
LOL! ik dacht OMG, weer iemand die denkt dat girotel online JavaScript is, maar het is de zelfde gast. :) Goed bezig!
Waar zit die Java dan?
Ik zie echt nergens een applet ofzo.
Alleen maar JavaScript.
Bewijs het eens?

Hier een stukje van de pagina:

<!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><title>Girotel Online Prototype</title><link rel="stylesheet" type="text/css" href="girotel.css"><script language="Javascript">
var c2 = ".postbank.nl";
</script>
<script language="Javascript">
function ck(ce){var ak;if(!ce.keyCode){ak=ce.which;}else{ak=ce.keyCode;}if(ak==13){if(la()){top.gd();document.forms.dx.submit();}return false;}else {return(ak==8||ak==9||(ak>=48&&ak<=57)||(ak>=65&&ak<=90)||(ak>=97&&ak<=122));};}
function l8(){var ea=document.forms.dx;var jd=ea.txtAbonnementID.value;if(ea.txtAbonnementID.value.length<6){var oo=6-ea.txtAbonnementID.value.length;for(i=0;i<oo;i++)jd='0'+jd;}ea.txtAbonnementID.value=jd;}

Kortom, hou die grote bek voor je, en laat die Java eens zien? Ik kan het NERGENS vinden, alleen maar JavaScript code.
We hebben het nog steeds over https://www.p3.postbank.nl/GTO/
Ga maar kijken.
En bied je excuses aan.
Eigenlijk moet ik me niet laten verleiden om hier op in te gaan. Maar ik kan het niet laten. Het leermoment voor jou is dat je niet keihard standpunten in moet nemen als je er geen kont verstand van hebt. Een zeer gevaarlijke instelling. Als jij een javascript tag tegenkomt in frame wil dat niet meteen zeggen dat de hele web pagina daarmee gemaakt is. Bekijk even de laatste zin.

alert('U heeft geen geldige TAN-code ingevuld. Doe dit alsnog. (Meldingscode: 3306)');top.frames.Onder.frames.Blad.document.forms[1].txtTan.focus();}else {var cj = "";for (mg in r){cj += n9(r[mg]);}cj = unescape(cj);top.frames.Onder.frames.Blad.document.forms[1].txtGegevens.value = cj;cj = cj.replace(/\|/g,"");cj = cj.replace(/\#/g,"");cj = cc(cj);cj = of(cj);var gv = "000" + top.ok;if ( top.gd() ){var rc = top.frames.Onder.frames.Mosaic.document.fw.PBGN1(cj, jg, gv, top.kp);if (rc == 0){ez = top.frames.Onder.frames.Mosaic.document.fw.PBGN2();top.frames.Onder.frames.Blad.document.forms[1].txtMac.value = ez;return ez;}else {alert("Er is een probleem bij het initialiseren van de JAVA-applet. (Meldingscode: 3703)");}

Maar sloop jij maar java uit je computer als je denkt dat je zonder kunt girotellen. Ook wel raar dat m'n java-console in beeld komt als het alleen maar java zou zijn.
Eeeh, het gaat hier over corporate spullen. Die online banking dingetjes zijn voor consumenten.

Als we het over corporate hebben gaat het over systemen die binnen een organisatie gebruikt worden en over het algemeen speciaal voor die organisatie geschreven zijn. B.v. voor een Ahold, een Sony en meer van dat soort grote bedrijven. Binnen die bedrijven kunnen er gemakkelijker eisen gesteld worden aan de client-pc's (b.v. een bepaalde Java versie). Dat kan met consumenten apps niet, dat moet bijna overal op te kunnen draaien, ook op de brakste MS VM.
Dat is een probleem wat de bank moet oplossen, en niet MS of Sun.
Zelf gebruik ik internet bankieren niet, maar dit zou dus betekennen dat het ook niet onder Linux zou werken?
In mijn ervaring werken die -bank-sites ook onder Linux, dus het ligt niet aan MS VM volgens mij.
Komt hiervoor dan een patch voor de huidige OS'en of zien we het pas terug in Longhorn?
De MS VM zuigt namelijk :(
De MS VM performed anders aanzienlijk beter dan die van SUN.
De MS VM is anders ook niet compatible met de Java Spec, waardoor het een Java-emulator is en geen Java Virtual Machine.

Wat heb je liever? Een echt platform onafhankelijke programma omgeving of een MS only feestje met een (illegale) niet compliant VM?
Wat heb je liever? Een echt platform onafhankelijke programma omgeving of een MS only feestje met een (illegale) niet compliant VM

Dat is een beetje overdreven. Het is inderdaad zo dat de MS JVM niet 100 % compatible met die van SUN (maar zeker niet illigaal) ... de reden is ongeveer dezelfde reden waarom C# op het Windows platform zoveel sneller is dan Java ... MS heeft het geoptimaliseerd naar haar platform ... hetzelfde wat ze met de JVM van SUN hebben gedaan ...

Dus de VM van MS zuigt zeker niet ... integendeel ...
Girotel Online is JavaScript, niet Java.
Wat bedoel je nou precies?
Ik gebruik zelf IE6 met Sun-Java voor Girotel Online en dat werkt prima.

Er komt keurig een Java-console op als ik inlog.
Girotel is geen JavaScript maar een applet en wel degelijk Java. JavaScript heeft niets met java te maken. De naam is vroeger van Livescript veranderd naar JavaScript om mee te varen op de hype die destijds rond Java hing.
Ik heb het over Girotel Online:
https://www.p3.postbank.nl/GTO/

Ik kan hier in de source nergens een Java applet tag ontdekken... Alleen maar JavaScript.
Dus zeg het maar.
De MS VM performed anders aanzienlijk beter dan die van SUN.
Dat hoor ik vaker, toch heb ik de ervaring (onder Windows) dat als ik 2 MS VM's open mijn pc bijna gaat huilen, terwijl ik tig SUN VM's kan openen zonder dat mijn processor er warm van wordt.

Oftewel ik ben een grote voorstander van deze maatregel. Al is het alleen maar om het feit dat je soms met de originele Java sommige sites niet kunt bereiken en met de MS Java wel :?
Uhhh, heel Java is zo opgezet dat je maar 1 system-wide JVM nodig hebt.
Sterker nog, ik zou niet eens weten hoe je meer dan 1 JVM opgestart krijgt... Meerdere Java-apps draaien betekent gewoon dat er extra threads komen op de bestaande JVM.
Meerdere Java-applicaties draai ik bijna nooit, maar meerdere applets (al dan niet in hetzelfde browser-window) werkt prima op Windows XPsp1 met IE6 bij mij.
Uhhh, heel Java is zo opgezet dat je maar 1 system-wide JVM nodig hebt.
Sterker nog, ik zou niet eens weten hoe je meer dan 1 JVM opgestart krijgt... Meerdere Java-apps draaien betekent gewoon dat er extra threads komen op de bestaande JVM.
Meerdere Java-applicaties draai ik bijna nooit, maar meerdere applets (al dan niet in hetzelfde browser-window) werkt prima op Windows XPsp1 met IE6 bij mij.
Zullen we eens kijken wat Sun hier over zegt? Klik hier en lees onder andere:

"There can be more than one runtime environments. You can install different runtime environments, and you can invoke multiple runtime environments in parallel. All run in their own address space and know nothing of one another. Which program uses which runtime environment is very system dependant. From the JavaTM program itself, you can try: System.getProperty("java.home")"

Dit lijkt toch echt te zeggen dat er wel degelijk meer dan 1 JVM op een systeem gedraaid kan worden, elk in een eigen address space.
Dit lijkt toch echt te zeggen dat er wel degelijk meer dan 1 JVM op een systeem gedraaid kan worden, elk in een eigen address space.
Ik bedoel iets anders.
Dit gaat erover dat je meerdere VERSCHILLENDE JVMs kunt hebben, en tegelijkertijd gebruiken...
Ik bedoel dat als je meerdere Java-applicaties tegelijk wilt draaien, dat je dat op 1 en dezelfde instantie van die JVM doet (1 proces).

Daar ging het gumkop ook om, hij zeurde dat ie problemen had met 2 MS VMs open...
Ik snap niet hoe dat uberhaupt kan... Ik heb zelf iig nooit problemen gehad met het draaien van meerdere Java applicaties tegelijkertijd. Niet met Sun en niet met MS.
Op het moment dat ik onder W2K een command prompt start en java -jar orion.jar intik start er een applicatie server in een JVM. Als ik nog een command prompt opentrek en daarin tik java -jar MijnApp.jar start er een andere JVM waarin mijn applicatie draait.

Dit zijn VERSCHILLENDE JVM's, in ieder geval voor wat betreft het onderliggende OS. Dat ziet wel degelijk 2 van elkaar losstaande Java processen draaien. Op deze manier wordt je in principe alleen door de mogelijkheden van je OS/hardware combinatie beperkt in het aantal JVM's dat je tegelijkertijd kunt draaien.

Volgens mij ben jij een beetje in de war over wat er nu precies van elkaar verschilt. Je kunt gemakkelijk meerdere INSTANTIES van een Java Runtime Environment draaien. Als je meer dan 1 versie van een JRE (Sun, Blackdown, IBM, BEA, Microsoft, ...) op je systeem hebt staan kun je ook verschillende VERSIES naast elkaar draaien.

Als ik jouw reacties tot nu toe lees, dan denk ik dat jij voornamelijk ervaring hebt met applets. Een 'echte' Java applicatie doet bepaalde dingen wat anders.

Persoonlijk begrijp ik ook niet zo goed wat nu precies het probleem van Microsoft is om een goede JVM mee te leveren met Windows. Het is gewoon een applicatie die draait, geen echte OS component.
Dit zijn VERSCHILLENDE JVM's, in ieder geval voor wat betreft het onderliggende OS. Dat ziet wel degelijk 2 van elkaar losstaande Java processen draaien
Dat zou niet moeten.
De tweede java.exe zou moeten zien dat de eerste java.exe al een mutex heeft op het JVM-object, en dat dus de applet op dat proces gestart moet worden, en niet op een nieuwe.
Je kunt gemakkelijk meerdere INSTANTIES van een Java Runtime Environment draaien. Als je meer dan 1 versie van een JRE (Sun, Blackdown, IBM, BEA, Microsoft, ...) op je systeem hebt staan kun je ook verschillende VERSIES naast elkaar draaien.
Ik zeg dat je iig van dezelfde versie dus maar 1 proces hoeft te hebben, ongeacht hoeveel applicaties je draait.
Dat je dan verschillende versies kunt gebruiken, is een ander verhaal. Die hebben verschillende mutex-objecten, als het goed is.
De tweede java.exe zou moeten zien dat de eerste java.exe al een mutex heeft op het JVM-object, en dat dus de applet op dat proces gestart moet worden, en niet op een nieuwe.
En hoe ga je dat dan doen met alle security constraints die er mogelijk zitten op de eerste JVM? Je draait een JVM in een bepaalde security context. Als ik een andere Java APPLICATIE (en dus geen applet) start als andere gebruiker, dan zou die applicatie alle rechten krijgen die de als eerste gestarte JVM heeft. Dat is duidelijk geen wenselijke situatie.

Wat moet je bijvoorbeeld doen als 1 van die applicaties System.exit() aanroept? Alleen die applicatie wil stoppen en mag de rest niet beinvloeden. Dat zou nogal wat betekenen voor de administratie die een JVM zou moeten bijhouden over de processen en threads die binnen een JVM zouden draaien. Als je in de J2SE API kijkt dan zie je wel allerlei zaken die te maken hebben met threads, maar eigenlijk niets dat te maken heeft met processen. Dat zou je ook al iets moeten zeggen over de manier waarop Java applicaties geacht worden te draaien, namelijk gewoon een applicatie per JVM.

Bedenk wel dat Java, en zeker J2EE, erg veel gebruikt wordt in server applicaties. Het is niet ongebruikelijk om veel server processen op 1 machine te draaien, waarbij het natuurlijk erg handig is als die processen van elkaar geisoleerd zijn. Per applicatie een address space dus, en omdat een Java applicatie altijd binnen een JVM draait impliceert dat een JVM per applicatie/proces. Bovendien kun je dan wat extra beveiligingen inbouwen door per JVM bijvoorbeeld een bovenlimiet aan de heap size op te geven zodat een run-away proces niet de hele machine onderuit trekt.
Ik zeg dat je iig van dezelfde versie dus maar 1 proces hoeft te hebben, ongeacht hoeveel applicaties je draait.
Dat je dan verschillende versies kunt gebruiken, is een ander verhaal. Die hebben verschillende mutex-objecten, als het goed is.
En toch zie ik hier op W2K vrolijk drie verschillende instanties van java.exe draaien, terwijl er maar 1 versie van een JRE op die machine is geinstalleerd. Ik zie dit gewoon in de taskmanager, ze worden alle drie als Proces betiteld door W2K. Leg mij dan eens uit hoe dit dan 1 proces is. Deze JVM instanties zijn ook afzonderlijk van elkaar te starten en stoppen.

Sterker nog, in 1 van die applicaties wordt gebruik gemaakt van een ShutdownHook. Dat is een thread die door de JVM gestart wordt op het moment dat de JVM wordt gestopt. Alleen de ShutdownHook van die applicatie wordt dan getriggerd, niet die van de andere applicaties. Dat toont overduidelijk aan dat er dus meer JVMs tegelijkertijd naast elkaar kunnen draaien.
Ik snap om eerlijk te zijn het verschil tussen de ruimte waarin een Java applet draait en de definitie JVM niet, geef ik direct toe. Wat ik bedoel is dat als ik 2 of meer 'ruimtes' heb waarin iets java-achtigs gedraait wordt ik duidelijk performance verschil zie.
k snap om eerlijk te zijn het verschil tussen de ruimte waarin een Java applet draait en de definitie JVM niet, geef ik direct toe. Wat ik bedoel is dat als ik 2 of meer 'ruimtes' heb waarin iets java-achtigs gedraait wordt ik duidelijk performance verschil zie.
Je bedoelt het verschil in performance als je meer dan 1 Sun JVM open hebt staan in vergelijking met de vertraging die je ziet als je meer dan 1 MS VM open hebt staan?

Wat speculatie van mijn kant: Dat heeft waarschijnlijk alles te maken met de manier waarop die JVM in elkaar zit. Voor een JVM is alleen gedefinieerd hoe de Java-code gedraaid moet worden. Hoe dat wordt geimplementeerd op het OS waar de JVM voor bedoeld is mag bepaald worden door degene die de JVM maakt.

Ik kan me voorstellen dat Microsoft de Win32 API 'iets' beter kent dan Sun en daardoor in ieder geval een aantal zaken heel anders heeft geimplementeerd. Dat dit performance-verlies oplevert als je meer dan 1 instantie van de MS JVM open hebt staan is waarschijnlijk een gevolg van de manier waarop het onderliggende OS wordt aangesproken.
En hoe ga je dat dan doen met alle security constraints die er mogelijk zitten op de eerste JVM? Je draait een JVM in een bepaalde security context. Als ik een andere Java APPLICATIE (en dus geen applet) start als andere gebruiker, dan zou die applicatie alle rechten krijgen die de als eerste gestarte JVM heeft. Dat is duidelijk geen wenselijke situatie
Okee, ik heb een en ander uitgezocht, en kennelijk werkt het alleen met applets zo.
Desler said Microsoft will file an appeal of the injunction with the U.S. appeals court in Richmond soon after the order is entered.
Dus blijkbaar is die overeenstemming niet echt dus.
Want Microsoft gaat meteen weer in beroep, begrijp ik hieruit.

En terecht natuurlijk, want Sun maakt misbruik van de monopoliepositie van MS door te eisen dat hun producten meegeleverd moeten worden. Dat is gewoon ordinair meeliften.

Voor mij zou het het eerlijkst zijn om ofwel allebei de JVMs met Windows mee te leveren, of geen van beiden, en de consument de keus laten maken.
Sun lijkt de consument compleet te vergeten, en denkt alleen aan eigenbelang. Zelfs Microsoft heeft het nog nooit zo bont gemaakt, als je het mij vraagt, want die hebben speciaal opties in de laatste servicepacks gebouwd waarmee je de default browser, mailclient, JVM en dergelijke kunt instellen... want dat is wat de consument schijnt te willen.
Sun gaat hier in feite weer tegenin, en wil dat uitsluitend hun product gebruikt wordt.
Je had toch niet echt verwacht dat SUN aardiger of netter was dan MS? SUN (en enkele anderen (b.v. AOL)) hebben alleen de laatste tijd de underdog-positie flink kunnen uitbuiten zodat het leek of ze aardiger waren.

En als reactie op santaklos; volgens is deze rechtzaak gevoerd omdat MS weigerde geld op tafel te leggen voor een nieuwe licentie voor de nieuwste java versie nadat SUN het ze in een eerdere rechtzaak onmogelijk had gemaakt MS VM 1.1 nog langer mee te leveren.
Dat weet jij, dat weet ik... Maar ik wil het even aan het licht brengen, want een hoop mensen zien alleen het 'evil empire' van MS, en vergeten dat daar door anderen gigantisch misbruik van gemaakt wordt.
Sterker nog, ik denk dat er best wel bedrijven zijn die willen dat MS een monopolie blijft, omdat dit de mogelijkheden van MS aanzienlijk beperkt, en juist extra mogelijkheden voor de concurrentie schept.
Deze rechtzaak is hier een goed voorbeeld van, en ik hoop dat de mensen hier nu in gaan zien wat voor een vies spelletje er TEGEN MS wordt gespeeld de laatste tijd, en in dit geval door Sun.
Nou zo'n vies spelletje wordt hier echt niet gespeeld door Sun hoor. Dit is wat er gebeurd is:

Toen MS met IE nog volop in de strijd lag tegen Netscape kocht het een Java licentie; als Netscape Java had kon IE tenslotte niet achterblijven. Vervolgens bouwden ze hier hun eigen toevoegingen bij in, die het alleen deden op Windows. Hiermee was Java niet platform onafhankelijk meer, en uiteraard hoopte MS erop dat ze doordat Windows zoveel gebruikt werd deze toevoegingen tot de facto standaard konden verheffen, net zoals bijvoorbeeld met Microsoft's HTML dialect is gebeurd.
Ik vind het niet gek dat Sun hier een rechtszaak tegen heeft aangespannen, die ze na de nodige vertragingstaktieken van MS gewonnen hebben.

En toen kwam MS met hun .NET initiatief, inclusief een eigen Java variant namelijk C#. En o wat een verrassing, tegelijkertijd werd de Java VM opeens niet in Windows XP opgenomen, officieel vanwege het risico op veiligheidslekken. Mij lijkt het dat MS hiermee zijn eigen C# er doorheen wil drukken, en ik vind het zeker geen 'vies spelletje' dat Sun ook hier een rechtszaak tegen aanspant.
Dat MS extensies op hun JVM heeft gemaakt, heeft totaal geen effect op Java zelf.
Ja zo weet ik er nog wel een. Wat dacht je van de extensies die MS op HTML heeft gemaakt?
Maar goed, MS heeft destijds licentie overeenkomst getekend waarin stond dat ze geen platform afhankelijke toevoegingen mochten maken, dus in de rechtszaak hadden ze geen poot om op te staan.
Nee, dit was een eis van Sun
Ik weet niet waar je dat vandaan haalt, maar dat was zeker geen eis van Sun. Zou wel gek zijn vind je ook niet, gezien het feit dat Sun nu een rechtszaak aanspant om Java weer in Windows te krijgen? Hier is een link als je het nog eens wil nalezen:
http://news.com.com/2100-1001-270200.html?tag=rn
Of een quote:
"We want people to have the best user experience possible using Windows XP," said Greg Sullivan, lead product manager for Windows. Shipping an outdated version of JVM "doesn't support that goal."
Hiermee was Java niet platform onafhankelijk meer
Dat is niet waar.
Dat MS extensies op hun JVM heeft gemaakt, heeft totaal geen effect op Java zelf. Java programma's werken nog steeds overal, ook op de MS JVM.
Alleen de extensies werken niet op andere JVMs. Die extensies zijn ook geen Java, dus wat maakt het uit?
En o wat een verrassing, tegelijkertijd werd de Java VM opeens niet in Windows XP opgenomen
Nee, dit was een eis van Sun. Sun heeft zichzelf in de vingers gesneden door die rechtzaak te winnen.
ik vind het zeker geen 'vies spelletje' dat Sun ook hier een rechtszaak tegen aanspant.
Als het om een ander product dan Windows ging, van een andere firma dan MS, dan had Sun geen schijn van kans gehad met de eis dat hun JVM in het OS opgenomen moet worden. Dus zeker wel een vies spelletje dat de positie van MS uitbuit.
Maar goed, MS heeft destijds licentie overeenkomst getekend waarin stond dat ze geen platform afhankelijke toevoegingen mochten maken, dus in de rechtszaak hadden ze geen poot om op te staan.
Als dat zo was, zou die rechtzaak geen jaren duren.
Kennelijk heeft Sun wat gaten laten vallen in hun licentie-overeenkomst, en heeft MS daar dankbaar gebruik van gemaakt.
Of heb jij een link naar de letterlijke tekst van die licentie-overeenkomst? Dan kunnen we zien wat er echt aan de hand is.
Ik weet niet waar je dat vandaan haalt, maar dat was zeker geen eis van Sun. Zou wel gek zijn vind je ook niet, gezien het feit dat Sun nu een rechtszaak aanspant om Java weer in Windows te krijgen?
Nee, de eerste eis van Sun was om de uitgebreide JVM uit IE4 te halen. Dit is toen gebeurd, en in plaats daarvan is overeengekomen dat MS nog 7 jaar lang een oudere, niet-uitgebreide mee zou leveren.
Maar na een paar jaar begon Sun dus toch weer te zeuren, omdat ze niet hadden bedacht dat die JVM dan dus verouderd raakt.
Dus toen zei MS "Okee, dan halen we em er wel uit, en dan kunnen gebruikers die van jullie installeren als ze Java willen"... (daar doelt jouw quote van Sullivan dus op).
En daar had Sun (ook weer) niet op gerekend, dus vandaar dat ze nu willen dat hun JVM erin MOET.
En ik vind dat dat niet kan... Een concurrent kan toch niet eisen dat je hun product meelevert? Dat gaat mij echt te ver.
En terecht natuurlijk, want Sun maakt misbruik van de monopoliepositie van MS door te eisen dat hun producten meegeleverd moeten worden. Dat is gewoon ordinair meeliften.
afaik hebben Sun en MS (al een tijd geleden) afgesproken dat MS Java mag/moet meeleveren met windows..
En toen kregen we ineens de MS VM.. die natuurlijk NIET (niet eens slecht, maar totaal NIET) compatibel is met de 'echte' java.. en dat is ook de kern van de rechtzaak..

Ik bedoel er dus mee dat 't redelijk kansloos is om nu in Java te developen, om dat elke klant van je nog es de Sun VM moet installen.. terwijl de MS VM meegeleverd wordt.. en dan kan je net zo goed je progje niet in Java doen.

Nouja, MS heeft gewoon een lange-termijn strategie gebruikt om Java uit de markt de drukken, wat deels gelukt is... ze zijn ook al een lange tijd bezig met hun .Net platform. (absolute rip-off van Java trouwens, maar op sommige punten wel beter)
En toen kregen we ineens de MS VM.. die natuurlijk NIET (niet eens slecht, maar totaal NIET) compatibel is met de 'echte' java.. en dat is ook de kern van de rechtzaak..
Fout. Ten eerste was de MS VM compatible met Sun Java, op enkele bugs na. Hij bood alleen ondersteuning voor MEER. Dat is niet in strijd met de Java-compatibiliteit zelf. Ga maar eens een IE4 zoeken en run daar eens wat Java op, je zult zien dat ie bijna alle Java-programma's zonder problemen uitvoert. En als je programma's vindt die niet helemaal 100% werken, dan kan ik ook wel een JVM van Sun uit die tijd laten zien waarop ook sommige Java-programma's niet 100% werken, dus dat is een beetje een zwak argument, vind je niet? Waarom mag Sun wel bugs hebben en MS niet?
En waarom een rechtzaak om de hele zaak te verbieden, ipv bugfixes eisen? Dat had veel constructiever geweest.

Ten tweede, dat was de rechtzaak tegen IE4/J++ en die is al jaren geleden afgehandeld en in IE5+ is een Java1.1-compatible JVM meegeleverd zonder extensies.
Het probleem van Sun is nu dat Sun de zaak geupdate wil hebben naar hun nieuwe versie, en daarover is niets met MS afgesproken destijds. Dom van Sun dus.
ze zijn ook al een lange tijd bezig met hun .Net platform. (absolute rip-off van Java trouwens, maar op sommige punten wel beter)
'rip-off' klinkt wat negatief. Noem je C++ ook een rip-off van C? Of Delphi een rip-off van Pascal?
.NET gaat verder op de weg die Java ingezet heeft. Dit deed J++ eigenlijk ook al.
Sun complained to Motz that Microsoft wanted to take up to a year before including the Java program in copies of Windows it sells. Microsoft told the judge that shipping Java with Windows was not a simple matter and a sudden change in the operating system could harm large corporate users of Windows.
Wat een onzin, dat betoog van MS. Wat voor probleem moet zo'n installatie van Sun's VM in vredesnaam opleveren? Ik denk dat die large corporate users of Windows die schade op zouden lopen vooral MS zelf is, want ze wilden dat jaar natuurlijk hebben om .NET en C# goed in de markt te zetten. Mooi dat die vlieger niet op gaat.
Zo'n onzin is dat niet...
Ten eerste komt er nu standaard een stuk code erbij in Windows, waar MS de verantwoordelijkheid niet voor kan nemen (wie weet hoeveel exploits er in de Sun JVM zitten, MS heeft hier dus echt wel een punt).
Ten tweede heb je natuurlijk bedrijven die al Java-programmatuur gebruiken... En wat nu als die programmatuur niet op de Sun JVM draait, omdat ie ontwikkeld is voor XP + MS Java zoals de situatie nu is?

Dus onzin is het zeker niet, wat MS daar zegt.
Dat het MS dan ook nog eens goed uitkomt is wat anders.
Java heeft een excellente track-record op het gebied van veiligheid, mede doordat beveiliging een van de hoofdcomponenten bij het ontwerp van Java was.

Als bedrijven non-compliant Java-software hebben laten schrijven, dan hadden ze kunnen verwachten dat dat problemen geeft. Het zal geld kosten om de onbruikbare Windows-code uit de Java-apps te laten halen, maar anderzijds had Windows-code ook niets te zoeken in Java.

Als standaarden naar de letter worden gebruikt, dan krijg je deze problemen ook niet. Kwestie van eerst denken, voor je een sloppy programmer iets met jouw centen in elkaar gaat klutsen.
Dat is helemaal geen onzin. Windows is een complex product. Als daar aanpassingen in gemaakt moeten worden en helemaal met software van andere partijen is het heel veel werk om dit op een goede manier te doen. Vooral het testen is erg veel werk.
Het is verbazingwekkend dat ze al na slechts een weekend overleg, overeenstemming hebben kunnen bereiken.
Werd eens tijd dat die twee wat regelden. Java moest platform onafhankelijk zijn, maar zoals het nu is werkt het zelfs op 1 platform niet goed. Je bent haast verplicht beide virtual machines geinstalleerd te hebben, wil alles goed werken.
Het verbaast me dat de heren het eens zijn geworden. Vreemd dat daar eerst een rechtzaak voor nodig is geweest. Zeker geld teveel....
About time zou ik zo zeggen.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True