Sun-ontwikkelaar: 'Java moet alsnog desktop veroveren'

De Java-programmeertaal is inmiddels ruim 12 jaar oud. Dat gecombineerd met de presentatie van JavaFX enkele dagen geleden, was voor C|Net reden om in gesprek te gaan over allerlei Java-onderwerpen met Java-goeroe en -ontwikkelaar James Gosling.

In zijn eerste serie antwoorden legt Gosling uit wat JavaFX is en hoe het gebruikt kan worden. JavaFX is een van de projecten om ervoor te zorgen dat Java meer gebruikt gaat worden bij de ontwikkeling van clientsoftware. Met behulp van JavaFX Script zou dit mogelijk moeten zijn, omdat deze taal specifiek bedoeld is voor het bouwen van dynamische, interactieve en animatierijke gui's al dan niet voor het web. Volgens C|Net gaat Sun hierdoor terug naar de roots van Java, de taal is namelijk voorzien van verschillende functies om de gebruikservaring van applicaties op het web te verbeteren. Gosling is het eens met deze stelling en vult aan dat onder meer de applet-, de 2d graphics- en de Swing-technologie hieraan hadden moeten bijdragen. Zonder duidelijke aanwijsbare reden heeft de applettechniek echter weinig succes gehad, aldus Gosling.

Een van de mogelijke redenen dat Java-applets nooit veel succes gehad hebben, vertelt C|Net, is dat Adobe met Flash en sinds kort Microsoft Silverlight het veel makkelijker maken om interactieve sites te bouwen. Onder meer die concurrentie heeft Sun ertoe aangezet om het makkelijker te maken om Java in clientsoftware toe te passen en dat is waar JavaFX het resultaat van is, aldus de Java-goeroe. Begin deze week heeft Sun bekendgemaakt dat het open source maken van Java is afgerond. Gosling was en is daar echter geen voorstander van: hij is bang dat er incompatible Java-varianten zullen verschijnen. Hij merkt echter op dat de kans dat dit gebeurt erg klein is, omdat iedere Java-ontwikkelaar ervan uitgaat dat zijn applicaties op elke Java-implementatie werkt. Gevraagd naar zijn mening over het resultaat van het open source maken van Java, vertelt Gosling dat hij daar nog weinig over kan zeggen, omdat de vrijgave nog te kort geleden is om concrete resultaten te laten zien.

Reacties (79)

[Blorgg]

Heuh? Java moet de desktop veroveren? Alsjeblieft niet zeg. Ondanks alles wat de Java aanhangers beweren is Java programmatuur nog steeds enorm langzaam en moet je zo'n Java virtuele machine hebben die je standaard erg regelmatig lastig valt met een zijn langzame update procedure.

Van mij mogen ze dat Java na 12 jaar nou eindelijk wel eens gaan begraven voor de desktop, om van web applicaties nog maar te zwijgen.

[Little Penguin]

Ik heb 5 jaar lang een Java webapplicatie onder beheer gehad en die was absoluut niet langzaam. Sterker nog in hetzelfde project was ook een SOAP server geimplementeerd in Delphi en die is vanwege o.a. schaalbaarheid nu omgezet naar Java.

Verd is Java niet traag (meer) en kan de taal zich uitstekend meten met andere omgevingen. Ik zie dus niet in waarom Java op de desktop niet zou kunnen.

Ik denk dat je dit idee opgedaan heb toen de systemen nog te traag waren voor VMs, maar inmiddels is dat dus niet meer zo, blijkbaar heb je dus verouderde inzichten...

[JeromeB]

Blorgg heeft het over desktop-applicaties, maar je voorbeeld is een webapplicatie. Ik neem aan dat je die web-applicatie op een aparte server had draaien en niet op je desktopcomputer die je ook dagelijks gebruikt voor andere toepassingen.
Als ik een Java-desktop-applicatie opstart dan werkt het wel redelijk, maar het vraagt eigenlijk iets teveel van mijn systeem. Mijn systeem wordt dus wel degelijk trager en dat bevalt mij niet.

[demonite]

(ten eerste) woohoo java is een gevoelig onderwerp hier!

Ten 2e: Tomcat en Websphere zijn best leuke dingetjes en die werken ook best aardig. Maar heb jij wel 's een java desktop app regelmatig gebruikt? Ik gebruik op het moment Poseidon, een UML tool met een erg fijne user interface, in java geschreven (gedeeltelijk opensource) en behoorlijk prijzige pro/entr license.. Maar dat is dus echt wel traag. Ondanks dat het op een vrij deftige workstation draait.
MS Visio die vergelijkbare functionaliteit heeft (alleen bagger interface naar mijn mening) draait ZO veel vloeiender.. en zo ook Eclipse IDE is ook nie vooruit te branden.

[tjerkw]

Java lijkt voor jou traag omdat die applicaties eerst zelf een JVM opstarten. En dat is inderdaad traag. Ze zouden de JVM gewoon meteen moeten laden.. dan gaat JAVA retesnel.

[demonite]

ik had het niet over de lange opstarttijd... daar leer je wel mee leven, die 2 applicaties die ik noemde gebruik je toch voor langere tijd..
Het is gewoon in het gebruik erg langzaam. Die tig lagen die tussen het afhandelen van een muisclick en het openen van een context menu zitten of het selecteren van objecten bijvoorbeeld... gewoon het normale gebruik van de applicatie valt mij tegen als ik het vergelijk met niet-java applicaties.

[catfish]

het verschil is dat Java over de jaren VEEL sneller is geworden door de constante ontwikkeling
Delphi is gewoon een ouderwetse taal die alleen nog gebruikt wordt omdat veel (oudere) programmeurs niet anders kunnen/willen

[J.J.J. Bokma]

Voor je meer uit je nek kletst moet je eens gaan googlen op Free Pascal en Lazarus.

[roy-t]

ik ben zelf een C#-er maar ik snap deze post niet, Java voor grote desktop applicaties wordt veel gebruikt en voelt niet langzamer aan, alleen voor kleine programmatjes is dit van belang / een probleem.

[J.J.J. Bokma]

Ik herhaal mij nog maar een keer want die mythe is erg hardnekkig:

"Zoals ik al recent schreef: heel veel performance issues met Java liggen aan de programmeur die clueless is. Die zal in C/C++ ook rommel bakken."

