J’utilise Diigo, très efficace. Il permet de mettre plusieurs tags sur une page , enregistrer une image et créer des listes. thématiques. J’utilise en plus pearltrees pourle coté visuel et social

Ce qu’on peut faire pour “tricher” un peu, c’est inverser les actions dans l’étape “fork” en remplacant invokeAll(pv1, pv2); par invokeAll(pv2, pv1);
Et là miracle, ca s’exécute en 14 sec ! (normal, le mot de passe commence par “I” et se trouve donc dans la deuxième branche de l’arbre)

Tu ne peux pas dire des choses comme “l’histoire va plutôt dans le sens inverse de Node.js”. node.js est en train de cartonner chez les sites webs a fort traffic, mais c’est comme pour tout, ca ne s’utilise que si ca a du sens. Dans le cas de votre jeu ou dans les applis de gestion developpees par Ippon, je veux bien croire que ce serait un mauvais choix…

Pour le second argument “un seul langage” je suis d’accord avec toi.

Par contre ca ne fonctionne pas très bien, le “shutdownNow()” n’arrête pas les traitements du coup le traitement va jusqu’au bout … Si qqu’un a une idée car je maîtrise pas trop fork/join encore

Traces d’exécution sur ma machine 4 coeurs (HP ProBook / Windows 7 64 bits) : 
Available processors : 4
Number of passwords : 362880
Solution : IDAEBHJGC
Execution time : 18521 ms

(Par contre j’ai pas réussi à faire fonctionner la méthode “shutdownNow()” du “ForkJoinPool” (java.util.concurrent.CancellationException), du coup j’ai utilisé un bon vieux booléen … si qqu’un a une meilleure solution, je suis preneur)

Ca donne quoi sur le MacBook Pro 8 coeurs niveau perfs ? Histoire de comparer …

Côté licence, cette ouverture du code est effectivement une très bonne chose. Dommage… actuellement, il semble qu’il y ait peu de contributeurs hors Redhat sur les modules:( mais bon, les projets sont a suivre. Je vais me monter un POC chez moi pour secouer le cocotier…

Curiosité des Licences: Seam Persistence en Apache qui s’appuie sur SeamTransaction en GPL v2… très logique ! Sans parler des fichiers sans licence dans les 2 projets…

Dans tous les cas, merci pour cet article Antoine! Cela, me donne envie d’approfondir le sujet même s’il ne semble pas encore y avoir de solution industrielle hors JTA…

1) ce qui est primordial ici, c’est qu’une majorité de langages dérivés de Java adoptent un ensemble de pot commun de fonctionnalités. Je crois qu’il est temps d’introduire ces fonctionnalités dans la prochaine version de Java, plutôt que ces designers de langage continuent à faire des choses quasi-identiques dans leur coin.

2) il se trouve que certaines de ces fonctionnalités sont déjà dans C#.
a) ce n’est pas une bonne idée de se priver de ces fonctionnalités en Java pour la “bonne” raison que C# les propose déjà !
b) puisque je pense que ce sont des bonnes fonctionnalités à adopter au sein de Java, je continue à penser, légitimement, je crois, que les développeurs de C# auraient raison de se moquer de nous si on ne les adopte pas, non pas parce que ce sont des fonctionnalités de C#, mais parce que ce sont des fonctionnalités intéressantes, et IMHO, utiles.

PersistenceContextType.EXTENDED :
———————————————–
Si nous souhaitons ne pas avoir recours au mode ?ush manuel spéci?que d’Hibernate,cela veut dire que nous devons trancher entre les modes standards auto et commit. Écartons d’of?ce le mode auto puisque celui-ci peut exécuter un ?ush avant l’exécution decertaines requêtes.Le choix  @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) pour toutes les méthodes, excepté celle de validation (méthode de flush). Pour rappel, avec NOT_SUPPORTED, si un accès à une ressource transactionnelle est requis, celui-ci s’effectue en dehors d’un contexte transactionnel en exploitant la fonctionnalité d’autocommit. Le autocommit n’est pas intercepté par le conteneur comme un commit traditionnel et donc que le fush ne sera pas déclenché.Seule la méthode de validation surcharge ce comportement : on l’annote avec @TransactionAttribute(TransactionAttributeType.REQUIRED). Cette méthode peut être vide, le simple fait que le conteneur commit le contexte transactionnel en fin de méthode, c’est  suffisant à déclencher le fush.

* Inférence de type,

* Simplification des accesseurs sur les propriétés,

* Les Traits.

Vu qu’il y a aussi d’autres langages du même acabit (Fantom, par ex), je vois un risque que les développeurs se “dispersent” dans ces diverses communautés. Et l’émergence d’un langage “tête de gondole” mainstream qui porterait haut l’étendard de ces innovations serait retardé, mais pas impossible.

Bref, l’idéal serait que le JCP adopte le noyau d’innovations commun pour Java 8. De la sorte, ces langages ne ré-implémenteraient pas chacun dans leur coin ces innovations quasi-communes, ce qui n’empêcherait pas que chacun continue à développer des fonctionnalités innovantes hors ce noyau commun.

