Sun gaat Java promoten bij spelontwikkelaars

Sun Microsystems heeft een werkgroep in het leven geroepen om Java populairder te maken onder de ontwikkelaars van online games, zo meldt CNet. De Game Technologies Group gaat zich richten op het leveren van de techniek achter online gaming, en het promoten van de Java-programmeertaal. Momenteel wordt Java veel gebruikt voor het ontwikkelen van spellen voor mobiele telefoons, maar voor het pc-platform laten de meeste ontwikkelaars de programmeertaal vooralsnog links liggen. Volgens Sun geheel onterecht, omdat het multi-platformkarakter van de taal uitermate goed aansluit op de toekomst van online gaming:

"There's a tremendous move to adapt games for an online environment," Fowler said. "With Java technologies being multi-platform, it's a natural place to develop for the network." [...] game publishers find it increasingly important to offer their games on multiple devices--not just different types of PC operating systems but handheld computers and mobile phones as well. "You're now in essence chasing your consumer from device to device," he said.

Reacties (57)

[Verwijderd]

Terwijl ik zo door de bovenstaande commentaren lees vraag ik me af hoeveel van de mensen hier werkelijk ervaring heeft met java; en dan bedoel ik niet het draaien van applicaties, maar ontwerpen van programmatuur en implementeren hiervan in java.

Urban myths:
- Java is traag
Java (JRE 1.4) is niet traag.van zichzelf. Je kunt het wel traag maken door slecht ontwerp en slechte implementatie. Net als bij iedere programmeertaal zijn er een aantal "do-s" en "don't-s".

- De platformonafhankelijkheid staat in de weg van performance
iedereen die het nodige van virtualisering afweet, weet dat dit een vrij onzinnige stelling is.

- De virtual machine zorgt voor performance verlies.
In 1.4 zit een behoorlijk goede JIT compiler die ervoor zorgt dat je hier nagenoeg niets van merkt.

- Java zuigt want app X is geschreven in Java en is ongelovelijk traag.
Dus als app Y traag is en geschreven is in C dan zuigt C ineens?

- Flash is ook systeemonafhankelijk en veel beter.
Flash staat tot java als een driewieler staat tot een Daf Turbo Intercooler truck. Geen vergelijk dus.

- Java is alleen handig voor kleine apps
50% van de financiele wereld werkt met J2EE.

- De garbage collector vertraagt en legt af en toe alles stil.
In 1.4 heb je de keuze tussen 4 verschillende gc-s; 1 daarvan legt de boel nooit stil.


Java is niet zomaar een in elkaar gehacked zooitje; java is een enorm project, uniek in zijn soort. Met iedere release wordt het aantal mogelijkheden uitgebreid en tegelijkertijd de performance verbeterd.

[Verwijderd]

Aan deze post heb ik niet veel toe te voegen. Een van de sterke punten vind ik ook het ongelooflijk gemak waarmee je in Java een groot poject kan opzetten (zie het succes van J2EE).
Ik ben trouwens heel hard aan het uitkijken naar J2SDK 1.5 owv de ondersteuning voor Generics.

[Verwijderd]

Ik ben mezelf nog op dit gebied aan het orienteren. Ik wil namelijk een 3d software rasterizer gaan schrijven, en dacht misschien leuk voor in Java door dus platform onafhankelijkheid.

Maar voor een software rasterizer moeten heel veel numbers gecrunched worden. Nu was het net zo dat ik voor school een number crunch programmaatje in c moest schrijven wat we maanden ervoor in java hadden gedaan. Ideaal om de snelheid in de praktijk te zien.

Het probleemgebied was het zogenaamde vermoeden van Collatz waarbij eigenlijk heel veel gerekend wordt met grote data types (64bits integer) van gehele getallen. Het kwam er in ieder geval op neer dat de bepaling van een waarde in Java meer dan 2 dagen duurde terwijl in C/C++ binnen 5 uur. Persoonlijk trek ik dan de conclusie dat Java ontzettend traag is t.o.v. C/C++.

Het blijft hoe dan ook een leuk project om een software rasterizer te schrijven en ik zal het dan ook gewoon in Java gaan doen, met de hoop dat de Java performance in de toekomst wel zal verbeteren..

[Verwijderd]

Kijk opzich denk ik dat er veel waarheid in
jer verhaal zit. Het lijkt erop dat je inderdaad
erg goed weet waar je het over hebt.