[crashmatrix]

En ook daarbij een voetnoot, want al is Java de afgelopen jaren zeker een goed systeem geworden, en is het op executie tijd gigantisch vooruit gegaan, zal het nooit op het zelfde niveau komen als native gecompileerde applicaties.

Nu is dit voor zeer grote stukken bedrijfssoftware niet essentieel, maar laten we wel stellen dat de keuze tussen een interpreted/bytecode/JIT compiled taal en een standaard compiled taaltje nogsteeds van dermate belang is dat het argument dat Java snel genoeg is even snel van de tafel wordt geveegd.

[tjerkw]

Java kan zelfs sneller dan native gecompileerde talen. Als je de JVM in server mode draait worden bepaalde code gecompileerd naar native code. Dit is de code die het meest wordt uitgevoerd (90% van de tijd wordt uitgevoerd in 10% van de code).
Daarbij analyseert de JVM de code en zorgt dan voor bepaalde optimalisatie stappen die niet mogelijk zijn bij static compilation.

Bron:
http://java.sun.com/products/hotspot/docs/general/hs2.html

En een mooie regel:
The extensive inlining enabled by the Java HotSpot dynamic compiler gives it a huge advantage over static compilers.

Houden die C++ die-hards nu een keer hun mond?

[Apache]

Java is iets waar echt zeer zeer zeer veel FUD rond hangt, sommige applicaties die bvb SWT gebruiken weten gebruikers zelfs niet eens dat het een java applicatie is, maar toch blijven ze roepen dat java traag is.

Ik lees hier dat java zeker voor webapps moet verdwijnen, java webapps zijn een pak sneller dan de gemiddelde php applicatie en er zijn veel fijnere & verder ontwikkelde frameworks voor beschikbaar. Gmail is trouwens ook geimplementeerd in java, ik denk niet dat die applicatie als traag beschouwt word. Google gebruikt het trouwens wel voor meerdere projecten en dankzij hun hebben we er ook een leuk view framework bij nl. gwt.

Ik geloof ook nog steeds in java op de desktop, dan liefst wel met swt dan met swing want die heeft inderdaad nog steeds een achterhaalde look&feel hoewel de grote verbeteringen van 1.6, qua snelheid is er niets mis meer mee in ieder geval.

Java developer heeft helemaal niets te maken met een religie, maar je kan er wel verliefd op worden door de fantastische tools, frameworks, technologieën die ervoor beschikbaar zijn en dan kijk je niet meer snel nog naar iets anders.

[peke]

Inderdaad, en met versie 1.6 is Java in sommige gevallen tot 15% sneller dan vorige versies.
Daarbij is Java een heel rijk platform.
Zo heb je zoals je zei SWT (niet in de standaard) om per platform een native look and feel te verkrijgen, je hebt JNI om native code aan te roepen (dus je kan evenveel als met C/C++, je hebt zeg maar best of both worlds).

Ik heb zelf al met .NET (C# en VB.net), Java en C++ gewerkt en ik vind Java toch de betere taal/platform.
Omdat Java:
* Open source is.
* Vele goede IDE's het ondersteunen (Netbeans, Eclipse, ...).
* Platformonafhankelijk voor de meeste applicaties is.
* Op het gebied van Threading superieur is aan .NET (implementeer Runnable in Java en je bent klaar, het blijft allemaal heel netjes itt .NET waar je vaak moet rotzooien met invoke).
* Java2D is heel uitgebreidt en ondersteundt OpenGL acceleratie sinds 1.5 (als je het aanzet), je hoeft hier verder niets speciaal voor te doen. Verder is Java2D ook bakken sneller dan GDI+ van .Net.

En zo kan ik nog tientallen redenen bedenken.

De echte reden waarom Flash zoveel populairder is dan Applets zal in werkelijkheid zijn dat Flash een veel lagere instapdrempel heeft.
Voor Java moet je een hele taal kennen en voor Flash enkel wat actionscripting (alhoewel AS3.0 ook een hele taal op zich is).
Door de eenvoudige dingen op de stage te doen en de complexere met ActionScripting heb je met Flash bovendien een heel snel resultaat.

Dat het is omdat de VM van 12MB moet geladen worden is gewoon onzin, de meeste mensen weten niet eens wat de VM is, laat staan dat ze zich storen aan het starten ervan.

[Verwijderd]

Java developer heeft helemaal niets te maken met een religie, maar je kan er wel verliefd op worden.. ...en dan kijk je niet meer snel nog naar iets anders

En waarom denk je dat ik op de vergelijking met "religie" kwam?????

[jopiek]

idd, geef mij maar Pascal... Pascal is platformonafhankelijk, veel sneller dan Java, mooiere interfaces, leesbaardere code, etc. etc. etc.

als ik moet kiezen om een leerling for (int i = 0; i<10; i++) { } aan het verstand moet prustsen of het elegante: for i := 0 to 9 do begin end; dan weet ik het wel...

[mux]

Java is verdorie niet alleen een applet-taal! Mensen vinden het niet fijn dat een hele VM moet worden geladen ipv een klein pluginnetje om interactieve content te renderen.

Java is een *prima* alternatief voor C voor het programmeren van welke applicatie dan ook, met als gigantisch voordeel platformonafhankelijkheid (nou ja, tot op een zeker niveau). Zeker nu apple, onterecht naar mijn mening (maar daar heb ik gewoon niks over te zeggen), in opkomst is zullen meer en meer mensen zien dat er alternatieven zijn voor windows en die ook gebruiken. Als multidisciplinaire devver kan ik niet genoeg krijgen van java :-).

Nu met opensourcing is er nog meer te doen en te maken. Java is in deze tijd van toenemende gebruiksvriendelijkheid, dus ook voor programmeurs, een gedoodverfde winnaar in het veld van programmeertalen.

[Little Penguin]

Mensen vinden het niet fijn dat een hele VM moet worden geladen ipv een klein pluginnetje om interactieve content te renderen.

Dit probleem geldt net zo goed voor Silverlight en misschien ook nog wel een beetje voor Adobe's Flash - op dit punt staan de omgevingen dus gelijk.

Waarschijnlijk heeft Java als grootste probleem dat ze gewoon te vroeg waren. Java moest kunnen werken op een 166MHz pentium en daardoor voelde het traag aan. Flash is later gekomen en voelde direct snel aan en dat perceptieverschil is gebleven...

