Quand je lis ce document de Google sur les problèmes de sécurité avec les applications Web, je me dis que les Applets ont été écartées pour de mauvaises raisons.
Certes je ne suis pas un spécialiste en sécurité mais Google lui-même indique que l'utilisation massive d'AJAX a créé des failles de sécurité qui n'existaient pas avant avec des sites plus classiques. Et Google est un des plus actifs promoteurs des applications AJAX.
Par ailleurs ce qu'ils appellent Same-Origin Policy a été copié de ce qui avait été introduit par les Applets (en quelle année ? 1998 ?). De même le problème d'injection de code par des entrées utilisateurs n'est pas possible en Applets puisque l'application n'est pas faite en HTML/JS/JSON. C'est du Java. On peut difficilement imaginer saisir dans un formulaire du code Java en espérant qu'à l'affichage il va s'exécuter.
Je ne dis pas qu'il n'y a pas de failles dans les Applets mais je pense que ce ne sont pas des failles introduites par un mauvais codage alors qu'en HTML/AJAX/JS c'est le cœur du problème.
En fait on peut considérer que la plupart des sites ont des failles dues à une méconnaissance des problèmes de sécurité.
Bref tout cela me fait dire qu'avec HTML/AJAX/JS on a fait un bon en arrière incroyable en promouvant des technologies qui n'étaient pas adaptées pour faire des applications solides. D'ailleurs le nombre de frameworks qui existent dans ce domaine indique que ces technologies en sont au stade du prototype et que chacun cherche désespérément à combler les lacunes d'un système de développement bancal.
En fait - parenthèse - tout ce temps perdu me donne à penser que la concurrence exacerbée est vraiment un mauvais système. Au contraire une coopération entre les différents acteurs aurait abouti beaucoup plus rapidement (en théorie) à produire les fonctions manquantes sur les systèmes existant, en l’occurrence Java puisque c'est le sujet. L'idéologie des USA nous a entrainé dans des errements dont on n'est pas encore sorti.
Parallèlement Java est depuis longtemps une technologie aboutie et il aurait juste fallu corriger les quelques choses qui n'allaient pas (UI/Swing, le problème du déploiement par exemple) mais des guerres de pouvoir ont sabordé cela.
Quand je vois JavaFX 2, je me dis que si il était sorti en 2000 les choses auraient pu être différentes.
Alors on va me dire qu'avec Java il faut installer une JVM, c'est chiant. C'est vrai mais comment croyez-vous que JavaScript s'exécute ? Avec une VM embarquée comme l'était la JVM dans les premiers navigateurs.
De plus je pense que Java pourrait évoluer pour être modulaire et n'installer dans le navigateur que le strict nécessaire au fur et à mesure des besoins. De même, ne pourrait-on pas imaginer de livrer une application Java entièrement autonome (en fait c'est déjà possible en utilisant des outils payants) ?
Le problème principal étant que les acteurs qui font les navigateurs sont engagés dans une mise à l'écart de Java dans le Web et dans les systèmes car ils veulent tous que le développeur utilise leur framework de développement à l'exclusion de tout autre (Google, Apple, Microsoft). Java étant multi-plateforme il doit être tué.
De la part de Google c'est quand même un peu bizarre étant donné qu'il a volé choisi Java pour en faire le système de développement sur Android. D'ailleurs il n'a pas choisi JavaScript mais Java (tout le monde sait que JavaScript est un très mauvais langage...). De fait on peut considérer qu'il y a désormais deux Java différents qui évoluent de manière indépendante. Cela fractionne encore plus les énergies.
C'est une spécialité de l'informatique de refaire 100 fois les mêmes outils. Il suffit pour s'en convaincre de consulter la liste des langages de programmation sur Wikipedia. Il faut imaginer tout le temps et l'argent dépensé pour créer tous ces langages dont peut-être 10% sont couramment utilisés et encore moins dans l'industrie. Et encore ce ne sont que les langages de programmation. Il y a plein d'autres langages pour tout un tas d'usages tous plus ou moins différents parfois de manière très subtile.
Franchement les différences (je considère uniquement le langage) entre C++, Java, Ruby, Groovy, Python, Scala, C#, JavaScript, Go, Dart, Eiffel etc. justifient-elles de créer un nouveau langage et un nouveau environnement de compilation, d'exécution et de débug ? Ne pourrait-on pas juste améliorer l'existant ? C'est par exemple ce que fait Java 8 en intégrant des nouveautés présentes dans d'autres langages. Mais comme le processus est long, les autres langages ont le temps de prendre une place significative.
Ceci dit, c'est plaisant de découvrir un nouveau langage mais le problème se pose de pouvoir le maitriser pour le mettre en œuvre de manière efficace, sachant que si l'on fait cela on se disperse immanquablement et je ne peux m’empêcher de penser que cela nuit à l'efficacité globale. Une autre façon de voir est de s'inspirer de ce que l'on voit dans d'autres langages pour l'appliquer dans son langage courant. C'est parfois possible mais pas toujours du fait de manques rédhibitoires.
D'ailleurs - une parenthèse - cela me fait penser aux films SF dans lesquels les informaticiens arrivent à télécharger des programmes dans des systèmes dont ils ne savent rien. On imagine donc que le futur n'utilisera qu'un seul système, avec un seul type de langage, un seul type de binaire, un seul type de connexion etc. On branche, ça upload et POUF le programme s'exécute ! Magique. Quand on voit le bordel que c'est actuellement j'ai de la peine à l'imaginer.
Il y a quand même un domaine où Java est très populaire, c'est le domaine des applications serveur, et on peut considérer qu'il ne survit que pour cela. C'est dommage car Java est l'évolution de Smalltalk qui était aussi une plateforme entière de développement aboutie aussi bien client que serveur.