Maar ik zit vaak in die financiele wereld, meer
in de middleware en message broker laag van software dan.

En elke java app die ik tegenkom in deze proffesionele wereld, is traag, vooral als er een grote UI gebouwd wordt. Houden ze het nou alleen bij messagaging dan is het verhaal anders.

En dat J2EE veel gebruikt workt heeft denk ik niet zoveel met de kwaliteit ervan te maken. Maar oa het leer traject vaan J2EE (IBM Websphere) en protabliltiy op meerdere platforms. Eeh de hype maybe.

Anyway, het is vrij goed te gebruiken, maar hou het inderdaad klein (web services) en bouw er geen UI's mee.

[dustin]

Java applicaties worden wel steeds sneller. JDK 1.4 is al veel sneller dan 1.3 en zeker dan 1.2.

Snelheid komt nog wel.

[JSK]

Echte snelheid is altijd alleen te behalen door juist van platform specifieke technieken gebruik te maken. Dat lijkt me dus redelijk in strijd met het beginsel van Java. Niet doen dus.

[justice strike]

laat ze eerst opengl maar goed ondersteunen (wat ook best multiplatform is, en best slecht geimplementeerd is in java) en andere io devices (3d geluid anyone?)

don't get me wrong ben een java en c schrijver, (in java echt veel geschreven) maar wat java mist is i/o ik kan niet eens een fatsoenlijk programma schrijven wat de usb poort aanspreekt. com en lpt kan nog net maar java is niet bedoelt voor io door het multiplatform karakter, daardoor kan je niet hardware gaan aanspreken (zoals 3d en geluid) wat best zonde is... maar aan de andere kant best begrijpelijk

[dustin]

USB kan je wel gebruiken in java, net zoals de comm en par poort. Of direct naar poorten van je pc schrijving. Daar zijn allemaal JNI modules voor. Niet alles zit standaard in java maar komt nog wel.

[Onno]

maar java is niet bedoelt voor io door het multiplatform karakter, daardoor kan je niet hardware gaan aanspreken (zoals 3d en geluid)

Hm? Java Sound API? Java3D?

Je kunt niet de hardware zelf rechtstreeks aanspreken, maar er zijn best API's voor, en dat verschilt niks van de manier waarop normale Windows/Linux/whatever programma's geluid of 3D gebruiken. Dat gaat ook gewoon via een algemene API als OpenGL/DirectX, en niet rechtstreeks.

[LEiPiE]

erm, Java3D *IS* keihard OpenGL (Of directX, kun je zelf kiezen welke implementatie je download). Java3D heeft 3D sound, Java3D is volledig voorbereid op zelfs 6-assige input devices (alleen omdat die nog zo zeldzaam zijn moet er zelf een implementatie van worden gemaakt).
Mijn afstudeer-buren zijn bezig met een X3D viewer in C/C++/OpenGL en waren er al trots op dat ze 36 frames/sec haalden.
Ze stonden flink te kijken toen de X3D loader voor Java3D *en* sneller de 3D wereld laadde *en* vervolgens vrij constant op 72 frames/sec zat...
Java (c.q. Java3D) zijn *echt* niet meer zo traag als altijd maar domweg wordt aangenomen!

[.oisyn]

Reactie op LEiPiE:

Java3D is bagger, traag, vervelend om te programmeren, en totaal niet bruikbaar voor games

Het is niet bruikbaar omdat het te weinig controle geeft over de manier van rendering. Je kunt bijvoorbeeld geen losse polygonen tekenen (waar wat voor te zeggen is, aangezien het anders nog trager zou worden ), en de renderstates zijn ook niet echt instelbaar... je kunt hoogstens een paar textures en de diffuse/specular color met elkaar moduleren, en dan houdt het wel op. En terwijl je dat in games nou net wel allemaal nodig hebt. Denk aan back to front sorting voor transparante polygonen, het gebruik van de stencilbuffer in verband met spiegels en schaduwen e.d.. Een occlusion culling algoritme implementeren is ook amper te doen, en bovendien vrij langzaam

Het hele scenegraph gebeuren is wel mooi en abstract enzo, maar in de praktijk heb je er geen malle moer aan. Een game heeft over het algemeen geen hierarchische transformaties, waardoor alle objecten dus min of meer in de rootnode komen te staan.