[mashell]

Java is een *prima* alternatief voor C voor het programmeren van welke applicatie dan ook

Alleen als je ze op een heel dikke desktop laat draaien. Voor kleinere (lees goedkopere of embedded) systemen is er geen alternatief voor C.

[Herko_ter_Horst]

Onzin, juist in toepassingen voor kleinere devices (mobiele telefoons) en embedded systemen neemt Java de laatste tijd een grote vlucht. Door gebruik te maken van Java, maak je je applicatie in één keer voor verschillende platformen (maakt niet uit of je op een Nokia onder Windows ME/Phone draait, of op een SonyEricsson onder Symbian: het Java platform is hetzelfde).

Op embedded systemen zijn daarnaast de mogelijkheden voor het dynamisch laden van code (at runtime, dus zonder het systeem te hoeven herstartenm, wat in dergelijke vaak mission-critical toepassingen uit den boze is) een belangrijke feature.

[.oisyn]

En kijk dan eens voor de grap in het verschil tussen Java applicaties en Symbian applicaties (die laatste zijn in C++ geschreven en compileren naar native code). Met native code is zoveel meer mogelijk - ik heb nog geen Java game gespeeld die echt vloeiend en responsive aanvoelt. Daarentegen draaide Doom een paar jaar terug al fatsoenlijk op Symbian telefoons.

Bottom line is dat een mobiele telefoon geen desktop is, en zeker op die gelimiteerde CPUs is de Java performance echt om te huilen. Wat graphics betreft ben je echt afhankelijk van wat de API je biedt (zodat dat native geimplementeerd kan worden), zelf pixels plotten is er niet echt bij.

[Mars Warrior]

Onzin, juist in toepassingen voor kleinere devices (mobiele telefoons) en embedded systemen neemt Java de laatste tijd een grote vlucht. Door gebruik te maken van Java, maak je je applicatie in één keer voor verschillende platformen (maakt niet uit of je op een Nokia onder Windows ME/Phone draait, of op een SonyEricsson onder Symbian: het Java platform is hetzelfde).

Aha, en daarom staat er bij die programmaatjes altijd een lijst van compatibele telefoons zeker

[Ximinez]

Door gebruik te maken van Java, maak je je applicatie in één keer voor verschillende platformen (maakt niet uit of je op een Nokia onder Windows ME/Phone draait, of op een SonyEricsson onder Symbian: het Java platform is hetzelfde).

Deels waar, de uitvoerbare bytecode is inderdaad op verschillende platformen te draaien. Echter heeft geen van alle devices een uniforme display en resolutie. Je zult nog steeds een "device afhankelijke" implementatie moeten maken, niet op code niveau maar in het user interaction domein.

[tjerkw]

Voor spellen is dit waar, maar voor gewone applicaties ( bedrijfsapplicaties bijvoorbeeld ) is dit niet meer nodig. Door gewoon gebruik te maken van de MIDLET API (J2ME) werkt je applicatie op elke resolutie, de fabrikant van de mobieltje bepaalt namelijk waar een bepaalde knop komt.

De programmeeur geeft niet aan WAAR de knop komt maar geeft aan wat de semantiek, betekenis van de knop is. Bijvoorbeeld Knop a is een ACTIE knop. Knop b is een TERUG knop.

[J.J.J. Bokma]

http://en.wikipedia.org/wiki/Tini

Mis dus.

[crashmatrix]

Het zou leuk zijn daarbij te vermelden dat de TINI een ongelooflijk onstabiel embedded systeempje is welke een uiterst beperkte subset van de Java API draait, oftewel, leuk prototype, en bruikbaar voor sommige dingen, maar geen goed voorbeeld van een crossover embedded device / Java VM

[kvaruni]

Zeker nu apple, onterecht naar mijn mening, in opkomst is.

Kan je dit nader verklaren? Waarom is het in jou opzicht onterecht? Bedoel je dit ten opzichte van dit artikel en het gebruik van Java of was dit algemeen bedoeld?

Nu, in beide gevallen graag wat aanvulling dus

[Verwijderd]

Apple is altijd al het meest vooruitstrevende en daarnaast meest stabiele "client" os geweest.

met twee hele grote nadelen
-Dure hardware
-Geen goede game ondersteuning

Sinds apple Intel based is en dus duall boot windows kan draaien is het onderste nadeel geen nadeel meer. Maar ze bliiven wel duur.

[Ackermans1973]

Waarom zou ik dure hardware kopen om daarop dual boot Windows te kunnen draaien?

Waarom zou ik dan niet gewoon goedkopere hardware kopen, en daar Windows op draaien?

Wat heeft Apple dan meer te bieden?

[catfish]

lol, dan ga je dus Windows draaien op een Mac om games te spelen... sorry maar dan vraagt 99% van de mensen zich af waarom er nog OSX op staat
enkel tweakers draaien 2 OS'en op 1 computer

btw, Apple is geen OS
OSX heeft een goede reputatie, maar zeg nooit dat bv OS9 stabiel is/was, want dat was het echt wel niet hoor

[johnbetonschaar]

met twee hele grote nadelen
-Dure hardware
-Geen goede game ondersteuning

Punt 1 is wat mij betreft een soort van myth die maar eens gebust moet worden. Apple heeft hardware in alle prijsklasses van goedkoop tot duur, van midrange tot high-end. Een fatsoenlijke iMac C2D heb je al voor 999 euro, daarvoor krijg je een 100% compleet systeem met een OS license. Een mac Mini gaat al vanaf 550 euro.

Inderdaad, als je alle onderdelen afzonderlijk telt zou je in theorie voor een paar euro's minder gelijkwaardige onderdelen kunnen kopen, maar dan heb je niet hetzelfde product, maar een luidruchtige lelijke budget kast met allemaal losse randapparaten en een knaken-monitor erop. Daarbij kan je die PC niet puur op de specs vergelijken met een OS X machine, want OS X gaat naar mijn ervaring veel efficienter om met de hardware, waardoor je meer haalt uit dezelfde specs. Last but not least is die apple hardware na 2 jaar nog het dubbele waard van wat een zelf inelkaar geschroefde standaard PC of een simpele Dell nog waard is.

