JDK 7 : Que pensez-vous des nouveautés et qu'auriez-vous aimé avoir de nouveau ?

[verbose]

D'autant que je sache, il sera possible de faire un switch avec des String. Il aurait été souhaitable que cela soit également possible avec les enums. Cela ne devrait pas poser de difficulté technique puisque les enums sont associé à un ordinal.

[adiGuba]

Envoyé par verbose

Il aurait été souhaitable que cela soit également possible avec les enums.

Heu...
C'est déjà le cas, et ce depuis l'intégration des enum dans Java 5...

a++

[verbose]

mdr, voilà ce que c'est de travailler sur une version 1.4 !!!

[dingoth]

Ce que j'aurais préféré avoir en plus ? La gestion améliorée des exceptions : tant le multiple-catch que le rethrow ; une amélioration substantielle de Swing.

Ce que j'apprécie particulièrement : les nouvelles manières d'introduire un nombre dans le code source. Tant la forme binaire que l'ajout de caractères de soulignement pour espacer le code me satisfont. C'est juste une amélioration syntactique, mais c'est tellement bon quand on est appelé à maintenir une application d' 1.000.000 de lignes de codes codée dans les années 1998-2003.

Quelques changements possibles ? Pour une fois virer la compatibilité ascendante afin de virer toutes les mauvaises manoeuvres que l'on voit tous les jours (utilisation et comput de Date, alors que Calendar existe), virer les méthodes désuettes dont on n'a que faire et qui n'existent plus que dans du code vieux de 10 ans, pouvoir enfin recevoir un java.awt.Graphics qui a les possibilités d'un Graphics2D sans caster, et j'en passe.

En gros, j'aurais aimé un peu d'audace

[Baptiste Wicht]

Envoyé par dingoth

Quelques changements possibles ? Pour une fois virer la compatibilité ascendante afin de virer toutes les mauvaises manoeuvres que l'on voit tous les jours (utilisation et comput de Date, alors que Calendar existe), virer les méthodes désuettes dont on n'a que faire et qui n'existent plus que dans du code vieux de 10 ans, pouvoir enfin recevoir un java.awt.Graphics qui a les possibilités d'un Graphics2D sans caster, et j'en passe.

Je suis du même avis.

Autant la compatibilité ascendante est un avantage de Java, autant c'est un frain pour l'évolution du langage. Personnellement, je ne pense pas que la compatibilité ascendante justifie de garder des choses obsolètes de ne pouvoir effectuer certaines améliorations soit au niveau du compilateur, du langage ou de la librairie standard. Je sacrifierais volontiers la compatibilité ascendante au prix d'améliorations et d'audace dans les nouvelles versions.

[Jack Sparrow]

Envoyé par r1-1024

Très souvent dans le coeur d'une appli à plugin il est indispensable de faire un catch(Throwable).

Enfin, un NullPointerException est quand même une erreur grave, qui vient souvent d'une erreur dans le programme ou un problème de packaging.

Un NullPointerException ne me semble pas particulièrement moins grave qu'un OutOfMemoryException.

