Java, Helaas is dit vaak nodig op de werkplek. Maar waarom. Het is traag en bagger en zit vol veiligheids- lekken.

Java uitzetten in de browser. Geen enkele fatsoenlijke webapp van de afgelopen vijf jaar heeft Java nodig.

Java is nog steeds populair omdat het letterlijk op elk platform wel draait. Dat het traag en bagger is, ben ik direct met je eens, maar er vanaf komen wordt nog lastig ben ik bang..

Deze exploit werkt alleen op de nieuwe Java 1.7 en is textbook-case simpel. Hopen dat het niet al te veel ellende oplevert ...

Is het niet mogelijk internet en backend toegang te scheideN/

Traag? Dat was versie 1.1.7 misschien, maar inmiddels is dat wel over. En bagger? Hoezo dan?

Helaas... We werken met analytische software, waar helaas geen alternatief voor is, die zelfs een oude Java versie vereist. Elk jaar komt er wel een nieuwe versie uit, maar het loopt altijd achter.

Exploit java_jre17_exec voor Metasploit werkt perfect.

Die specifieke Java-versie dependencies van veel - slechte - software is ook echt de achilleshiel. Het zou veel veiliger zijn Java standaard niet op werkplekken te installeren en gewoon gevirtualiseerd de betreffende versie met de betreffende app streamen. Geen versie-conflicten en geen security issues met browsen (AV oplossing of niet).

F-secure online scanner wel ;_)

F*ck. Geen Minecraft meer voorlopig...

Daar gaat mijn spelletje klaverjassen op Spelpunt maar ik heb er gelukkig geen last van met Open JDK Java met Icedtea plugin

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.


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.