Punt 2 is voor de meeste mensen helemaal niet relevant. Het is misschien een verassing, maar niet iedereen gebruikt zijn PC om te gamen.

[Neko Koneko]

OSX is stabiel omdat Apple er gewoon een soort Unix distro van gemaakt heeft. Verdient Apple weinig credit voor, hooguit voor het nemen van het besluit om het zo aan te pakken.

Apple zelf kan nog steeds niks, Apple software vind ik persoonlijk allemaal rotzooi

[Jack Flushell]

Volgens je profiel heb je geen ervaring met OSX of AppleOS. Bovendien lijkt het me erg kort door de bocht om te zeggen dat _alle_ applicaties rotzooi zijn. Veel dingen zijn erg vergelijkbaar met Windows (Photoshop anyone?)

[Laurens-R]

Ach zo blijft het he. Je zal altijd mensen houden die er anders tegenaan kijken dan jezelf. Zodra populariteit toeneemt, groeit ook het aantal tegenstanders. Doe je nix aan en deze houden Apple tevens scherp en bij de les.

Ook al ben ik voor Apple, ik ben ook voor tegenstand tegen Apple!

[Barbapapa720]

..., ik ben ook voor tegenstand tegen Apple

min min is plus. Je bent dus voor Apple. Punt is duidelijk.

[Verwijderd]

Java is een *prima* alternatief voor C voor het programmeren van welke applicatie dan ook...

Van zodra je applicatie enigszinds performantiekritiek is, is Java echt geen optie. Multimediabewerking, een wetenschappelijke simulatie, actiespelletjes, etc. Genoeg voorbeelden waar C/C++ de enige doordachte optie is. Voor een GUI is Java een "alternatief" ja, maar ook niet veel meer dan dat.

...met als gigantisch voordeel platformonafhankelijkheid ...

Waarom zou dat zo'n gigantisch voordeel zijn? Als je een beetje oplet is C/C++ ook voor meerdere platformen te compileren. Heeft meer te maken met welke bibliotheken je gebruikt dan de taal zelf.

[Verwijderd]

Van zodra je applicatie enigszinds performantiekritiek is, is Java echt geen optie.

Dit worden echter hoe langer hoe minder applicaties.
Dingen als mailclients, webbrowsers, office-suites (OpenOffice!!) etc. zouden allemaal prima in Java kunnen draaien. Vanwege hardware-acceleratie zijn ook dingen als video-decoding tegenwoordig niet meer CPU-vretend... en op sommige moderne videokaarten kun je ook al hardwarematig encoden...
Als er straks ook nog gebruik gemaakt gaat worden van dingen als physics-hardware of gewoon GPGPU etc, dan blijft er voor veel applicaties weinig meer dan een GUI over. Java zou dat prima kunnen.

Waarom zou dat zo'n gigantisch voordeel zijn? Als je een beetje oplet is C/C++ ook voor meerdere platformen te compileren. Heeft meer te maken met welke bibliotheken je gebruikt dan de taal zelf.

Lijkt me toch logisch? Java is niet alleen een taal, maar een platform.
Als je de JVM eenmaal hebt, kun je alle Java-applicaties zonder problemen draaien.
Bij C++ moet je de sourcecode hebben, en moet je die kunnen compileren op jouw systeem (wat een doorsnee gebruiker dus niet kan), pas dan kun je er hetzelfde mee dan met Java (afgezien van managed C++ in .NET dan, maar je kunt niet alle C++ code klakkeloos voor .NET compileren, en de .NET VM is veel minder wijd verspreid dan de Java VM).
Is dus toch wel een belangrijk voordeel van Java... zeker in applicaties die via het internet aangeboden worden.

[.oisyn]

Als er straks ook nog gebruik gemaakt gaat worden van dingen als physics-hardware of gewoon GPGPU etc, dan blijft er voor veel applicaties weinig meer dan een GUI over. Java zou dat prima kunnen.

Ik hoef jouw echter niet uit te leggen (gezien je topic op GoT van onlangs ) dat er voor het aanspreken van dergelijke hardware ook CPU power nodig is. Denk aan visible surface determination, LODing en spatial subdivision voor je physics. De hardware is voornamelijk belangrijk voor het doen van de berekeningen, maar je kan niet zomaar even al je data offloaden naar de hardware en die het maar uit laten zoeken.

Voor dat soort dingen is Java nog altijd afhankelijk van native implementaties die dit allemaal voor je oplossen.

En dan nog een heel belangrijk punt: ik heb nog geen compiler of VM gezien voor imperatieve talen (C++, Java) die normale floating point berekeningen kan vectorizen voor de CPU (zoals bijv. voor de SSE instructieset). De gangbare C en C++ compilers ondersteunen echter speciale types en intrinsic functies die direct naar SIMD machinecode compileren. Dit scheelt echt zo enorm veel qua performance, en alle games voor de PC van tegenwoordig vereisen SSE of zelfs SSE2. Dit om even aan te geven hoeveel er gebruik van gemaakt wordt

In Java is er geen enkele manier om zulke functionaliteit aan te spreken, je zal erop moeten vertrouwen dat de JIT compiler je code snapt en het kan vectorizen, wat een enorm lastig probleem is.

[Verwijderd]

Ik hoef jouw echter niet uit te leggen (gezien je topic op GoT van onlangs ) dat er voor het aanspreken van dergelijke hardware ook CPU power nodig is. Denk aan visible surface determination, LODing en spatial subdivision voor je physics. De hardware is voornamelijk belangrijk voor het doen van de berekeningen, maar je kan niet zomaar even al je data offloaden naar de hardware en die het maar uit laten zoeken.

