Java moet net zoals C, C++, Pascal, CORBA, XML en WebServices gewoon standaard worden. Sun heeft ooit eens een keer in het verleden Java v1 ontwikkeld en werd toendertijd (95) door IBM en M$ gesteund. Ze hebben zich toen zo in-flexibel opgesteld dat M$ eruit is gestapt en .Net heeft ontwikkeld. IBM stelt nu naar mijn mening terecht dat Java maar eens gestandaardiseerd moet worden door een onafhankelijke organisatie; het is gewoon te groot voor SUN en te belangrijk voor de markt als dat niet gebeurt. Als producent blijf je dan altijd afhankelijk van een SUN die altijd zijn eigen belang bovenaan zet.
SUN kan beter zijn spullen laten standaardiseren en zich toeleggen op het produceren van degelijke applicatie servers en -tools, want dat is iets waar ze veel steken laten vallen.
Als ze Java in '95 uit handen hadden gegeven, hadden we nu geen .Net gehad en was de wereld een stuk overzichtelijker geweest, alleen wist waarschijnlijk niemand meer wie SUN was
[edit]
M$ had trouwens de beste en snelste Java Virtual Machine toendertijd + een hele stabiele ontwikkelomgeving ( J++ ). De JVM die ze nu meeleveren stamt uit '97 en is nog steeds retestabiel in IE.
M$ had trouwens de beste en snelste Java Virtual Machine toendertijd
Jammer dat ze er weer platform afhankelijke zooi in moesten gooien waardoor het mogelijk werd windows-only java progs te maken.
Terecht dat Sun daar pissed over was.
Dat is juist het grote misverstand: het gaat er absoluut niet om dat Microsoft het mogelijk maakte om Java applicaties te schrijven die alleen onder Microsoft Windows werkten. Het is namelijk gewoon toegestaan om Java libraries te maken die gebruik maken van native functionaliteit die waarschijnlijk maar op 1 platform beschikbaar is. Apple doet in feite precies hetzelfde op Mac OS X en er bestaan vele libraries die gebruik maken van native functionaliteit die waarschijnlijk nooit geimplementeerd kan worden op een ander platform.
Het ging er juist om dat Microsoft features aan de taal Java en de JVM had toegevoegd die het niet mogelijk maakte om dezelfde code te draaien op een andere JVM, maar wel op hetzelfde platform. Platform specifieke code is dus geen probleem, JVM specifieke code wel.
De aanpassingen / uitbreidingen (COM) / beperkingen (RMI, JNI) die Microsoft waren bovendien nogal twijfelachtig. COM functionaliteit had ook geimplementeerd kunnen worden zonder de JVM aan te passen. De COM informatie werd opgeslagen in attributen en er is duidelijk in de specificaties aangegeven dat attributen slechts ter informatie mogen dienen en niet het functioneren van de code mogen beperken als een JVM de attributen niet kent. COM funciontaliteit had ook gebruik kunnen maken van normale native libraries, waardoor er geen enkel probleem was geweest: de code had dan ook in andere JVMs kunnen draaien.
idd was Microsoft bezig hun java implementatie een beetje te ver-microsoft-en door aan standaard calls extra opties toe te voegen die microsoft specifiek waren.
IBM heeft dat nooit gedaan en is 'trouw' gebleven aan de door SUN opgelegde specificaties. Niet SUN, maar firma's als IBM, BEA en Oracle hebben java groot gemaakt in de middleware business. SUN zou eigenlijk eens een keer moeten luisteren wat de markt, en implementors eigenlijk al een hele tijd willen: formalisatie van de Java standaard.
M$ had trouwens de beste en snelste Java Virtual Machine toendertijd
De snelste
gratis JVM onder Windows...
En dan nog grotendeels doordat een aantal sandbox-principes eruitgehaald waren.
SUN biedt ook een gratis JVM aan. Deze is onder Windows echter erg traag, heeft veel overhead en integreert niet goed met IE, uiteraard in vergelijk met de M$ JVM.
[edit]Hoezo troll?? We hebben het hier over gratis JVM's en ik vergelijk die van SUN met Microsoft. Sorry hoor als ik op iemand z'n tenen ben gestapt!
SUN biedt ook een gratis JVM aan. Deze is onder Windows echter erg traag, heeft veel overhead en integreert niet goed met IE, uiteraard in vergelijk met de M$ JVM.
Sun's JVM is in de laatste versies helemaal niet meer zo traag eens die opgestart is en werkt perfect samen met elke browser behalve MSIE (hoe zou dat komen?).
Sommige alternatieve JVM's zijn een pak sneller dan die van MS, en dat
zonder te bezuinigen op de sandbox-beveiliging.
Filip, noem dan eens een aantal alternatieve JVM's en onderbouw (met benchmark cijfers!) dat ze sneller zijn dan de MS JVM. En kom ook eens met wat bewijs voor je claim dat MS de sandbox beveiliging omzeilt.
Je bewering is namelijk incorrect. Alle testen zijn uitgevoerd met native Java applets die in de sandbox context draaien en de MS JVM is daarin beduidend sneller dan de rest:
Proof: www.javaworld.com/javaworld/jw-12-1997/jw-12-volanomark.htmlThese initial test results show Microsoft's JVM to be substantially faster than the competing platforms when their software implementations are compared directly on the same Intel hardware platform.
[quote]SUN biedt ook een gratis JVM aan. Deze is onder Windows echter erg traag, heeft veel overhead en integreert niet goed met IE, uiteraard in vergelijk met de M$ JVM.
[edit]Hoezo troll?? We hebben het hier over gratis JVM's en ik vergelijk die van SUN met Microsoft. Sorry hoor als ik op iemand z'n tenen ben gestapt!
[/quote]
Misschien dat die Troll beoordelingen iets te maken hebben met het feit dat je Microsoft afkort tot M$? Komt niet bepaald vriendelijk over hè?
Je hebt gelijk dat het wel wat ver gaat. Maar dat soort dingen worden gewoon niet goed ontvangen...
Dit is incorrect. De MS JVM was de snelste en meest efficiente versie ongeacht het platform. Dit is meermalen aangetoont in zeer veel verschillende testen. En het sandbox model bij de MS JVM is volledig in tact gebleven hoor. Weet niet helemaal hoe je daarbij komt...
Marcellozschreef SUN kan beter zijn spullen laten standaardiseren en zich toeleggen op het produceren van degelijke applicatie servers en -tools, want dat is iets waar ze veel steken laten vallen.
Als ze Java in '95 uit handen hadden gegeven, hadden we nu geen .Net gehad en was de wereld een stuk overzichtelijker geweest, alleen wist waarschijnlijk niemand meer wie SUN was
Als ze java in 95 uit handen hadden gegeven dan was er nu waarschijnlijk geen java, MS heefdt geen enkel belang bij write once run anywhere, daar ging het conflict om tussen SUN en MS. SUN heeft daaruit de conclusie getrokken dat veto recht nodig was.
SUN verdient nu geld door licenties te verkopen aan de leveranciers van java tools zoals Bea, IBM (websphere) Sybase en Oracle, het heeft er geen belang bij een concurrent van die bedrijven te worden.
Bij een open standaard geregeerd door een neutraal body is het onduidelijk hoe leveranciers van code en concepten daar nog een vergoeding voor zouden kunnen krijgen. Toch laat ook SUN doorschemeren dat het die kant op gaat.
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
While Sun is on a path to open up Java on its own terms, IBM doesn't like where things are heading. In Sun's world, Java needs a guardian angel to protect the sanctity of the many things that Java already offers and, in Sun's eyes, that guardian angel should be Sun. But IBM thinks Java should be an open standard governed by an independent and objective organization. So says IBM director of e-business standards strategy Bob Sutor.
13:34
13:11
Door ![[show]](http://tweakimg.net/g/if/comments/button_down.gif "Reactie uitklappen")