Dat die mensen maar 36 fps haalden met C++ zegt meer over hun kwaliteiten dan het potentieel van Java3D, en het is dan ook een kromme conclusie

[TheOneLLama]

Ik zie dan liever een fatsoenlijk JAVA Audio API, ipv direct naar de hardware te gaan schrijven. Je hebt gelijk dat ook beter connection API mooi zou zijn, voor alle type connecties dan (USB, Firewire, serieel, parallel, Bluetooth, WiFi, Gameport etc.)

[EJP]

Het lijkt me logisch dat java gene i/o ondersteunt. Zo kan iedere mafketel bij wijze van spreke je usbmodem uitzetten. Het is alleen om de veiligheid dat ze dat juist niet erin hebben gebouwd.

[justice strike]

reply op dustin vogel

jusb hoort niet tot de standaard java library en werkt op dit moment alleen onder unix, er is dus geen jusb voor windows. terwijl usb toch een UNIVERSAL serial bus is. tot dat er een fatsoenlijke implementatie is ben ik en de spelontwikkelaars afhankelijk van wat de opensource community proberen te maken.

en reply of ejp

java heeft geen io niet omdat er geen veiligheid is dan (want dat is complete bullshit) maar omdat het anders niet multiplatform kan zijn, niet elke io system van elk os werkt hetzelfde, omdat een beetje fatsoenlijk in een vm voor elkaar te krijgen is een te grote klus dus hebben ze het maar eruit gelaten en inderdaad hebben ze het aan jni modules overgelaten. maar ik wil niet zelf een jni module schrijven als ik de usb of zoiets wil gebruiken, en als er geen libraries voor zijn dan kom ik ook niet veel verder....

[Remus]

Dat wordt al gedaan door middel van de JNI (Java Native Interface), waarmee bepaalde functies bijvoorbeeld uitbesteed worden aan DirectX op Win32 of anders zelf wordt gedaan danwel uitbesteed wordt aan een vergelijkbaar produkt op het operating system

[Marten]

Hmm.. Klinkt als AWT vs Swing? En java wordt toch al veel gebruikt in online games? Van die applets op websites welteverstaan

[dustin]

Natuurlijk moet je oppassen wat je doet. Je kan dingen lomp maken en dingen goed maken. Natuurlijk moet je het goed doen.

[NBK]

Als ze dan maar wel de echte java gaan gebuiken en niet die van micrsoft ander schiet SUN er alnog niks mee op. En ik moet eerlijk zeggen dat ik nou niet echt onder de indruk ben van de snelheid van java applicaties...
maar dat verklaar het kopje koffie in het logo misschien wel...

[Stewie!]

Java is niet voor niks een ander woord voor "coffee"
En dat is iid echt gekozen omdat de programmeurs/ontwerpers van Java zoveel koffie dronken

En die microsoft variant: C# bedoel je?

En langzaam op windows platform:
-je hebt java
-dan compileer je dat half
-dan zorgt de VM (code op windows, niet IN) dat je t verder compileert
-dan zorgt windows ervoor dat t wordt gecompileerd naar machine taal

hoezo veel stappen

Reactie op hieronder:
C# zit in .NET zit in win kernel
wat denk je dat sneller is?

C#:
- C# code
- MSIL
- JIT compiled alles verder, dit zit in de CLR

Bovendien zit de JIT en de rest van .NET framework echt in de kernel (ja, net 1 milimeter erboven) en niet twee stappen (code + Java VM application) erboven zoals de Java VM.

[VisionMaster]

Leukste is dat dezelfde stappen worden gemaakt bij iedere platform en alleen de onderste twee door jou genoemde lagen worden anders per platform.

maaruh C# werkt ook via een CDL (.Net term: Common Discription Language) => Class achtig uitegevoerd in een VM achtige sandbox en dat soort voorbeweging in je OS en dat zorgt weer voor 1-0 voor je cpu.

waar mis ik je punt

edit: had niet anders verwacht dan dat het systeem van Java af is gekeken. Alleen voordelen in windows natuurlijk ivm java performance

[Verwijderd]