Klopt, maar dan heb je het wel over cutting-edge 3d applicaties.
Je kunt al een heel eind komen met iets minder CPU-power. Laten we zeggen dat een spel als Quake 3 absoluut geen probleem is in Java, om het zo maar eens te stellen. En daarmee zou je al een hele hoop leuke interactieve dingen kunnen doen... Bv een makelaars-website waar je vanaf je browser een kijkje in de huizen kunt nemen (eenvoudig model van het huis met foto's als textures op de muren ofzo).

Voor dat soort dingen is Java nog altijd afhankelijk van native implementaties die dit allemaal voor je oplossen.

Valt ook wel mee hoor. Je kunt alles doen in Java, het is alleen wat trager. Nou, dat komt dus neer op net ff wat minder detail in je 3d-wereld, maar dat is niet zo'n ramp voor een hoop toepassingen. Als ik zie hoe sneu Second Life eruitziet... en de hype eromheen... Bewijst wel dat cutting-edge graphics etc niet altijd nodig zijn. Had in Java ook best gekund.

In Java is er geen enkele manier om zulke functionaliteit aan te spreken, je zal erop moeten vertrouwen dat de JIT compiler je code snapt en het kan vectorizen, wat een enorm lastig probleem is.

Ja, maar dat is ook niet het punt. Natuurlijk kun je via Java niet altijd het uiterste uit je hardware halen.
Mijn punt was meer dat dat ook helemaal niet nodig is, in de meeste gevallen. Als het wel nodig is, gebruik je gewoon geen Java... Maar voor de rest zou het prima kunnen.

Sowieso worden de CPUs ook steeds sneller (en steeds meer gebottleneckt door cache, geheugen en bussnelheden etc, waardoor SIMD minder effectief wordt)...
Zo ben ik niet al te lang geleden overgestapt van een Athlon XP 1800+ naar een Core2 Duo E6600.
Laat ik het zo zeggen... M'n nieuwe PC is met Java-code in bijna alle gevallen sneller dan m'n oude was, met compleet getunede code met SIMD en alles erop en eraan. En op die oude PC kon ik toch ook al behoorlijk boeiende code draaien... Heb er nog verdienstelijk Half Life 2 op gespeeld bv, met physics en al, hoog detail.

[.oisyn]

Lees nu nog eens even je eigen alinea door die ik quotte in mijn reactie, want dat was waar ik op reageerde. Als er dingen door hardware worden opgelost betekent dat niet dat er alleen maar een GUI over blijft (sowieso heb ik nog nooit een reguliere niet performance kritieke app gezien die gebruik maakt van een full blown physics engine, maar goed), en dat soort apps zijn nog steeds niet in Java te implementeren. Dat veel andere dingen wel in Java te implementeren zijn ontken ik ook helemaal niet

Verder moet je niet al mijn opmerkingen niet op jouw reactie persoonlijk betrekken. Het stuk over SSE was een algemene uitleg waarom Java nooit die performance zou kunnen halen, en was niet specifiek aan jou gericht.

[Verwijderd]

Lees nu nog eens even je eigen alinea door die ik quotte in mijn reactie, want dat was waar ik op reageerde. Als er dingen door hardware worden opgelost betekent dat niet dat er alleen maar een GUI over blijft (sowieso heb ik nog nooit een reguliere niet performance kritieke app gezien die gebruik maakt van een full blown physics engine, maar goed), en dat soort apps zijn nog steeds niet in Java te implementeren. Dat veel andere dingen wel in Java te implementeren zijn ontken ik ook helemaal niet

Ik snap je punt niet... Apps die niet in Java zijn te implementeren, als in technisch onmogelijk?
Tuurlijk niet.
Je kunt sowieso al via JNI, met wat C++ 'lijm' alle bestaande hardware-APIs/drivers aanspreken... En Sun heeft voor bv OpenGL al een directe koppeling in Java opgenomen... Ik zie niet in waarom dat niet met bv PhysX of andere toekomstige hardware zou kunnen.
Met .NET kun je toch ook vanuit de VM dingen als DirectX aanspreken?

Alles kan... het is alleen wat minder snel... Wat dus niet altijd een bezwaar is (hele websites en andere meuk worden met php/mysql gebouwd, en dat verdient al helemaal niet de schoonheidsprijs... het is zeker niet snel of efficient, maar het is wel 'snel genoeg').
Voordeel is wel weer dat Java-code bijzonder compact is (sowieso een hele compacte instructieset, en dingen als loop-unrolling hoeven pas gedaan te worden bij de JIT-compilatiestap).
Kortom, ik vind het idee van Java op de desktop helemaal zo gek nog niet.

[J.J.J. Bokma]

Zoals ik al recent schreef: heel veel performance issues met Java liggen aan de programmeur die clueless is. Die zal in C/C++ ook rommel bakken.

[Gyske]

Van zodra je applicatie enigszinds performantiekritiek is, is Java echt geen optie.

Voor iedereen die denk dat java niet gebruikt kan worden voor 'serieuze' high performance mission/safety critical applicaties: RTJ (Real Time Java).
Lees hier een paar berichten over systemen die mbv van Java geimplementeerd worden/zijn:
- National Oilwell Varco Selects Aonix PERC for Java™-based Robotic Drilling
- Lockheed Martin Selects Aonix PERC Virtual Machine for Aegis Weapon System
L-3 Telemetry Selects Aonix PERC VM for Upgrade of Java™ Real-Time Data Acquisition System
(Ik heb geen enkele band met Aonix of aanverwante bedrijven en programmeer zelf in C en Java software voor de luchtverkeersleiding industrie)
Serieuze (C(++)) programmeurs die denken dat Java nog niet voor hun serieuze werk geschikt is, doen er denk ik goed aan eens een beetje rond te kijken op de site van Aonix. Het is natuurlijk een beetje commercieel getint, maar de technische achtergronden en whitepapers zijn toch interessant. Ze vertellen ook het een en ander over hoe de problemen rond timing, memory management en Garbage Collection zijn opgelost.
Ik moet trouwens wel toegeven dat real-time java niet voor gewone stervelingen (lees organisaties met laag budget) toegankelijk is. Dat doet alleen niet af aan het feit dat Java er wel geschikt voor is.

[BartOtten]

Qt iemad of sla ik dan compleet de plank mis? Dan kan je devven voor de 3 platformen voor de desktop: Windows, Mac OS en Linux. Lijkt me genoeg en schijnt een zeer makkelijke ontwikkeling te bieden.

BO heeft geen kaas gegeten van programmeertalen voor de desktop

[Verwijderd]

Zonder duidelijke aanwijsbare reden heeft de applettechniek echter weinig succes gehad, aldus Gosling.

Daar had men dan wel even onderzoek naar mogen doen. Als je van het verleden al niet kunt leren hoe weet je dan waar je in de toekomst heen moet? Ik denk dat als men een beetje beter had gezocht dat er wel wat redenen gevonden zouden zijn. Maargoed,.. persoonlijk heb ik java altijd al iets gevonden waarbij de community in sneltreinvaart met oogkleppen op vooruit stoomt zonder echt te kijken waar vraag naar is.

Groot, log en opdringering; ik wil bijvoorbeeld helemaal niet dat Java system resources opvreet bij het opstarten van mijn systeem en mijn boot-time vergroot. Ja, ik krijg dat wel uitgezet, maar de gemiddelde gebruiker niet,.. en bij iedere update krijg je weer de hele sh*t door je strot geduwd waarbij je het weer handmatig uit moet zetten. Het zit gewoon gebruikersonvriendelijk in elkaar en de gemiddelde applicatie ziet er hedendaags nog steeds uit alsof het in een win3.1 omgeving thuis hoort.

Tenzij men echt een applicatie nodig heeft die alleen onder java draait kan 99% van de wereld prima zonder Java. Het heeft weinig tot geen toegevoegde waarde en lijkt alleen voor java-programmeurs iets Geweldigs te zijn. Ik babbel wel eens met een tweetal Java programmeurs en het lijkt wel bijna een religie te zijn,.. waarbij het er niet om gaat wat de mensheid wil,.. maar om wat ze de mensheid op kunnen dringen.

[Herko_ter_Horst]

99% van jouw wereld kan misschien zonder Java, 99% van de mijne kan dat beslist niet.

In Enterprise omgevingen die niet vastgebakken zitten aan Microsoft is er geen serieus alternatief, zeker als het (zoals in veel gevallen) gaat om niet-homogene IT infrastructuren, met Linux/Unix/BSD, Novell en Windows servers. Niet geheel toevallig zijn dit ook de omgevingen waar Sun traditioneel z'n geld vandaan haalt.

Dat heeft niks te maken met religie, maar met slim zaken doen: als ik in plaats van X keer voor diverse systemen/OS'en, één keer iets kan ontwikkelen wat op al de systemen van al mijn klanten draait, heeft dat zowel voor mij als ontwikkelaar, als voor de klant grote voordelen (in termen van beheer, kennis-opbouw, e.d.).

Het probleem met Java op de desktop is tweeledig:
A. Sun heeft er nooit écht effort in gestoken, omdat ze toepassing op servers belangrijker vonden.
B. (mede gevolg van A) de programmeer-interfaces die Java voor de desktop biedt zijn te weinig intuitief, waardoor het voor de meesten te ingewikkeld is om een goed performende UI te bouwen. Het kán wel, maar het is te ingewikkeld. Dit heeft dus niks te maken met de performance van Java in het algemeen.

Dit heeft ertoe geleid dat de snelheid van Java in het algemeen steeds wordt afgemeten aan de snelheid van de vele "slecht" geschreven user interfaces.

Als Sun serieus met de desktop aan de gang wil, zullen ze een alternatief moeten bieden voor AWT/Swing. Misschien wordt JavaFX dat alternatief.

[Verwijderd]

Om te beginnen: Je puntjes A en B onderschrijven precies waar ik op doel. Ik had het dan ook voornamelijk over het perspectief van de eindgebruiker op de desktop. Vandaar ook de quote die ik aanhaalde.

Server-side is een ander verhaal, daar heeft de eindgebruiker niet per direct mee te maken. En de eindgebruiker is de groep die ik in het oog houd. Dat zijn de klanten van mijn klanten. Die zal het een worst zijn wat er op de server draait, als het maar draait. Het zal ze een even grote worst zijn op welk OS de server draait, als het maar draait. Het kan ze waarschijnlijk niet eens intereseren wat een server is. Als ik zit te devven dan kijk ik naar wie er uiteindelijk gebruik van moet maken,.. niet naar of het voor mij makkelijk is om te ontwikkelen,.. dan schiet ik het doel volkomen voorbij.

Maar goed, je gaf het al aan. De eindgebruiker is nooit echt onder de loep genomen door Sun. Dat is voor mij net zoiets als een auto fabrikant die kijkt naar wat zijn dealers willen in plaats van de persoon die het voertuig moet besturen. En dat noem ik niet echt slim zaken doen. En daar zijn ze nu dan waarschijnlijk ook achter gekomen,... al lijken ze nog steeds niet te snappen waarom hun applets het zo slecht deden.

[Verwijderd]

Ben het volstrekt eens met Pittoors boven mij.

Pittoors legt de nadruk op de eind gebruiker, die heeft niets aan Java en heeft er eerder last van dan dat deze er profijt van heeft. Ik noem LimeWire en Azureus. Afgrijselijke stukken software onder Windows.

Ik ga even specifiek in op Herko's opmerking over de grote voordelen van platformonafhankelijkheid van Java in server omgevingen.

Ten eerste geloof ik niet in platformonafhankelijkheid, evenmin in een multiculturele samenleving. Platformonafhankelijkheid zal best bestaan, maar het is de grootste onzin die er bestaat in de software industrie. Een enorme desillusie die uiteindelijk alleen ten voordele is van de programmeur. Dit voordeel is enkel pure luiheid en tijdwinst. Goede, kwalitatieve, veilige, stabiele en snelle software is per definitie ontworpen en gecompileerd voor een specifiek platform (of processor architectuur voor de fijnproevers).

Mijn tweede punt is dat júist server software kwalitatief, veilig, stabiel en snel moet zijn. Hierbij sluit je per definitie al platformonafhankelijke omgevingen uit zoals Java. Je moet simpelweg niet willen dat dezelfde code op allerlei platformen draait.

[Barend]

Ik ben het met je eens dat Gosling best wat harder had mogen zoeken naar de oorzaken van het falen van applets. Je hebt ook wel gelijk als je zegt dat Java op de desktop tamelijk opdringerig is (helaas met software eerder regel dan uitzondering...). Je stelling dat de wereld prima zonder Java kan is echter een heel ander verhaal.

Sun, Oracle, IBM, SAP, BEA en nog een aantal andere leveranciers gebruiken gezamenlijk Java als de programmeertaal voor hun platform *. Dit doen ze om tegenwicht te kunnen bieden aan Microsoft. Microsoft is zo'n onwijs grote speler, dat als al die andere partijen zich niet verenigen op een gezamelijke programmeertaal, er eenvoudigweg te weinig expertise in de markt is om projecten op hun software te bemensen. Ze zouden dan snel al hun marktaandeel verliezen aan de enige partij waarvoor je als softwarebehoeftige wél voldoende ontwikkelaars kan vinden. Je hebt daarom ongelijk als je zegt dat de wereld zonder Java kan.

Natuurlijk kunnen de Sun's, Oracle's, IBM's, SAP's en BEA's van deze wereld gezamenlijk een andere programmeertaal kiezen om datzelfde te bereiken. Je hebt daarom gelijk als je zegt dat de wereld zonder Java kan.

In dit stadium is dat niet meer practisch. Java gaat ooit dood-als-COBOL, maar zal niet snel verdwijnen. Wen er maar aan...


*) ja, ik weet van het bestaan van COBOL en ABAP en PL/SQL.