MAJ: j'étais à l'instant sur un forum de développement Mac et ça parlait de Swift. C'est vrai que j'avais oublié de le citer dans ma liste non exhaustive de langages. Je ne connais pas bien Swift mais il semble qu'il soit plus statique que Objective-C qui est dynamique par nature. En effet la méthode exécutée n'est découverte qu'à l'exécution et non à la compilation. Visiblement Swift corrige cela. Mais alors on peut se demander pourquoi ne pas avoir choisi Java qui est fortement typé ?

J'ai commencé à traiter les FSEQ mais c'est vraiment compliqué. Voici un avant-goût : J'utilise l'API Chart de javafx mais ce n'est pas certain que ce soit la meilleure solution. J'essaye de contrôler la hauteur de chaque point avec la souris.

Sinon j'ai bien avancé sur l'édition des voices : Je pense qu'il faudrait que j'ajoute un bandeau avec des contrôles de volume ou des "mute" pour tous les opérateurs, que ce soit accessible tout le temps.

J'ai commencé un éditeur pour le Yamaha FS1R. Il est encore un peu limité !

J'ai terminé une première version de l'éditeur Java 8 pour le Matrix-1000. J'ai réussi à caser tous les paramètres sur une page ce qui était une condition sine qua non. En tout cas je le trouve beaucoup plus beau et plus ergonomique que celui de JSynthLib, sans me vanter. Bon c'est vrai j'ai honteusement copié le look des potentiomètres d'Ableton Live, j'avoue, comme ça je ne suis pas dépaysé ;)
Vous pouvez le télécharger ici. En voici un aperçu :

Je viens de m'apercevoir que le JDK 8 contient la classe Optional qui sert à contenir une valeur potentiellement absente.
Habituellement on retourne null pour signifier l'absence de valeur. Néanmoins cela peut provoquer des NPE plus tard dans le code.
Je n'étais pas hyper convaincu de l'intérêt de Optional, mais je pense que c'est quand même mieux de l'utiliser pour plusieurs raisons :

1. le fait que la méthode peut ne pas fournir de valeur est indiqué dans sa signature
2. l'interface est claire : isPresent et get
3. le get lève NoSuchElementException

Le type de retour indique la possibilité de ne pas avoir de valeur alors qu'avec une méthode qui retourne null il faut consulter la javadoc. Ainsi si on prend l'habitude de tester isPresent avant de l'utiliser, pas de problème. Mais même si on appelle get sur un Optional vide on à l'exception. En fait il est préférable d'utiliser la méthode ifPresent comme indiqué sur la page Oracle.
Évidemment cela suppose de ne pas transmettre un Optional en paramètre car là il me semble qu'on retombe dans les inconvénients de transmettre une valeur null. Je pense qu'il faut appeler isPresent et get immédiatement après le retour de méthode, ainsi si il y a un problème il est localisé au plus près de la source.

Voir aussi