Beweren dat .NET niet op Java lijkt is natuurlijk onzin, maar afgekeken van gaat te ver. C# is net als Java een 4e generatie taal en kent een syntax die een crossover is tussen C++ en Java. Dat boeit natuurlijk niets, want een taal is maar een taal is maar een taal. COBOL lijkt in niets op Java en is ook een taal (geschikt gemaakt) voor .NET.
Over de sandboxes in .NET: dat zijn code access security omgevingen, dat kent Java pertinent niet. De sandbox van Java wordt gevormd door de VM, waarbinnen de Java applicaties draaien. .NET applicaties gaan inderdaad door een JIT compiler die compileert naar native code, maar dit gebeurd alleen de eerste keer, of als het expliciet aangegeven wordt. Het tooltje ngen kan trouwens native images aanmaken, die direct opgeslagen worden in de Native Assembly Cache (een verborgen onderdeel van de Global Assembly Cache) en nooit JIT compiled worden. De CLR is een onderdeel van het OS zoals Java onderdeel is van SUN's JavaOS voor allerhande apparaten.Het ligt dus ingebed in het OS, zoals DaMorpheus al zegt.
Verder: de CLR is niet platformgebonden, dus implementeer de ECMA standaarden voor Linux en de .NET applicaties draaien op Linux. (Windows Forms zijn gebaseerd op de Win32 API, dus dat gaat nog niet (GTK# gaat daar verandering in brengen, maar dat duurt nog even)). Er is geen enkel voordeel van Java boven .NET, behalve de directe beschikbaarheid en de al bestaande enorme community (die voor .NET groeit snel, maar is nog niet zó groot). Ook zijn er enkele ontwerpkeuzes die in specifieke gevallen de schaal doen overslaan naar Java, zoals embedded toepassingen (het .NET Compact Framework is eigenlijk nog te zwaar voor embedded toepassingen. Compatibiliteit met applicaties die gebruikmaken van de volledige kracht van .NET heeft hier een iets te grote rol gespeeld...)

[Stewie!]

Hoe denk je dat .NET in Windows zit? Op dezelfde manier als Java of echt in de windows kernel? T is niet voor niks vanaf windows 2000 kernels!

Het gaat erom dat C# veel sneller dus uitgevoerd wordt dan Java!

[cashewnut]

C# zit in .NET zit in win kernel

De Linux kernel kan ook gecompiled worden met java support (http://www.linuxhq.com/java.html). Tja, als Microsoft ervoor kiest om dat niet te doen en in plaats daarvan hun eigen "standaard" op de markt te brengen...

[Onno]

dan zorgt windows ervoor dat t wordt gecompileerd naar machine taal

[HawVer]

Met de microsoft variant bedoeld hij waarschijnlijk de Microsoft VM mee. Dat is een kloon van de originele Java van Sun.
Over het algemeen geprogrammeerd met Visual J++. Als ze die gaan gebruiken schiet Sun er inderdaad niks mee op.

[mangosap]

Een ander nadeel: geen unsigned integers...

In mijn ervaring kan het voor het programmeren van games erg handig zijn om een beetje te schuiven en te spelen met de bits in een integer: dit is snel en effiecient.

Maar als je steeds rekening moet houden met het 'sign' van de int, dan wordt dit snel erg omslachtig...

[reddog33hummer]

Daar heb je de byte voor

[Verwijderd]

Die is ook signed: [-128..127]

[Firefox]

Tis al wel vaker gezegd... maar wil dat ook aankaarten.

Games hebben een snelle performance nodig. Java kan dat (nu iig) niet bieden.

Kijk maar naar de volgende voorbeelden:

- Citrix Management Console. Handig die tool hoor, maar een ONTIEGELIJKE zware memory footprint (citrix: het wordt afgeraden om de CMC-tool binnen terminal sessies te gebruiken. Het is beter deze op lokaal op een gewoon werkstation te draaien.)
- Novell Console ONE. (het superlatief voor traag is nog niet genoeg om dit te beschrijven. Een megalatief, gigalatief of ultralatief is nodig om dat te kunne beschrijven. )

Lijkt me een stuk wijzer als programeurs hun Dedicated Server code (da's veel interessanter nl) in C++ schrijven voor Linux servers, en daarbij rekening houden voor poorten naar Windows omgevingen ipv de huidige trent "eerst op windows programmeren en tzt misschien eens kijken naar het maken van een Linux_DS. (op dat moment zit er teveel Windows based code in met functie gebruik van bijv. DirectX, en moet je voor een Linux server een aparte code tree bij gaan houden om een werkende linux ds te kunnen leveren (= het probleem waarom EA/DICE nog niet een stabiele Dedicated Server heeft kunnen uitbrengen voor de grote massa Linux-based game hosts.)

[leuk_he]

Kijk maar naar de volgende voorbeelden:

- Citrix Management Console. Handig die tool hoor, maar een ONTIEGELIJKE zware memory footprint

Zou het kunnen zijn dat deze niet juist geimplementeerd zijn? Ik heb ook goed werkende java programma´s gezien, maar ook soms grote slome java applicaties. Op een of andere manier zie je vaker de slome applicaties dan de snelle applicaties.

[gamecreature]

Java KAN een interessant platform voor het ontwikkelen van games zijn. Ik heb 'vroeger' internet games met java (jre1.1) ontwikkeld en de performance was toen goed genoeg voor eenvoudige games.. Maar op dit moment zul je geen Unreal 2003 in Java schrijven...

Alhoewel de Java3D API heel interessant is, omdat deze zowel gebruik kan maken van OpenGL en DirectX..

Ik denk als SUN zijn zinnen inzet op een betere performance, minder geheugen gebruik.. Zie ik de toekomst voor Java goed genoeg in !!

Ook bestaat er de mogelijkheid voor het gebruik van de JNI (Java Native Interface), waarmee hele critische zaken in platform specifieke code geschreven kan worden..

Alleen de garbage collector zou roet in het eten kunnen gooien, aangezien deze te pas en te onpas begint te draaien waardoor het spel even stil hangt...

[Verwijderd]

Eigenlijk ligt de schuld bij Sun zelf. Die blijft als een broedse kip op haar eigen Java ei zitten. Daarmee gaat de ontwikkeling van Java veels te traag. Het is er misschien allemaal wel maar het blijft achter lopen bij andere talen.

[Verwijderd]

Ze hebben idd een goed punt met hun platform onafhankelijkheid. Nu er steeds meer (vooral op de aziatische markt) pc's met bv linux in de supermarkten te vinden zijn.
Ze gaan wel zoals NBK zegt iets aan hun snelheid moeten doen. Want hun virtual machine is vreselijk traag en nukkig. Voor een simpele toepassing is java zeker snel genoeg. Maar voor de huidige 3D games
Dat argument van MS is enkel windows afhankelijk. Het heeft zelfs dacht ik niet zoveel te doen met de taal zelf. Enkel het feit dat Microsoft een eigen virtual machine heeft ontwikkeld om Java-code in windows te kunnen gebruiken. Maar als game-verkoper doe je gewoon voor ieder platform een java virtual machine erbij.

[C00P]

In welke talen worden games nu voornamelijk geschreven, en welke voordelen heeft Java tenopzichte van de nu gebruikte talen ?

[Verwijderd]

Spellen worden bij mijn weten vooral in C en C++ geprogrammeerd.

Het onderscheid Java ten opzichte van C/C++? Wel, Java zit ietsje "properder" in elkaar, en houdt de programmeur iets meer bij het handje. In C / C++ moet de programmeur bijvoorbeeld regelmatig eraan denken om geheugen vrij te geven dat hij heeft aangevraagd; in Java zal de Virtual Machine zulk geheugen automatisch vrijgen ("garbage collection"). Dit voorbeeldje geeft al aan waar 'm eigenlijk het verschil ligt tussen de twee: Java zal een heleboel automatiseren, maar dit gaat wel wat ten koste van de snelheid. Automatische garbage collection is meestal trager dan manuele garbage collection zoals bij C / C++.

Java heeft voor de rest als voordeel dat het, zoals hoger reeds gezegd, platform onafhankelijk is, al moet je dat wel met een korreltje zout nemen. C / C++ kan ook voor grote delen platformonafhankelijk zijn als je de juiste libraries gebruikt, en programmeurs in Java moeten er toch dikwijls aan denken dat deze of gene functie beter of niet werkt in bepaalde besturingssystemen.

[NeoCarnifex]

Games worden voornamelijk geschreven in C/C++. Maar niet voor de volle 100%. Meestal is de engine geschreven in C/C++, zeg maar het technisch gedeelte van het spel. Het logische gedeelte, zeg maar de beschrijving van de spelregels zelf worden vaak in een scripttaal geschreven die net als java vaak portable is. Denk aan Quake-C, en UnrealScript. Deze kun je 1x schrijven, 1x compilen, en daarna kun je die code zonder probleem gebruiken op Unreal op Windows, Linux of AppleOS. Carmack, de prog. van Quake, heeft ooit Java willen gebruiken (zie http://www.gamasutra.com/features/19990611/java_13.htm over Java en games) maar porting problemen deed het plan de das om. Daarom is er gekozen om zelf een soort JavaVM te maken, de Quake engine die dus onafh. van het OS QuakeC code kan draaien. Zelfde voor Unreal met compiles UnrealScript.

Spellen die java gebruikt hebben:
Vampire: The Masquerade
Prax War

[Firefox]

zover ik weet: C++

Voordeel:
C++ moet je "porten" naar een ander OS, en dan opnieuw Compileren. maw, er komen aparte binaries voor Linux, (native)FreeBSD, Mac, Windows etc.

JAVA is 1x schrijven en overal werken doordat het gebruik maakt van een java virtual machine... zoals SUN het bedoeld heeft, en Microsoft dat een tikkeltje heeft lopen frustreren.

da's dan ook de reden dat in de mobieltjes wereld hier veel gebruik van gemaakt wordt... snelheid is vaak niet zo'n issue, maar het aantal OS-en waar de verschillende GSM-en onder draaien is HUGE. een java-toepassing werkt op elke java enabled gsm.

Nadeel: Doordat er een virtual machine tussen zit om de java toepassing binnen te draaien zit er extra code in de weg. -> extra geheugen gebruik, en extra CPU usage. dit vertraagt, en is in moderne spellen niet acceptabel.

[Johnny]

Woedt er met online gaming niet spelletjes in de browser bedoeld waar je nu vaak Flash en Shockwave ziet?

[P.i.R.h.o.]

Ik denk dat ze met Online games wel degelijk multiplayers bedoelen (Quake, Unreal, Everquest, ...) omdat het in Java heel makkelijk is om netwerkfuncties te programmeren. Veel makkelijker dan bvb in C++ met sockets te werken.

Het nadeel is en blijft natuurlijk de vertragende VM...

[Verwijderd]

Een nadeel is dat de multimedia mogelijkheden van Java veel minder zijn dan de alternatieven. En als je daar toch gebruik wilt van maken je toch sneller de kans loopt om platform afhankelijk te worden.
Wat dat betreft is Shockwave Flash veel handiger lijkt me.
En ze hebben nog steeds last van een negatieve reputatie wat jammer genoeg onterrecht is.

[SlasZ]

wel er bestaat een shockwave-versie van quake3 die je volledig in je browser kan spelen, maar die werd op verzoek van ID-software verwijderd.

Zie: http://www.gamers.nl/nieuws/14629

Ik denk dat java wel geschikt is voor 3D-games. Eenmaal opgestart is java niet veel trager dan C++, al is het wel zo dat je in C++ veel meer kan optimalizeren, en ook het geheugengebruik is veel lager in C++.
Moest het mogelijk zijn de garbagecollector in java uit te schakelen en zelf het geheugen te beheren zou het al veel interessanter zijn denk ik.

[progster]

flash is nu niet echt platform onafhankelijk lijkt me, ik geloof er nog altijd geen (stable) flashmx ondersteuning is voor linux. En shockwave (dat is nog iets anders) werkt enkel onder windows en ENKEL in msie.

edit: een voorbeeldje hiervan is http://www.isketch.net/ (klik maar is op "play now")

~Progster

[SlasZ]

akkoord, ik wil maar zeggen dat het zeker mogelijk is geavanceerde games te maken in niet zo conventionele programmeertalen zoals shockwave of java

[Verwijderd]

Leuk voor Sun maar ehm ik denk toch echt dat dit nogo is...
Ik bedoel toen ik nog java van de MS site kon downloaden waren JAVA onderdelen stukken sneller! De JAVA van Sun is vrij langzaam...

Ik werk ook op een helpdesk waar dit probleem vaker een vraag is...

De mensen willen dan JAVA van MS maar ja op een officiële helpdesk kan ik helaas niet zeggen zoek met google op: Download microsoft virtual machine

[Remus]

Inderdaad de Java VM voor applets is zeker traag in vergelijking met die van MS, en hoe komt dat? Omdat MS allerlei shortcuts in de code kan maken, niet-standaard java-oplossingen implementeerde etcetc. Overigens ondersteunt de MS VM maar tot Java 1.1 itt Java 1.4.1 voor de laatste (non-beta) Sun VM.