[Verwijderd]

Zoals ik al eerder had gezegd doelde ik met mijn uitspraken voornamelijk op Jan L. achter de desktop. En trust me,.. die kan echt zonder Java, en zijn PC ook.

Lees mijn reaktie op Herko_ter_Horst hierboven maar even, anders val ik in herhaling.

Verder ben ik me ervan bewust dat wat je zegt (jawel, alles wat je zegt) volledig waar is, en ik ben het dan ook 100% met je eens. Maar ergens aan wennen dat me door de strot geduwd wordt zal ik nooit,.. en al zeker niet als het eindproduct (desktop) er uitziet alsof het in een grot is opgegraven.

[J.J.J. Bokma]

"Groot, log en opdringering; ik wil bijvoorbeeld helemaal niet dat Java system resources opvreet"

Dan moet je simpelweg beter programmeren. Groot, log en opdringering (wasdat?) ligt heel vaak aan de programmeur. Maar goed, die gaat niet zeggen dat ie clueless is, dus schuift die het gewoon op Java.

Ik kijk er, als programmeur, al lang niet meer van op dat het grootste deel van de mensen die zichzelf programmeur noemen nauwelijks kunnen programmeren. Of te wel: ze rijden net zo "goed" auto als mensen met een flinke slok op.

[crashmatrix]