Si la fenêtre de Java 8 est loupée, pour avoir un langage “tête de gondole” mainstream avec ces innovations, on risque d’être réduit à attendre (dans de nombreux cas business) la sortie de Java 9 ; autrement dit, une éternité par rapport au fait que C# dispose déjà de la plupart de ces innovations (sic).

Flex et Silverlight ont apporté plusieurs choses essentielles :
1. Une architecture RIA avec un client riche qui appelle des services, et plus le concept de pages et de navigation qui ne convient pas à la plupart des applications d’entreprise
2. Des librairies de composants graphiques complètes et faciles à étendre
3. Un développement industriel avec des outils, des frameworks et autres
4. La possibilité d’être déployé sur tous les navigateurs actuels, IE6 y compris, grâce à un plugin déjà présent un peu partout (sauf Silverlight cela dit)

Pour le 1, c’est parfaitement possible à faire avec du HTML/JS mais ce n’est pas encore la ‘mode’. En tout cas c’est TRES eloigné de ce qui se fait avec JSF, Spring MVC, ou n’importe quelle autre techno à base de templates HTML. Et c’est bien dommage parce que ça permet d’avoir une architecture vraiment propre et de séparer clairement la couche présentation de la couche service (et donc d’éviter d’être à la merci des évolutions de toutes ces technos Web).

Pour le 2, hormis peut-être ExtJS, je ne vois pas trop d’équivalent à Flex/Silverlight pour les composants graphiques riches et la qualité visuelle. Avec GWT, on a l’impression que chaque composant un peu complexe est une victoire technologique incroyable pour une armée de hackers. C’est sympa mais pour faire une vraie application j’ai pas envie de chercher partout des composants plus ou moins bien réalisés.

Pour le 3, ben j’attends encore de voir des choses pour HTML/JS mais il y en a peut-être. GWT est probablement ce qui se rapproche le plus de Flex de ce côté-là.
Pour le 4, rien de plus à dire. Le jour où je verrai un Chrome, un Firefox (sans même parler d’un Chrome Frame sous IE) chez un grand compte, je changerai peut-être d’avis. Mais après avoir lutté pendant des années avec des incompatibilités HTML/CSS/JS entre IE, Firefox, Safari sur Windows, Mac et autres, Flex était réellement une bouffée d’air frais.

Le 5, c’est que Flex c’est fun et ça redonne vraiment plaisir à développer. On peut faire des trucs faciles à utiliser sans se demander à chaque fois si c’est possible en JS ou comment hacker la css pour mettre un encadré bleu. Après il y a des gens qui adorent hacker du jQuery et qui font des choses excellentes mais bon… pas moi.

Pour résumer, avec Flex et GraniteDS, vous avez le 1, le 2, le 3, le 4 et le 5 et en plus comme notre architecture n’implique aucune dépendance ni à Flex ni à GraniteDS vous pourrez switcher joyeusement vers HTML5 quand le besoin s’en fera sentir sans rien toucher au serveur.
A noter également que Flex est une couche au-dessus de Flash et qu’il pourrait finir par être possible de compiler du Flex en HTML5/JS plutôt qu’en Flash/AS3.

Bref, avec le possible déclin de Flex et de Silverlight, Oracle aurait une carte à jouer.
Ce pourrait être comme le retour de HotJava, soit un des tout premiers navigateurs tout en Java : http://www.jroller.com/dmdevito/entry/hotjava_may_come_back_due

En fait, SUN a voulu combattre directement HTML avec Java (les applets Java) et a été écrasé par ce rouleau compresseur (i.e. HTML) : http://www.jroller.com/dmdevito/entry/html_the_juggernaut_of_our
L’approche JavaFX semble être héritière de la leçon de l’échec des applets : Oracle ne cherche plus à affronter directement HTML, mais mixe les forces de HTML et de Java à travers JavaFX (puisque le runtime JavaFX contient notamment WebKit). Ce pourrait être la souche permettant de faire refleurir les applis Java sur le poste client, pour la création du bureau métier.

2eme point très important aussi c’est la fluidité de l’application que l’on a en Flex et SL et pas vraiment en JS (que ce soit via GWT, Eclipse RCP ou un framework JS). Dès qu’on a une appli un peu complexe, les explorateurs montrent leurs limites. 
On est sur des pages web et non plus sur une appli bien structurée en arborescence. Du coup on n’a pas la même réactivité entre les différentes vues (même si des frameworks comme ExtJS4 proposent le mode appli MVC).

Je n’ai aucun doute que Flex et SL vont mourrir, mais ne pas pouvoir profiter pleinement des designs comme l’IOC, le MVC et autres c’est une belle régression. Il va falloir du temps, à mon avis, pour que des frameworks + IDE vraiment complets et rapides n’arrivent au niveau de Flex et SL.
Et puis le HTML5 n’est toujours pas sec…

Il faut voir le bon côté des choses : si seul HTML 5 est viable, les grands comptes n’auront plus d’autre choix que de migrer vers des navigateurs modernes

Pour ceux qui ne connaissent pas ce site : http://www.ie6countdown.com/, il serait bon de le montrer à vos ‘gars de la DSI dinausaure’ pour les informer que même Microsoft attend avec impatience la mort définitive d’IE6 … en espérant qu’ils fassent ensuite les mêmes sites pour ie7 et ie8