C'est le plus connu qui a évolué, mais il y a aussi le framework de parallélisation (qui va encore évolué avec Java8).
C'est exactement ce que je dis. On bouche en s'en battant de rendre les trucs performants ou utilisables.
Le fork/join de la JSR166y est très bien. Une nouveauté. Cool ! (enfin c'est dispo comme lib externe depuis 5 ans)
En attendant tu peux toujours pas instancier un foutu Future sans utiliser l'AbstractFuture de Guava (FutureTask ne marche qu'avec un Runnable). L'API des Executor est tellement mal gaulé que 90% des gens qui essayent de créer un thread pool avec un nombre min et max de thread se plantent (la compatibilité Java 5/6/7 en exercice). Faire un thread group nommé demande encore de dupliquer 30 lignes de code ou d'utiliser une lib externe. On peut continuer comme ca longtemps sur ce tout petit module fonctionnel mais le constat est généralisé sur presque tout le JDK.
On rajoute des briques très bien. Mais les bases qui servent à construire ces briques sont en train de pourrir. Pour avec un semblant de DRY t'es obligé d'utilisé 1000 libs. Mais laisser ca a des third party c'est prendre le risque de retomber sur le délire du logging ou d'avoir une compatibilité beaucoup plus difficile à gérer que si le JDK cassait quelque chose ou se bougeait simplement le cul. Rare sont les projets reposant sur un OSGI ou assimilé et t'es bien malin quand ton runtime arrive déjà avec ses 30 libs dans une version donnée… Même en OSGI t'as intêret à être à grin très fin pour jamais tomber sur ce genre de problème.
Je suis d'accord pour dire que le JCP a du mal à sortir des choses mais c'est parce qu'il est difficile de sortir un consensus pas un manque de volonté (du moins je pense pas).
Non par ce que le bateau s'est enlisé depuis longtemps et que le remettre à flot est difficile. Si on pousse pas ca avance pas.
il y a une volonté de découper l'API pour la rendre plus modulaire (voir le JSR 337).
La JSR 337 c'est juste la JSR de Java8 qui listent les JSR qui seront incluses. Le DRAFT-1 n'indique pour le moment absolument rien à propos de Jigsaw. Toute les chances pour que ce soit encore repoussé à Java 9.
Note que Jigsaw au niveau du JDK ne rend absolument pas l'API plus modulaire. Ils veulent juste pouvoir charger les différents sous modules du JDK par bout fonctionnel (réduire le coût du download + boot). Ca demande un énorme boulot de nettoyage puisqu'il faut péter toutes les dépendances qui traînent. Mais d'un point de vue utilisateur ca n'a absolument aucun impact.
Ça ne ressort pas mais c'est un avis personnel.
Il me semble personnellement très foireux.
Je n'ai absolument jamais entendu ce genre d'idée. Autrement on inventerait pas des trucs comme tweaker la résolution de méthode virtuel pour ajouter les implémentation par défaut dans les interfaces pour le support des lambdas. On s'amuserait pas prévoir des gesticulations immondes pour réparer les conneries qui ont été fait avec l'autoboxing et son interaction avec les collections. Et on peut continuer.
[^] # Re: Usine
Posté par ckyl . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 3.
C'est exactement ce que je dis. On bouche en s'en battant de rendre les trucs performants ou utilisables.
Le fork/join de la JSR166y est très bien. Une nouveauté. Cool ! (enfin c'est dispo comme lib externe depuis 5 ans)
En attendant tu peux toujours pas instancier un foutu Future sans utiliser l'
AbstractFuturede Guava (FutureTaskne marche qu'avec unRunnable). L'API des Executor est tellement mal gaulé que 90% des gens qui essayent de créer un thread pool avec un nombre min et max de thread se plantent (la compatibilité Java 5/6/7 en exercice). Faire un thread group nommé demande encore de dupliquer 30 lignes de code ou d'utiliser une lib externe. On peut continuer comme ca longtemps sur ce tout petit module fonctionnel mais le constat est généralisé sur presque tout le JDK.On rajoute des briques très bien. Mais les bases qui servent à construire ces briques sont en train de pourrir. Pour avec un semblant de DRY t'es obligé d'utilisé 1000 libs. Mais laisser ca a des third party c'est prendre le risque de retomber sur le délire du logging ou d'avoir une compatibilité beaucoup plus difficile à gérer que si le JDK cassait quelque chose ou se bougeait simplement le cul. Rare sont les projets reposant sur un OSGI ou assimilé et t'es bien malin quand ton runtime arrive déjà avec ses 30 libs dans une version donnée… Même en OSGI t'as intêret à être à grin très fin pour jamais tomber sur ce genre de problème.
Non par ce que le bateau s'est enlisé depuis longtemps et que le remettre à flot est difficile. Si on pousse pas ca avance pas.
La JSR 337 c'est juste la JSR de Java8 qui listent les JSR qui seront incluses. Le DRAFT-1 n'indique pour le moment absolument rien à propos de Jigsaw. Toute les chances pour que ce soit encore repoussé à Java 9.
Note que Jigsaw au niveau du JDK ne rend absolument pas l'API plus modulaire. Ils veulent juste pouvoir charger les différents sous modules du JDK par bout fonctionnel (réduire le coût du download + boot). Ca demande un énorme boulot de nettoyage puisqu'il faut péter toutes les dépendances qui traînent. Mais d'un point de vue utilisateur ca n'a absolument aucun impact.
Il me semble personnellement très foireux.
Je n'ai absolument jamais entendu ce genre d'idée. Autrement on inventerait pas des trucs comme tweaker la résolution de méthode virtuel pour ajouter les implémentation par défaut dans les interfaces pour le support des lambdas. On s'amuserait pas prévoir des gesticulations immondes pour réparer les conneries qui ont été fait avec l'autoboxing et son interaction avec les collections. Et on peut continuer.