"De schuld van de programmeur", kan ik niet ontkennen, maar zeker ook niet "de schuld van de taal die het toestaat". Learning curve voor Java is (relatief gezien) redelijk laag, ik pikte de beginselen op in een week of twee, code jatten hier, code jatten daar en je hebt iets dat werkt. Maar of het goed werkt boeit op dat moment niet, het werkt, einde verhaal.

Dat gemak is aan de ene kant erg gewild, ik zou echt niet al mijn tijd willen verknoeien aan het rechtzetten van pointer rotzooi in C, maar met die achtergrond komt wel een zekere secuurheid (imho) naar voren in het programmeer werkje, dat zie ik ook om mij heen.

En "Groot, log en opdringering" valt niet zo maar op te lossen door beter te programmeren, Java is van nature steviger gebouwd, en volgens velen te stevig. Einde argument, niemand had gelijk.

[cdwave]

De reden dat het nooit wat is geworden met applets is simpelweg dat die dingen voor geen meter werkten. Op de ene browser zus en op de andere zo. En dan had je nog talloze releases van de Java VM met elk z'n eigen nukken, zoals bijvoorbeeld het niet functioneren van Thread.join() en dat soort banaliteiten. Gevolg was dat je applet alleen maar werkte op precies die versies van die browsers met precies die versie van Java. De beloofde portabiliteit was ver te zoeken, zo moest ik java files met de Microsoft (of eender welke andere) compiler tot class files compileren, want als ik dat met de SUN compiler deed dan werkten ze niet op de SUN machine die ze zelf compileerde.

Snel genoeg kwamen WEB applicatie ontwikkelaars tot de conclusie dat het geen zin had om delen aan de client applicatie toe te vertrouwen, je moest alles in de server nog een keer over doen om hackers buiten te kunnen houden.

Gevolg was dat WEB applicatie ontwikkelaars zich op de server kant gingen concentreren, en daar tref je dus nog steeds veel Java aan - maar nog veel meer andere talen.

[Little Penguin]

Als Java een volwaardig alternatief moet worden voor andere omgevingen (Delphi, MS VisualC ed) dan zou men er ook voor moeten zorgen dat de JRE zelf zo klein mogelijk is - nu is heden ten dage 13MiB (download size van de JRE) niet superveel meer, maar om nu een VM van 13MiB te integreren in een applicatie van, laten we zeggen 4MiB is een beetje onzinnig.

Misschien dat Sun eens zou moeten kijken in hoeverre men kan werken aan een afgeslankte versie van de JRE, nu weet ik niet in hoeverre dat ook echt mogelijk is...

[sCHuTt]

Ja, maar die 13MB is eenmalig, en door tig 4MB toepassingkjes te gebruiken...

[Verwijderd]

... wat in de regel niet vaak gebeurt omdat de JRE vaak nodig is voor slechts 1 applicatie. En na het sluiten van die applicatie blijft de JRE draaien op de achtergrond. Als ik iets niet meer gebruik dan wil ik ook niet dat het mijn resources opvreet. En dat geldt ook voor Java.

[Verwijderd]

Wanneer je ontwikkelt voor een wereldwijde markt kan je er niet vanuit gaan dat iedereen net zo fortuinlijk is als catfish en een octa-core-intel-megamultithreated machine heeft die voorzien is van 16 Gig aan geheugen.

Ander feit is dat ik als eindgebruiker wil bepalen wat er draait, en ik als ontwikkelaar mijn eindgebruiker niet wil opzadelen met een onnodige systeembelasting, in welke vorm dan ook.

Als iedereen te werk ging onder het mom van "och,.. wat is nu 14 MB" dan hebben we binnen twee jaar minimaal 50 Gig nodig aan geheugen omdat het blijkbaar toch niet meer uitmaakt wat er draait op de achtergrond en of het wel nodig is. Ik mis de tijd dat programma's (including OS) het onderste uit de kan moesten halen en dat programmeurs niet zo lui konden zijn als ze tegenwoordig af en toe lijken te zijn.


edit:

(Ik stop met reageren op deze uitspraken denk ik lol. Iedere keer wordt als tegen argument gebruikt: "Jaaaahhh,.. maar hij doet het ooook!!!" Oh okay, dan is het wel goed natuurlijk )

