IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage Java Discussion :

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


Sujet :

Langage Java

  1. #1
    Expert éminent sénior
    Avatar de Baptiste Wicht
    Homme Profil pro
    Étudiant
    Inscrit en
    octobre 2005
    Messages
    7 431
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Suisse

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2005
    Messages : 7 431
    Points : 21 318
    Points
    21 318
    Par défaut JDK 7 : Que pensez-vous des nouveautés et qu'auriez-vous aimé avoir de nouveau ?
    Bonjour,

    Ce débat est destiné à parler des nouveautés du JDK 7 (pas seulement le projet Coin).

    Qu'en pensez-vous ?
    Qu'auriez-vous aimé d'autre dans cette nouvelle version de Java ?
    Qu'aimeriez-vous voir dans les futures version de Java ?

  2. #2
    Membre du Club Avatar de r1-1024
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    138
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 138
    Points : 68
    Points
    68
    Par défaut
    L'invocation dynamique c'est le seul truc que je retiendrai. Pour le reste, une bonne completion / indentation fait l'affaire.

    Par contre j'aurai aimé qu'ils se penchent sur des points importants :

    -accélérer les fonctions trigos qui sont 10 fois plus lentes qu'en C (donc toujours pas de code de calcul en java : vive la fft et le traitement de signal)
    -a quand un delete possible (comme pour flash), on pourrai enfin avoir un code java reproductible en temps ?
    -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).
    -accélérer le temps de chargement des applets javafx pour faire enfin décoller ce petit bijoux.
    -pourquoi une méthode/champs protected est toujours en visibilité pacquet ?
    -pouvoir déclarer les InnerClass dans un .java pour plus de lisibilité (ceux qui vont souvent dans le code de la JVM me comprendront).
    -pouvoir compiler une chaîne de caractère autrement que ""+""+"". Impec pour des requêtes SQL, l'écriture XML ou d'un code assembleur/C pour un shader.
    -a qd un preprocesseur en standard javac ?

    Des moins importants :

    -corriger l'implémentation douteuse des JDialog et les weakreference de leurs enfants (ça c très merdique et très décevant de la part de Sun).
    -configuration automatique possible du garbage collector (xmx dépend de la machine cible)
    -possibilité de renommer java.exe et de le sortir de java/bin (impec pour le déploiement et le kill d'une appli java)
    -Pouvoir ajouter des listeners en réponse au kill pour libérer des ressources par ex.
    -Il était question d'extraire le window manager de netbean et de le mettre en std !


    Et un truc qui serai franchement top :
    - Avoir des exceptions qui ne puissent être rattrapées que par certaine classe.
    (par ex le OutOfMemory ne devrait pas être rattrapable par n'importe qui).
    - Pouvoir faire un pull de mémoire configurable par classloader.

    Avec ces deux trucs (et le SécurityManager) , une appli à plugin pourrait gérer complètement les défaillances de ses petits.

  3. #3
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 25 481
    Points : 48 820
    Points
    48 820
    Par défaut
    Citation Envoyé par r1-1024 Voir le message
    -pourquoi une méthode/champs protected est toujours en visibilité pacquet ?
    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
    -pouvoir déclarer les InnerClass dans un .java pour plus de lisibilité (ceux qui vont souvent dans le code de la JVM me comprendront).
    Tu veux dire la sortir de sa parent class pour la stocker dans un .java indépendant?
    -pouvoir compiler une chaîne de caractère autrement que ""+""+"". Impec pour des requêtes SQL, l'écriture XML ou d'un code assembleur/C pour un shader.
    Au choix tu a stringbuilder, stringbuffer, stringformat

    -possibilité de renommer java.exe et de le sortir de java/bin (impec pour le déploiement et le kill d'une appli java)
    Il me semble que, sous unix, par exemple, il est impossible de renommer une application une fois lancée, que ce soit en java ou autre
    -Pouvoir ajouter des listeners en réponse au kill pour libérer des ressources par ex.
    Voir la doc sur les shutdownHooks. Pour les autres signaux (sous unix par exemple), il faut passer par des apis natives spécifique car la notion de signaux n'existe pas sur tout les OS
    - Avoir des exceptions qui ne puissent être rattrapées que par certaine classe.
    (par ex le OutOfMemory ne devrait pas être rattrapable par n'importe qui).
    Je peux comprendre que ca permet de contourner le problème des zozos qui font du catch(Throwable), mais le problème de base là, c'est le mauvais codage dans l'appli en question, pas le role du copilateur de tourner autour de ces erreurs. De plus on peux envisager des cas ou ce catch est légitime (bien que limite). Tu lancer un calcul gourmand mais rapide, tu catch le OutOfMemory et en cas de déclenchement tu calcul autrement avec moins de mémoire.

    - Pouvoir faire un pull de mémoire configurable par classloader.
    Je vois bien l'idée mais ca poserais en pratique d'énorme soucis en raison du principe de délagation des classloader (va-t-en savoir qui doit être le propriétaire de la String machin qu'on viens de créer). A la rigeur une zone mémoire par threadgroup ce serait peut être gérable (et encore)

  4. #4
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    4 295
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations forums :
    Inscription : avril 2002
    Messages : 4 295
    Points : 12 930
    Points
    12 930
    Par défaut
    Citation Envoyé par r1-1024 Voir le message
    -accélérer les fonctions trigos qui sont 10 fois plus lentes qu'en C (donc toujours pas de code de calcul en java : vive la fft et le traitement de signal)
    -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).
    -accélérer le temps de chargement des applets javafx pour faire enfin décoller ce petit bijoux.
    -corriger l'implémentation douteuse des JDialog et les weakreference de leurs enfants (ça c très merdique et très décevant de la part de Sun).
    -configuration automatique possible du garbage collector (xmx dépend de la machine cible)
    -possibilité de renommer java.exe et de le sortir de java/bin (impec pour le déploiement et le kill d'une appli java)
    -Pouvoir ajouter des listeners en réponse au kill pour libérer des ressources par ex.
    -Il était question d'extraire le window manager de netbean et de le mettre en std !
    - Pouvoir faire un pull de mémoire configurable par classloader.
    - Avoir des exceptions qui ne puissent être rattrapées que par certaine classe.
    (par ex le OutOfMemory ne devrait pas être rattrapable par n'importe qui).
    Cet article ne couvre que le projet Coin. Tout ceci ne correspond pas a des évolution du langage même mais a des évolutions de la JVM ou de ses API, ce qui ne concerne pas le projet Coin.
    Pour ce qui est du listener en réponse au kill, ca existe déjà.

    -a quand un delete possible (comme pour flash), on pourrai enfin avoir un code java reproductible en temps ?
    Tu voudrais un delete à la C++ qui détruirait immédiatement l'objet sans passer par le garbage collector?
    L'idée peu paraitre intéressante pour certain cas particulier. Mais pour le coup ca deviens dangereux car sa casserait un principe fondamental en java : toute référence a un objet est toujours valide.
    L'impact de ce genre de chose me parait énorme et ca pourrait potentiellement entrainer beaucoup de problèmes.

    -pourquoi une méthode/champs protected est toujours en visibilité pacquet ?
    Parceque je ne crois pas que ca pose de problèmes à grand monde. De plus changer ça, changerait les base même du langage et causerait des problèmes de compatibilité inutiles

    -pouvoir déclarer les InnerClass dans un .java pour plus de lisibilité (ceux qui vont souvent dans le code de la JVM me comprendront).
    Je n'avais jamais songé a ça mais c'est vrai que ça pourrait être intéressant.

    -pouvoir compiler une chaîne de caractère autrement que ""+""+"". Impec pour des requêtes SQL, l'écriture XML ou d'un code assembleur/C pour un shader.
    La je ne comprends pas vraiment ce que tu souhaites.

    -a qd un preprocesseur en standard javac ?
    Jamais je l'espère. Java s'en passe très bien pour le moment et si tu en a besoin pour un usage très particulier, rien ne t'empêches d'en utiliser un.
    Par curiosité, pour quel genre de chose aurait tu besoin de ça.

  5. #5
    Membre du Club Avatar de r1-1024
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    138
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 138
    Points : 68
    Points
    68
    Par défaut
    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
    J'suis qd même currieux de savoir pour quelle raison ils ont fait ce choix.
    C vrai que l'incompatibilité serait génante.

    Tu veux dire la sortir de sa parent class pour la stocker dans un .java indépendant?
    Oui

    Au choix tu a stringbuilder, stringbuffer, stringformat
    En fait j'pensais à un truc du type as3
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    var monXML:XML = new XML ();
    monXML = <balise><test/></balise>;

    mais plus générique du type
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    StringBuilder ou String s={mon texte de n'importe quoi encodé dans 
    l'encodage du source java qui prend donc pas trop de place mais qui est très
     pratique pour faire des requête au xml ou ... maintenable}
    Il me semble que, sous unix, par exemple, il est impossible de renommer une application une fois lancée, que ce soit en java ou autre
    Malheureusement pour l'humanité il existe autre chose qu'UNIX.
    Et puis je pense que ça peut poser des problèmes avec jconsole (mais la je m'avance).
    C qd même pas la mort de permettre ça. Ils en ont bien conscience car la majorité des IDE font un lanceur home made.

    shutdownHooks
    ya ca c du bon

    Je peux comprendre que ca permet de contourner le problème des zozos qui font du catch(Throwable), mais le problème de base là, c'est le mauvais codage dans l'appli en question, pas le role du copilateur de tourner autour de ces erreurs. De plus on peux envisager des cas ou ce catch est légitime (bien que limite). Tu lancer un calcul gourmand mais rapide, tu catch le OutOfMemory et en cas de déclenchement tu calcul autrement avec moins de mémoire.
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
     
    for(View view:Views)
    {
      try
      {
        view.update();
      }
      catch(Throwable t)
      {
         //on fait un truc en conséquence
      }
     
    }
    Si on veut protéger un minimum l'appli.

    Si le security manager pouvait aussi gérer les catch ...

    Je vois bien l'idée mais ca poserais en pratique d'énorme soucis en raison du principe de délagation des classloader (va-t-en savoir qui doit être le propriétaire de la String machin qu'on viens de créer). A la rigeur une zone mémoire par threadgroup ce serait peut être gérable (et encore)
    Un peu comme APR (Apache). Mais passer par les ClassLoader c'est ambigue.
    Nouvel argument à new alors.

  6. #6
    Membre du Club Avatar de r1-1024
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    138
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 138
    Points : 68
    Points
    68
    Par défaut
    Tu voudrais un delete à la C++ qui détruirait immédiatement l'objet sans passer par le garbage collector?
    L'idée peu paraitre intéressante pour certain cas particulier. Mais pour le coup ca deviens dangereux car sa casserait un principe fondamental en java : toute référence a un objet est toujours valide.
    L'impact de ce genre de chose me parait énorme et ca pourrait potentiellement entrainer beaucoup de problèmes.
    Oui. Effectivement ça casserait ce principe. Mais il me semble important de pouvoir indiquer au gc qu'un objet de nième génération est libérable (si il est d'accord sur ce point, il efface immédiatement l'object et ce de façon récursive sur le graphe objet) afin d'éviter que le gc ne se déclenche à un moment inattendu et généralement inopportun.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    delete obj;
    //serait équivalent à
    obj=null;
    System.gc();
    //si System.gc() était déterministe
    //ici rien ne garanti que notre objet soit effacé
    Jamais je l'espère. Java s'en passe très bien pour le moment et si tu en a besoin pour un usage très particulier, rien ne t'empêches d'en utiliser un.
    Par curiosité, pour quel genre de chose aurait tu besoin de ça.
    Je pense comme toi que l'utilisation bourine du preprocessor est à bannir.
    Mais son utilisation intelligente est à benir.
    C'est en regardant le source de GIMP ( je crois que c gimp) que j'me suis souvenu du preprocessor et de sa puissance.

    Bien souvent les IDE proposent de générer du code automatiquement, qu'il faut reprendre généralement. Une macro permet de faire la même chose en mieux.
    Ca permet de façon très concise d'avoir un résultat équivalent qu'à du xml qui passe dans du xsl pour faire du java et un autre source java car le xml ne suffit jamais en soi.

  7. #7
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par r1-1024 Voir le message
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    delete obj;
    //serait équivalent à
    obj=null;
    System.gc();
    //si System.gc() était déterministe
    //ici rien ne garanti que notre objet soit effacé
    Problème #1 : System.gc() est super lourd et doit être évité !
    Problème #2 : ce n'est pas parce que tu mets une référence à null que l'objet correspondant peut être libéré.
    Problème #3 : si tu veux un comportement déterministe il faut revoir complètement la gestion de la mémoire, afin qu'une référence que tu "supprimes" avec delete ne soit pas partagé... sinon on va se retrouver avec des références invalides ce qui est une abbération en Java


    Tout cela pour pas grand chose en fait...


    a++

  8. #8
    Membre du Club Avatar de r1-1024
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    138
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 138
    Points : 68
    Points
    68
    Par défaut
    Problème #1 : System.gc() est super lourd et doit être évité !
    Problème #2 : ce n'est pas parce que tu mets une référence à null que l'objet correspondant peut être libéré.
    Problème #3 : si tu veux un comportement déterministe il faut revoir complètement la gestion de la mémoire, afin qu'une référence que tu "supprimes" avec delete ne soit pas partagé... sinon on va se retrouver avec des références invalides ce qui est une abbération en Java
    Désolé, j'me suis mal exprimé.
    Le "delete" n'est pas fait pour effacer l'objet sans vérif (je crois que c'est le cas dans flash).
    En fait delete n'est pas approprié, il faudrait plutôt l'appeler gcOn(obj)

    Le but est simplement de notifier au gc que l'objet en question ne devrait plus être référencé et si tel est le cas de l'effacer.

    Cette opération ne serait pas effectuée si l'objet était référencé ailleurs.

    Exemple :
    Dans une application MDI j'effectue les opérations suivantes :
    -Open project
    -Do something costly
    -Save & close project
    Moi en interne je n'ai plus aucune référence sur le projet mais le gc ne s'est tjrs pas déclanché et le projet est à coup sûr encore en RAM. Même si il s déclanche ou que j'invoke le gc, comme mon projet est de nième génération, il ne sera pas libéré.
    -New project (et là j'attends que le gc fasse son boulot car j'ai plus de mémoire)

  9. #9
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 25 481
    Points : 48 820
    Points
    48 820
    Par défaut
    si tu regarde la manière dont fonctionne le gc en interne, tu verra que on ne peux jamais supprimer 1 objet. On travaille toujours sur des calculs de l'ensemble des objet. Ton problème est un problème de performance, et un mot clé delet eest une fausse solution. Ce qu'il faut c'est simplement des GC plus performant. Sinon lors du delete, tu va parcourir toute la heap pour tester si 1 objet peut être libéré, alors qu'il faudrait au contraire libérer tout ce qui est libérable à ce moment là.

  10. #10
    Membre du Club Avatar de r1-1024
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    138
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 138
    Points : 68
    Points
    68
    Par défaut
    C surement pour ca que flash doit effacer l'objet sans vérifier le graphe objet.
    J'ai eu pas mal de retour clients qui se plaignaient de ce comportement sur des applis gourmandes, et là malheureusement ya rien à faire.

  11. #11
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 25 481
    Points : 48 820
    Points
    48 820
    Par défaut
    tu peux lancer la jvm en mode server. Ceci utilise un algorithme de garbage collector qui réduit les blocage dus au GC.

  12. #12
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    4 295
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations forums :
    Inscription : avril 2002
    Messages : 4 295
    Points : 12 930
    Points
    12 930
    Par défaut
    De plus dans java 7 il y aura un nouvel algorithme de Garbage Collector nomé G1 qui devrait aussi permettre d'augmenter les perfs et de réduire les pauses.
    Il est même déjà disponible dans les toutes dernières updates du JRE 6, en tant qu'option expérimentale et désactivée par défaut. Pour plus d'explication sur G1 :http://java.sun.com/javase/technolog...c/g1_intro.jsp

  13. #13
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par r1-1024 Voir le message
    -accélérer les fonctions trigos qui sont 10 fois plus lentes qu'en C (donc toujours pas de code de calcul en java : vive la fft et le traitement de signal)
    10 fois? Ca m'étonnerait. De plus, l'API ForkJoin ouvre la porte à l'utilisation des SIMD en Java (jetez un coup d'oeil à la classe ParallelArray par exemple) :
    http://www.javac.info/jsr166z/jsr166...llelArray.html
    Le coeur algorithmique de certaines applications professionnelles scientifiques utilise déjà Java, c'est ce qui me mène à penser que tu exagères.

    Citation Envoyé par r1-1024 Voir le message
    -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).
    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.

    Citation Envoyé par r1-1024 Voir le message
    -accélérer le temps de chargement des applets javafx pour faire enfin décoller ce petit bijoux.
    Le Java Kernel résoud déjà en partie ce problème dans Java 1.6, l'installeur Adobe fait 1.8 Mo et ce kernel fait environ 3 Mo.

    Citation Envoyé par tchize_ Voir le message
    tu peux lancer la jvm en mode server. Ceci utilise un algorithme de garbage collector qui réduit les blocage dus au GC.
    Tu peux aussi fixer la durée des pauses en utilisant l'Incremental Low Pause Collector.

    Vous pouvez forcer la finalisation et appeler le ramasse-miettes mais ça ne règlera pas le problème si c'est une fuite mémoire (pensez à Purify Plus ou à un profiler).

  14. #14
    Membre chevronné
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    juillet 2006
    Messages
    1 242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 73
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : juillet 2006
    Messages : 1 242
    Points : 1 829
    Points
    1 829
    Par défaut
    brainstorming (c.a.d. je me réserve le droit de dire des bétises )

    souhaiter une plus grande facilité de modification du comportement du compilateur en fonction d'annotations.

    exemple 1:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    class Produit {
        @MightBeNull private String description ;
     
    }
    toutes les fois où on utilise ce champ warning si pas syntaxe spéciale pour tester si la référence est nulle.
    en poussant le bouchon on pourrait transférer l'annotation à la méthode "getDescription" ... sauf qu'il est possible que ce test outrepasse les possibilités du compilateur ....(peut-on prouver qu'on peut vérifier que l'affectation du résultat de la méthode peut être aussi controlée partout?)

    exemple 2:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
      public void méthode(@PRECOND(TestPositif.class) Number arg) {
        .....
    On impose ici à l'argument une précondition ... le compilateur peut remonter la pile des invocations pour controler si le test est fait quelque part (un peu à la manière des Exceptions controlées)...

    même remarque que précédement: nécessite des évolutions syntaxiques, pas évident que ce soit toujours faisable, chatouille un peu plus les annotations en leur faisant jouer un rôle proche de la sémantique du programme...

    mais bon on peut toujours réver
    J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
    (mon excellent bouquin sur Java : https://eska-publishing.com/fr/livre...822407076.html)

  15. #15
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par professeur shadoko Voir le message
    mais bon on peut toujours réver
    Ce n'est pas tellement un rêve : non seulement cela existe déjà mais il y a déjà des travaux là dessus via la JSR 305 !

    • Des outils d'analyses comme FindBugs ou celui intégré dans l'EDI IntelliJ permettent déjà d'utiliser des annotations propriétaires pour définir ces informations, et permettre une meilleure détection des bugs.

      Le problème c'est justement que ces annotations ne sont pas standard, donc peu utilisé... ce qui les rend peu utile !

    • La JSR 305 (Annotations for Software Defect Detection) a justement pour objectif de définir un ensemble d'annotations standard qui pourrait être utilisé par ces outils, ce qui permettra de les utiliser massivement et donc d'améliorer leurs résultats !


    Je ne pense pas que cela soit intégré directement dans javac, mais si c'est standardisé il y a de forte chance que ce soit intégré directement dans les EDI.



    Maintenant cela ne semble pas avoir beaucoup avancé... donc je ne sais pas si ce sera présent dans Java 7 ou pas...


    a++

  16. #16
    Membre confirmé

    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    août 2007
    Messages
    509
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux

    Informations forums :
    Inscription : août 2007
    Messages : 509
    Points : 613
    Points
    613
    Par défaut
    Citation Envoyé par r1-1024 Voir le message
    -pouvoir déclarer les InnerClass dans un .java pour plus de lisibilité (ceux qui vont souvent dans le code de la JVM me comprendront).
    Citation Envoyé par tchize_
    Tu veux dire la sortir de sa parent class pour la stocker dans un .java indépendant?
    euh ... . Est ce que ca ne revient pas à créer une simple classe. Sinon, c'est quoi la différence?

  17. #17
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    4 295
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations forums :
    Inscription : avril 2002
    Messages : 4 295
    Points : 12 930
    Points
    12 930
    Par défaut
    La différence c'est que l'objet d'une inner-class reste relié à la classe l'englobant. Il est a une visibilité limitée a cette classe, et accès direct aux attributs/méthodes de cette classe, ...

  18. #18
    Membre chevronné
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    juillet 2006
    Messages
    1 242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 73
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : juillet 2006
    Messages : 1 242
    Points : 1 829
    Points
    1 829
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    on ne lit jamais assez les manuels: les annotations de findbugs m'avaient échappé! (je trouve les règles générales de cet outil beaucoup plus pertinentes que celles de checkstyle).
    ça me semble un minimum; les règles sur les préconditions sont probablement plus dures à implanter. .... mais a première vue beaucoup de choses seraient faisables.
    merci!
    J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
    (mon excellent bouquin sur Java : https://eska-publishing.com/fr/livre...822407076.html)

  19. #19
    Membre confirmé

    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    août 2007
    Messages
    509
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux

    Informations forums :
    Inscription : août 2007
    Messages : 509
    Points : 613
    Points
    613
    Par défaut
    Citation Envoyé par Uther Voir le message
    La différence c'est que l'objet d'une inner-class reste relié à la classe l'englobant. Il est a une visibilité limitée a cette classe, et accès direct aux attributs/méthodes de cette classe, ...
    Oui mais, est ce que ca ne revient quand meme pas à créer une simple classe .java?

  20. #20
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    4 295
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations forums :
    Inscription : avril 2002
    Messages : 4 295
    Points : 12 930
    Points
    12 930
    Par défaut
    Oui, ça serait un fichier .java séparé mais qui fonctionnerait comme une inner classe et qui hériterait des particularités que j'ai cité.

    Par exemple:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    //fichier Main.java
    public class Main {
        int a = 0;
     
        Main() {
            SousClasse sc = new SousClasse();
            sc = new SousClasse();
        }
     
        public static void main(String[] args) {
            Main m = new Main();
            System.out.println("resultat: " + m.a);
        }
     
        class SousClasse {
            SousClasse() {
                a++;
            }
        }
    }
    Pourrait donner quequechose comme:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    //fichier Main.java
    public class Main {
        int a = 0;
     
        Main() {
            SousClasse sc = new SousClasse();
            sc = new SousClasse();
        }
     
        public static void main(String[] args) {
            Main m = new Main();
            System.out.println("resultat: " + m.a);
        }
    }
    //Fichier Main$SousClasse.java
    class Main.SousClasse {
        SousClasse() {
            a++;
        }
    }
    Si SousClasse est une classe séparée, elle ne pourrait pas accéder à la variable "a". De plus un objet de type SousClasse n'est instanciable que depuis un objet de la classe Main contrairement a une classe séparée.

    Bref les inner-classe sans des fichier séparés ne me parait pas une idée idiote. Ça pourrait être un gain en lisibilité si les inner-classes sont très grosses. Mais à mon avis, c'est loin d'être indispensable au vu de la complexité de l'évolution par rapport au gain.

Discussions similaires

  1. Que pensez vous des nouveautés d'Analysis Services 2012?
    Par FrancoisJehl dans le forum Microsoft BI
    Réponses: 6
    Dernier message: 08/05/2013, 10h16
  2. Que pensez-vous de SAP et des ERP ?
    Par cortex024 dans le forum SAP
    Réponses: 42
    Dernier message: 19/03/2011, 14h33
  3. Que pensez-vous des générateurs de doc PHP ?
    Par Nonothehobbit dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 64
    Dernier message: 10/07/2007, 10h17
  4. [Choix] Que pensez vous des CMS de type Mambo ?
    Par Nikeleos dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 5
    Dernier message: 02/09/2005, 12h45
  5. [Débat] Que pensez-vous des langages à typage dynamique?
    Par Eusebius dans le forum Langages de programmation
    Réponses: 14
    Dernier message: 16/06/2004, 12h12

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo