Door Anoniem: Java uitzetten in de browser. Geen enkele fatsoenlijke webapp van de afgelopen vijf jaar heeft Java nodig.
http://prints.profotonet.nl/ is kwalitatief de beste online fotoafdrukservice die ik ken. Ik neem aan dat die webapp (of zijn oorspronkelijke versie) ouder dan 5 jaar is, en ik neem ook aan dat met Ajax of zo een vergelijkbare upload-interface tegenwoordig zonder Java of Flash of Silverlight te bouwen is. Dat wil niet zeggen dat dit geen legitieme en fatsoenlijke toepassing is, en vanwege de kwaliteit van hun afdrukken heb ik een uitstekende reden om Java te blijven gebruiken.
Door Rolfieo: Java, Helaas is dit vaak nodig op de werkplek. Maar waarom. Het is traag en bagger en zit vol veiligheids- lekken.
Het grootste probleem qua veiligheid lijkt mij hoe de door vrijwel iedereen gebruikte implementatie tegenwoordig beheerd wordt. Dat het de vraag is of Oracle snel met een patch komt is diep triest, het zou vanzelfsprekend moeten zijn dat dat een topprioriteit heeft.
Qua traag & bagger is het beeld op
http://en.wikipedia.org/wiki/Java_performance#Program_speed genuanceerder. Lange laadtijd en hoog geheugengebruik van de runtime zijn dingen waar je last van kan hebben. Maar kennelijk zijn er toepassingen waar Java C of C++ inhaalt. Ik heb zelf ooit met de Netbeans-IDE gewerkt, op hardware die uitermate bescheiden is vergeleken met tegenwoordige werkstations. Netbeans is geschreven in Java en het enige wat ik merkte was dat een menu de eerste keer dat het uitklapte een korte vertraging gaf, en daarna was er geen verschil meer met een native applicatie te merken. Ik heb later met Visual Studio gewerkt en dat was in mijn perceptie slomer, op snellere machines wel te verstaan.
De allereerste versies van Java, voor er een Just-in-time-compiler (JIT) geïntroduceerd was, waren geïnterpreteerd en langzaam. De JIT's zijn zelf al lang geleden door hotspot-compilers vervangen, een systeem dat tijdens uitvoering een profiler mee laat draaien en op basis van runtime-metingen veel geraakte code opspoort en agressiever optimaliseert dan een traditionele ahead-of-time-compiler zou doen. De clientvariant van de hotspot-compiler komt vrijwel direct op snelheid, de servervariant komt trager op gang maar optimaliseert agressiever en voert code uiteindelijk sneller uit. Omdat de optimalistaties tijdens uitvoering van de applicatie gedaan worden wordt automatisch met het daadwerkelijke gebruik en de karakteristieken van de gebruikte hardware rekening gehouden, wat het resultaat potentieel sneller maakt dan een ahead-of-time-compiler kan halen. Dat kan de verklaring zijn voor de constatering dat sommige toepassingen in Java sneller uitpakken dan in C of C++. Het kan wellicht ook verklaren dat de indruk dat Java traag is zo hardnekkig is: op runtime optimaliseren kost overhead, en hoewel het per saldo winst oplevert kunnen er momenten zijn dat je het voelt, met name direct na het opstarten van de applicatie. Die indruk kan belangrijker zijn voor interactieve applicaties dan de gemiddelde performance van een applicatie die langdurig actief blijft. Hoe dan ook, ik vind de gekozen benadering een indrukwekkend technologisch staaltje, en dat mag ook wel eens gezegd worden.
Niet dat ik kapot ben van Java als programmeertaal. De makers hebben van begin af aan keuzes gemaakt die beperkend zijn, zoals het niet toestaan van operator overloading. De taal is breedsprakig en omslachtig om in te programmeren, iets wat ik overigens ook van C# vind. De compacte directheid van Python vind ik vergeleken met die talen echt een verademing.