[catfish]

14MB is lekker boeiend als je 1 of 2GB ram hebt
het is echt niet zo dat er tig VM's draaien in de achtergrond, hooguit die van Java en die van .net (of waarom denk je dat MSN zoveel ram vreet)

[DLGandalf]

het enige wat er blijft draaien na het sluiten van een java programma is de console, (en volgens mij gebeurt dat alleen bij applets)

lekker belangrijk die 14 mb, dat is inc. alle bibliotheken en die worden echt niet allemaal tegelijk geladen. Of zal ik voortaan bij Win32 programma's de grootte van alle DLL's er ook maar bij rekenen?

vergelijk het is met de .Net updates, die zijn misschien wel minder mb's maar de installatie duurt gewoon schandalig lang

java is echt zo gek niet

[Verwijderd]

Die is er ook. Voor gsm's enzo is er Java ME (micro edition).

[jj71]

Er is al een tijdje een idee bij Sun om een Java Browser Edition uit te brengen - een zo klein mogelijke versie van de JRE speciaal voor mensen die applets in een browser willen draaien.

Die edition is er nog niet, maar dit zou er best eens met de volgende versie van Java kunnen komen (hoewel dat nog wel anderhalf jaar duurt).

[SiliconError]

Zonder duidelijke aanwijsbare reden heeft de applettechniek echter weinig succes gehad, aldus Gosling.

De beste man zit zeker nog in de ontkenningsfase. Of hij heeft nog nooit een applet in een browser zien draaien (lijkt me sterk )

Misschien moet hij de laadtijden eens meten, en dat afzetten tegen de toegevoegde waarde van Java applets ten opzichte van Flash en andere moderne oplossingen.

[Verwijderd]

Een klein beetje geschiedenis kan precies geen kwaad. Applets hadden in eerste instantie als doel statische websites toch een zekere intelligentie en interactiviteit te geven. Het hele www was nog maar net uit de pampers en SUN kon webpaginas al 'intelligent' maken.

Web 2.0, Flash, Ajax, ... bestonden nog helemaal niet! Het enige wat bestond waren statische HTML paginaatjes. Op dit punt was Sun echt wel voor op zijn tijd.

Echter, zo'n appletje was redelijk veel data die moest verstuurt worden over je telefoonlijntje. (14.400 modem ofzoiets). Breedband zoals nu bestond ook nog niet. Dit heeft applets geen goede naam bezorgd.

Door de jaren heen zijn er Flash(ier) (sic) alternatieven gekomen, waardoor Applets naar de achtergrond zijn verdwenen. Ze zagen er fancier uit, waren makkelijker te maken, ....

Met de applets heeft Sun echt wel een pioniersrol gespeeld.

[Verwijderd]

Ik denk dat Java in de toekomst heel veel kan bieden. Je ziet dat security steeds belangrijker wordt en native applicaties hebben vaak door bugs direct toegang bieden tot het systeem.

Een java applicatie draait binnen een JVM en heeft maar zeer beperkt toegang tot het systeem terwijl computers steeds sneller worden en java applicaties steeds soepelere gaan lopen.

[Verwijderd]

Zodra Java meer gebruikt zal worden voor de desktop dan zullen er ook meer bugs gevonden worden, en bugs in de enviroment kunnen leiden tot toegang tot het hostende systeem of deze kunnen het systeem nadelig beinvloeden.

Ga er in ieder geval niet vanuit dat Java voor de desktop per definitie veilig is. Uiteindelijk speelt ook de programmeur een doorslaggevende rol.

linkje 1
linkje 2

[Verwijderd]

Begin deze week heeft Sun bekendgemaakt dat het open source maken van Java is afgerond. Gosling was en is daar echter geen voorstander van: hij is bang dat er incompatible Java-varianten zullen verschijnen. Hij merkt echter op dat de kans dat dit gebeurt erg klein is, omdat iedere Java-ontwikkelaar ervan uitgaat dat zijn applicaties op elke Java-implementatie werkt.

Toen MS met hun Java kwam met extensies (wat dus inhoudt dat het in principe *wel* compatible was met 'gewoon' Java, je kon alleen meer, en dat was natuurlijk weer niet terug compatible) zeiden ze iets compleet anders.
Maar het verleden heeft dus al bewezen dat dit argument niet klopt. De schuld daarvan ligt bij de Java-ontwikkelaars, dat hebben ze dan weer wel goed gezien.

[Robert-Jan]

Gosling ziet misschien niet de reden waarom applets mislukt zijn, maar andere ontwikkelaars bij Sun gelukkig wel.

Voordat Java op de desktop een succes kan worden moet de opstarttijd minimaal gelijk zijn aan die van Flash en moet de installatie minimaal even makkelijk zijn als die van Flash.

Gelukkig heeft Sun dit inmiddels ook door en wordt er hard gewerkt aan deze punten:

http://blogs.sun.com/roum...portant_promise_from_this

The most exciting thing for me coming from this Java One is the promise that Sun is going to fix the web browser applet plug-in and various issues with deployment of Java applications on the desktop. Sun will work on a special version of the JRE called "Consumer JRE" which will be smaller and the plan is to make it available in the beginning of next year. The applications will start very quickly from cold start, which is currently a problem with desktop Java applications - they start slow for the first time (successive startup times are not an issue).

The install experience will also be revamped to make it easier for consumers to install and update the JRE. This will include some JavaScript magic for version detection, etc. The JRE will be also modularized so that the basic JRE has minimal size and missing modules will be downloaded as needed. These changes will also have a positive effect on future Java FX-based applications.

[therebol]

Het wordt tijd dat meer mensen Rebol eens gaan ontdekken! In vergelijking daarmee is Java bloatware. In 646Kb (je leest het goed) is een complete programmeeromgeving inclusief de eenvoudigste GUI builder ooit verpakt, samen met de bijbehorende virtuele machine die draait op meer dan 40 verschillende hard- / softwareplatforms (ook embedded systemen). Op http://www.rebol.com/what-rebol.html kun je hierover meer te weten komen. Rebol/View is gratis te downloaden. Rebol wordt binnenkort voor een groot deel Open Source. Op dit moment wordt aan een nieuwe versie gewerkt die nog veel meer zal bieden dan de huidige versie.
The Rebol