Dans un système de plugin (par exemple pour du traitement d'images), il n'est pas improbable qu'il y ait un OutOfMemoryException, donc je ne vois pas particulièrement une raison de laisser passer un NullPointerException et pas un OutOfMemoryException.
-> on catche tout, et s'il n'y a plus de mémoire, le reste de l'application se cartonnera plus tard (voir pas du tout si le plugin avait besoin de 500mo)

[professeur shadoko]

ah oui j'oubliais: un système d'adaptateur pour les annotations.
je vais essayer de m'expliquer: tu annotes ton code avec une annotation à toi puis tu découvres une librairie qui utilise ses propres annotations et qui fait avec des traitements plus interessants que les tiens ... donc tu modifies ton code ... que tu remodifies ensuite avec une librairie d'annotation encore plus sexy, etc.
Autrefois (il y a bien longtemps ) j'avais un Pascal avec un mécanisme de ce genre: tu avais un adaptateur dans lequel tu spécifiais finalement si on cherche X et bien dans mon code c'est Y.
oui on peut aussi friser le macro-processeur ...
(certes ça a forcément des limites car on ne peut pas "traduire" n'importe
quelle annotation en n'importe quelle autre)
c'est idiot?

[Jack Sparrow]

Avoir une implémentation native et rapide de Image#getScaledInstance avec l'option SMOOTH.

Ou bien encore mieux, avoir une nouvelle clef RenderingHints.VALUE_INTERPOLATION_SMOOTH car les autres clefs donnent des résultats certes rapides, mais totalement mauvaise en cas de downscaling sur des images avec des détails fins.

[GrassEh]

Le switch de String, enfin ! Depuis le temps qu'on l'attendait celui là bien qu'il est pas fréquent de l'utiliser

[tchize_]

Envoyé par GrassEh

Le switch de String, enfin ! Depuis le temps qu'on l'attendait celui là bien qu'il est pas fréquent de l'utiliser

tu m'étonne, vu qu'il existe pas encore

[spall]

Envoyé par Jack Sparrow

Enfin, un NullPointerException est quand même une erreur grave, qui vient souvent d'une erreur dans le programme ou un problème de packaging.

Un NullPointerException ne me semble pas particulièrement moins grave qu'un OutOfMemoryException.

Dans un système de plugin (par exemple pour du traitement d'images), il n'est pas improbable qu'il y ait un OutOfMemoryException, donc je ne vois pas particulièrement une raison de laisser passer un NullPointerException et pas un OutOfMemoryException.
-> on catche tout, et s'il n'y a plus de mémoire, le reste de l'application se cartonnera plus tard (voir pas du tout si le plugin avait besoin de 500mo)

Il me semble qu'il a quand même un petite différence entre un NullPointer et un OutOfMemory. En général le NullPointer est plutôt du à un problème de code (checks insuffisants, etc.), il est souvent reproductible. Tandis que l'OutOfMemory est plutôt indépendant du programme (sauf erreur grossière...) il lié à l'environnent d'exécution et rarement gérable par le programme.

Toute la différence réside dans la hiérarchie de classe. NullPointerException hérite de Exception tandis que OutOfMemoryError hérite de Error.

J'en viens à la réflexion initiale de r1-1024 :

Envoyé par r1-1024

Très souvent dans le coeur d'une appli à plugin il est indispensable de faire un catch(Throwable).
Par ex :
Un plugin déclare une vue (une JTable par ex). Après passage d'un algo, le coeur de l'appli gère les mises à jours. Et là le plugin se viande et une belle NullPointer revient dans le coeur. Là il est indispensable de faire un truc du genre :

Code :

Si on veut protéger un minimum l'appli.

Eh bien non, il faut cacher "Exception", pas "Throwable" et çà suffit.

Voilà pourquoi il est fortement déconseillé de faire "catch(Throwable t)", cf.:

http://checkstyle.sourceforge.net/co...l#IllegalCatch

Seb.

[grunt2000]

Il peut arriver que l'on veuille obtenir à l'issue de l'exécution d'une fonction une exception à tous les coups trappable, pour des motifs spécifiques, en évitant deux écueils:

- Laisser remonter une exception que l'on ne pourrait pas traiter.
(on peut admettre que l'on soit dans une section si critique qu'il faille vraiment détecter tout problème).

- Renvoyer Exception soi-même. Car un public void maFonction throws Exception c'est presque ainsi que les malheurs de l'humanité on commencé. On perdrait toute précision d'incident pour la suite de la pile d'appel.

Donc, dans ce cas on peut réaliser ceci:

Code :

1
2
3
4
5
6
7
8
9
10
11
public void maFonction throws MonExceptionSpecifique
{
   try
   {
       ... code, pouvant éventuellement lever MonExceptionSpecifique...
   }
   catch(RuntimeException e)
   {
       throws(new MonExceptionSpecifique(e.getMessage(), e));
   }
}

Et super éventuellement, après avoir mille fois réfléchi, et encore en se flagellant et en faisant des donations:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public void maFonction throws MonExceptionSpecifique
{
   try
   {
       ... code, pouvant éventuellement lever MonExceptionSpecifique...
   }
   catch(RuntimeException e)
   {
       throws(new MonExceptionSpecifique(e.getMessage(), e));
   }
   catch(Error e)
   {
       throws(new MonExceptionSpecifique(e.getMessage(), e));
   }
}

Mais là, on se met déjà bien en danger. C'est pas beau.
Moi, quand ça m'arrive de devoir faire ça, c'est tellement terrible que j'enlève mon nom d'auteur du source et je mets celui de mon voisin.

Mais cela reste meilleur que le catch(Throwable t) {}, qui oublie tout.
ou le throws Exception (ou throws Throwable, arghhh), qui mélange tout.

Grunt.

[jblecanard]

Envoyé par r1-1024

-intégrer jogl en standard et porter swing en jogl. Sun s'offrirerai enfin le luxe de couper l'herbe sous le pied à Adobe à propos de la 3D native (qu'ils sont visiblement pas près d'avoir).

Envoyé par gouessej

Kenneth Russell ne veut pas qu'on fasse ça (pour que le JDK ne dépende pas d'une version particulière de JOGL entre autre) mais ça n'empêche pas que JavaFX utilise en douce JOGL. Swing bénéficie déjà de l'accélération graphique, il faudrait plutôt que le pipeline OpenGL existant soit fiabilisé car c'est pas encore ça sur certaines machines.

Justement, il faudrait se débarasser de cette vieille locomotive en l'intégrant en natif dans la JVM, de telle sorte que la maintenance de JOGL passe directement par le process de développement de Java, et non pas que l'équipe Java intègre après coup le travail effectué sur Jogl (ce que ne veux pas Kenneth j'imagine, et je suis d'accord).

Certes, ça pose des problèmes de licences, et le démarrage d'une telle chose est un vrai casse-tête, mais ça serait tellement bien !

[Yomhgui]

Envoyé par tchize_

Si tu change ça, tu pete toutes les applications existantes qui supposent qu'un champ protected doit etre accessible aussi depuis le paquet. On pourrait ajouter un nouveau mot clé, mais chez sun ils aiment pas ajouter de nouveaux mots clés . Puis comme on l'a dit, ca changerais le bytecode et c'était visiblement pas le but

Tout à fait OK. Par ailleurs, il me semble que c'est même techniquement délicat, sinon impossible, car il est nécessaire de pouvoir définir un ordre sur les portées pour pouvoir implémenter la covariance/contravariance dans le cas de méthodes héritées. Par ex:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public abstract class A {
 
    void doSomething() {}
 
}
 
public class C extends A {
 
    @Override
    protected void doSomething() {}
 
}

Pour pouvoir faire ça, il doit être nécessaire de pouvoir dire : private < package protected < protected < public. Et pour pouvoir dire que package protected "est inférieur" à protected, il faut bien que la seconde notion "contienne" complètement la première.

[Stef_D]

Je suis assez étonné que le switch(String) ait été ajouté.
Pour moi l'instruction switch doit se faire sur un type ordinal dont la taille est connue, cela permet d'optimiser les tests en découpant en table de saut en interne quand c'est possible. Faire un switch sur un String, je trouve ça plutot crado en fait... bien que pratique pour le code je reconnais.

Venant du monde Delphi je trouvais la notion de propriété très intéressante, je suis assez surpris qu'elle n'existe toujours pas en java... est-il prévu de l'ajouter un jour ? ou cela est-il tout simplement impossible du fait des modifications que cela demanderaient ?

J'ai vu aussi une discussion sur la possibilité de limiter le rattrapage de certaines erreurs que le "outOfMemory". Perso ça me gênerait bien de ne pas pouvoir rattraper cette erreur quand je le souhaite. Pas plus tard qu'hier j'ai du gérer le cas du outOfMemory sur un exemple tout bête : je dessine un masque pour une image, la taille du masque est complètement dynamique et peut dépasser celle de l'image de base, l'utilisateur peut la modifier simplement en dessinant en dehors des bordures actuelles... dans ce cas on peut arriver assez facilement à la limite mémoire de la JVM, j'ai donc fait un bête catch (Error) sur le redimensionnement du masque et en cas d'erreur on reste sur la dimension actuel et on affiche un message dans le log...

Tout le problème est de bien faire son code ou non, je pense que trop d'assistance afin d'éviter le mauvais code peut juste conduire à certaines limitations et surtout ça ne fait pas progresser le développeur en général.

[adiGuba]

Envoyé par Stef_D

Je suis assez étonné que le switch(String) ait été ajouté.
Pour moi l'instruction switch doit se faire sur un type ordinal dont la taille est connue, cela permet d'optimiser les tests en découpant en table de saut en interne quand c'est possible. Faire un switch sur un String, je trouve ça plutot crado en fait... bien que pratique pour le code je reconnais.

Le switch(String) sera également optimisé à la compilation

Par contre je ne trouve pas du tout que cela soit crado : les solutions alternatives le sont bien plus je trouve :

• Multiplier les if/else.
• Remplir une Map<String,Runnable> puis exécuter map.get(value).run().
• Créer une Enum "juste pour ca".

Après tout une String est un des type les plus utilisé

Envoyé par Stef_D

Venant du monde Delphi je trouvais la notion de propriété très intéressante, je suis assez surpris qu'elle n'existe toujours pas en java... est-il prévu de l'ajouter un jour ? ou cela est-il tout simplement impossible du fait des modifications que cela demanderaient ?

Il y a eu plusieurs suggestions, mais aucune n'a vraiment convaincu.

• Soit il s'agissait de simple sucre syntaxique, mais aux fonctionnalités limités.
• Soit il s'agissait d'un système de propriété complet, mais aui aurait été initulisable avec le code existant.

Envoyé par Stef_D

J'ai vu aussi une discussion sur la possibilité de limiter le rattrapage de certaines erreurs que le "outOfMemory".

Tu as une source pour cela ?

Par contre rattraper une OutOfMemory c'est pas top


a++

[Stef_D]

Envoyé par adiGuba

Le switch(String) sera également optimisé à la compilation

Par contre je ne trouve pas du tout que cela soit crado : les solutions alternatives le sont bien plus je trouve :

• Multiplier les if/else.
• Remplir une Map<String,Runnable> puis exécuter map.get(value).run().
• Créer une Enum "juste pour ca".

Après tout une String est un des type les plus utilisé

Je ne vois pas comment tu peux optimiser un switch(String) comparé à un ensemble de if () else if () ? Enfin peut-être ont ils des méthodes...
Et quand je dis crado, je parle de ce qui se passe en interne (String reste un objet, avec une méthode equals()...), sur la syntaxe ça me pose aucun problème, au contraire même !

Il y a eu plusieurs suggestions, mais aucune n'a vraiment convaincu.

• Soit il s'agissait de simple sucre syntaxique, mais aux fonctionnalités limités.
• Soit il s'agissait d'un système de propriété complet, mais aui aurait été initulisable avec le code existant.

C'est bien dommage que ça n'ai pas été intégré dans les débuts, quand cela était encore possible. Ça offre vraiment des possibilités intéressantes, aussi bien en fonctionnalité que d'un point de vue purement objet.

Tu as une source pour cela ?

Par contre rattraper une OutOfMemory c'est pas top

C'est au début de ce même topic et pourquoi rattraper une OutOfMemory n'est pas top ? Effectivement c'est une erreur fatale, mais si tu sais qu'une partie de ton code est tout à fait susceptible de la générer ? et surtout si tu la rattrapes correctement avec une action en conséquence de cette erreur (en l'occurrence moi je reste sur la taille actuelle de mon image) ? Tu penses qu'il est préférable de s'embêter à tester la consommation mémoire de ta prochain allocation et de vérifier si tu as assez de mémoire dispo pour la faire ? Bien sur tu ne vas pas rattraper le OutOfMemory partout, on a pas à prévoir ça et heureusement mais sur un cas particulièrement couteux en mémoire et où justement l'utilisateur peut arriver à la limite moi ça me choque pas.

[adiGuba]

Envoyé par Stef_D

Je ne vois pas comment tu peux optimiser un switch(String) comparé à un ensemble de if () else if () ? Enfin peut-être ont ils des méthodes...
Et quand je dis crado, je parle de ce qui se passe en interne (String reste un objet, avec une méthode equals()...), sur la syntaxe ça me pose aucun problème, au contraire même !

Justement il est possible d'utiliser un hashCode pour obtenir une valeur numérique représentant la chaine, et ainsi générer un simple switch(int).

Par exemple, ceci :

Code :

1
2
3
4
5
6
7
8
        switch(str) {
        case "AA":
            break;
        case "BB":
            break;
        case "CC":
            break;
        }

Pourrait être automatiquement compilé en ceci :

Code :

1
2
3
4
5
6
7
8
        switch (str.hashCode()) {
        case 2080: // "AA"
            break;
        case 2112: // "BB"
            break;
        case 2144: // "CC"
            break;
        }

Bien sûr cela ne génère pas forcément un nombre unique pour chaque String et il pourra y avoir des "doublons". Dans ce cas là il suffira de coupler cela avec un if/else mais uniquement pour les valeurs ayant le même hashCode...

Mais on est quand même loin des gros if/else qui n'en finissent plus

Envoyé par Stef_D

C'est au début de ce même topic

Ok je pensais que tu parlais d'une discussion officiel sur les listes de diffusion de Sun/Oracle à propos de l'avenir de Java...

Envoyé par Stef_D

et pourquoi rattraper une OutOfMemory n'est pas top ?

Parce que n'est pas fiable : rien ne dit que l'OutOfMemory surviendra bien au moment où tu demande beaucoup de mémoire. En clair lors du chargement de ton image tu pourrais occuper 99% de la mémoire, et cela fera planter une méthode anodine "autre part".


a++

[Stef_D]

Envoyé par adiGuba

Justement il est possible d'utiliser un hashCode pour obtenir une valeur numérique représentant la chaine...

Ah oui en effet dans ce cas si c'est directement optimisé en interne c'est plutot pas mal

Parce que n'est pas fiable : rien ne dit que l'OutOfMemory surviendra bien au moment où tu demande beaucoup de mémoire. En clair lors du chargement de ton image tu pourrais occuper 99% de la mémoire, et cela fera planter une méthode anodine "autre part".

Bien sur comme je disais on ne surveille pas un outOfMemory général, je ne le fais qu'à cet endroit bien précis car je sais qu'il y a une très grosse allocation derrière et que les chances d'un outOfMemory sont bien plus importantes ici qu'ailleurs et comme je peux le gérer facilement j'en profite, dans les autres cas tant pis, on s'en remet à "y'a pas assez de mémoire sur le système", on n'y peut rien et voilà...