Mais il n’invoque pas le hotswap, mais plutôt un pb connexe/sous-jacent qui est celui de la création de (très) nombreuses classes, et de *certaines* modifications dynamiques, création-modification propre aux langages dynamiques. Pour ce faire, il propose un ‘anonymous class loader’. Je n’ai pas regardé plus loin.

Quant à la sortie de la umbrella JSR Java 7, je n’ai pas d’idée. En fait, cela va sans doute dépendre de ce qu’ils veulent inclure dedans, par ex, avec ou sans closures ? Tous les composants n’ont pas le même degré d’avancement :
http://tech.puredanger.com/2008/08/02/java7-prediction-update/

Par ailleurs, j’ai trouvé un autre bon résumé du contenu du JDK 7 : http://tech.puredanger.com/java7

Sauf erreur de ma part, personne n’a plus parlé de ces améliorations du Hotswap depuis 2006, date de création de la JSR-292. L’early draft de celle-ci, disponible depuis mars dernier, n’en fait d’ailleurs aucune allusion.

J’en ai profité pour refaire le tour des articles sur le sujet. Danny Coward lui-même (ancien spec lead de la JSR-292, maintenant responsable de la umbrella JSR pour Java 7) avouait ne pas trop savoir comment s’y prendre pour permettre ce genre service. Je suis également tombé sur un article de Gilad Bracha commenté par l’un des contributeurs principaux RIFE enthousiasmé par le rechargement de classes à chaud, fonctionnalité qui différencie justement son framework. Quant à Gilad, également ancien spec lead de la JSR-292, il a préféré s’enfuir dans le monde de la modularité JAM/OSGi avec leur fine grained class loader plutôt que de pousser les évolutions du hotswap. Toute plaisanterie mise à part, à mon avis, ce n’est pas encore demain que la JVM concurrencera ce que nous propose JavaRebel.

Avez-vous des informations contradictoires ?

Question bonus : avez-vous un pronostique pour la sortie de la umbrella JSR Java 7 ? Personnellement, j’avais tout misé sur ‘mai dernier’ …

On entend plus souvent parler d’une des 2 parties de cette JSR : la fameuse instruction « invokedynamic » ; mais cette JSR a d’autres buts :

«  »
* to add a new JVM instruction, invokedynamic, designed to support the implementation of dynamically typed object oriented languages [...]
* also investigate support for hotswapping, the capability to modify the structure of classes at run time.
«  »

J’espère que cette JSR fera bien parti de JDK 7…

Seam propose un redeploiement leger pratique lorsque l’on travaille uniquement sur la partie vue (xhtml,css) et qu’aucuns beans Seam n’est ajoute.
Mais ce n’est pas aussi pousse que ce que tu as presente.

Sinon comme tu l’expliques, on oublie souvent que l’on peut se connecter a un Weblogic en mode debug et recharger une partie de l’application… Combien de developpeur perdent leur temps a tout recompiler ?

Pour ce qui est des limitations, c’est tout à fait exact, c’est ce que je voulais dire par « [l]es classes qui correspondent aux pages et composants ». Concrètement, T5 gère ses propres classloader afin de pouvoir enrichir le bytecode des classes qui correspondent aux composants/services/mixin (au sens T5), ce qui correspond à aux packages sous « myapp » dans l’organisation de projet conventionnelle visible ici: http://tapestry.apache.org/tapestry5/guide/project-layout.html.

En gros, dès qu’on touche à des classes de données ou des services externes (Spring…), le live reloading ne fonctionne plus, mais comme ce sont des classes dont les API sont souvent plus stables que les classes d’UI, c’est acceptable – et c’est de toute manière mieux que de toujours devoir recharger l’application.

(T5 recharge aussi toutes les ressources de type asset (fichier properties pour les traductions, templates, images, etc), mais ceci est beaucoup plus courant).

Pour les problèmes plus particulier dont vous parlez, je ne les ai jamais rencontré, mais ca ne veut bien sûr en aucun cas dire qu’ils n’existent pas Comme pour JavaRebel, le live-reload de T5 est une fonctionnalité qui a pour but principal d’accélérer le développement, rôle qu’elle remplie très bien. En cas de clastCastException, il suffit de revenir à l’ancienne méthode, et de relancer l’application.

Par contre, se sont des symptômes qui sont fréquents lorsque plusieurs versions de T5 sont présentes dans le même war (ce qui ne devrait pas arriver, mais Maven est parfois capricieux, ou les cleans pas toujours bien faits). Dans ce cas, les différentes versions se battent pour mettre à jours les classes, et ça peut donner des résultats intéressants

Bref, JavaRebel est la bonne solution à terme, parce qu’elle traite le problème là où il doit l’être : au niveau de la JVM (et je trouve comme vous aberrant que Sun n’ait pas proposé cette fonctionnalité depuis des lustres à ce niveau là). Mais JavaRebel à aussi ses contraintes (de licence notamment) qui font que tout le monde ne peut pas se permettre de l’utiliser, et dans ce cadre, la solution proposé dans T5 est mieux que rien, et est tout particulièrement adapté au contexte de la création d’UI, très itérative, mais forcément dans le contexte de l’application complètes (et donc avec des validations par tests unitaires plus difficiles, donc beaucoup de petites erreurs qui prennent moins de temps à être corrigé que le temps de charger l’application).

D’autres part, dis moi si je me trompe, mais j’ai cru comprendre que le mécanisme de rechargement de tapestry 5 présentait tout de même quelques lacunes :
- seuls les composants managés par tapestry sont rechargeables (c’est déjà pas mal)
- le rechargement de code référençant du code non managé peut provoquer certains problèmes (fuite mémoire, ClassCastException, IllegalAccessException …)

Vous confirmez ?

En fait, avec Tapestry 5 (http://tapestry.apache.org/tapestry5/), j’ai pris de mauvaises habitudes, et je ne me rend plus compte à quel point le cycle de développement « modification/compile/package/redéploiement/test » est long et inefficace, en particulier pour la partie UI d’une application, et encore plus dans le ca d’une application Web (vous savez, ces étapes très courante au cours d’un run… « ha, j’aimerais bien un bouton en plus pour ça… Oh, et un peu de Ajax serait plus dans l’air du temps… Ah zut, j’ai pas bien fait mon handler… Et si je rajoutais des tris sur ce tableau… Mince, mon comparateur est à l’envers… »).

Donc, Tapestry 5 prend en charge le rechargement à chaud des classes qui correspondent aux pages et composants, ce qui permet de lancer son application web dans eclipse, de modifier ses pages (templates et Java) et de simplement recharger la page dans le navigateur pour voir apparaître ses modifications.
Le développement itératif prend un vrai sens (les Groovy-er me comprendront ici – tiens d’ailleurs, on peut faire du Groovy à la place de Java pour le backend des pages dans T5 – ou du Scala, si on préfère).

Vous pouvez voir un exemple sur le dernier screencast de Howard (qui traite de AJAX, mais dans lequel on voit la fonctionnalité en question) :
http://tapestryjava.blogspot.com/2008/11/tapestry-5-ajax-screencast.html

Y’a plus qu’à tester JavaRebel. Avec Scala, parce que c’est plus marrant que Java

Toutefois, la face caché de l’iceberg est qu’il arrive parfois que JavaRebel cause des bugs bizarres et très difficiles à dépister mais surtout silencieux dans des applications un peu complexes.
donc, en face d’un truc qui cloche, relancer le test sans JavaRebel peut être le geste qui sauve

Jawher