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

  1. #1
    Responsable .NET

    Avatar de Hinault Romaric
    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2007
    Messages
    4 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 4 559
    Points : 251 947
    Points
    251 947
    Billets dans le blog
    105

    Par défaut Oracle lance une nouvelle tentative pour intégrer la modularité à Java

    Oracle lance une nouvelle tentative pour intégrer la modularité à Java
    une nouvelle implémentation du projet Jigsaw voit le jour

    Java n’est pas prêt à être doté d’un système de modules grâce au projet Jigsaw. Mark Reinhold, architecte en chef du groupe de la plateforme Java chez Oracle vient d’annoncer le redémarrage du projet.

    Le projet Jigsaw vise essentiellement à découper la bibliothèque d’exécution de base de Java en différents modules. Cela devrait permettre à une machine virtuelle Java (JVM) de fonctionner sans le support de certains packages de base.

    Après un travail préliminaire qui avait abouti à une proposition en 2008, le système de modules du projet Jigsaw allait être l’une des principales innovations de Java 7. Le projet a été reporté ensuite à Java 8, puis finalement, Oracle a annoncé sa sortie avec Java 9, annoncé pour 2015.

    Les principales raisons de ces reports sont des problèmes techniques liés à la compatibilité. La mise au point d’un système de modularité dans le JDK est un véritable défi, à cause des dépendances qui existent entre les packages. Par exemple, java.beans à une dépendance vers java.applet, qui dépend à son tour de java.awt.

    Face aux difficultés rencontrées, Mark Reinhold vient d’annoncer la création d’un nouveau prototype de Jigsaw pour explorer une approche simplifiée pour la réalisation des objectifs de ce projet.

    La nouvelle implémentation devra relever comme principal défi la mise au point d’une modularité sans un mode « module » distinct comme c’est le cas avec la version actuelle (qui a été la source de plusieurs incompatibilités), ceci sans faire de résolution de dépendances (caractéristique offerte par des outils comme Maven, Ivy ou Gradle).

    Les principales décisions de conception porteront également sur la mise sur pied d’un système de modules statiques (comme Maven) ou dynamiques (comme OGSI), la représentation des métadonnées des dépendances dans des fichiers et la nécessité d’utiliser des dépendances déclaratives (comme Maven).

    Le nouveau projet est basé sur un clone de l’actuel Jigsaw implémenté dans Java 8. Toutes les décisions de conception peuvent encore être changées pendant le processus de développement.


    Source : message de Mark Reinhold


    Et vous ?

    Que pensez-vous du projet Jigsaw et des multiples problèmes rencontrés avec celui-ci ?
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

  2. #2
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 170
    Points
    2 170

    Par défaut

    Il leur aura fallu plus de 5 ans pour réaliser que leur proposition n'était pas viable. Ca commence à ressembler à l'Arlésienne...

  3. #3
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 894
    Points : 7 208
    Points
    7 208

    Par défaut

    Sans la modularisation de la JVM, je ne vois aucun intérêt à Jigsaw, sauf peut-être la visibilité inter-package (si elle est maintenue). Reste tout de même à voir à quoi ca va ressembler au final.
    D'ailleurs il y a une description du fonctionnement de ce "nouveau" Jigsaw ?


    Je me demande quand ils auront le courage de couper la rétrocompatibilité. A la publication de chaque version majeure (voir mineure), on croise les doigts pour qu'il y ait un minimum d'impact sur nos codes.
    Au pire ils pourraient essayer de se limiter à deux version antérieures. Vu le rythme des publications, ca permettrait d'introduire quelques modifications dans le bytecode (et autres) pour avoir un support minimaliste des futures fonctionnalités.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  4. #4
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 415
    Points
    7 415

    Par défaut

    Cela me conforte qu'on aurait bien plus besoin d'un java 2 incompatible que d'un java 1.8, 1.9, 1.250. C'est vraiment affligeant d'entendre que l'on est coincé avec jigsaw à cause de quelques packages en peau de casserole, enfin ça montre aussi que le JDK lui même est sacrément emmêlé. J'ai peur qu'on se retrouve avec un maven au rabais 6 ans après, la modularité et les dépendances sont un important problème dans les projets java qui mériterait une vraie solution plutôt qu'un compromis.

  5. #5
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 257
    Points : 3 433
    Points
    3 433
    Billets dans le blog
    12

    Par défaut

    Citation Envoyé par _skip Voir le message
    mériterait une vraie solution plutôt qu'un compromis.
    Le backward compatibility force à créer des compromis en Java. Les annotations qui disparaissent après compilation, de même que pour les generics qui disparaissent et laissent place à un cast d'Object, les syntaxes sucrées pour le try-with-ressources et lambdas...
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  6. #6
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 415
    Points
    7 415

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    Le backward compatibility force à créer des compromis en Java. Les annotations qui disparaissent après compilation, de même que pour les generics qui disparaissent et laissent place à un cast d'Object, les syntaxes sucrées pour le try-with-ressources et lambdas...
    Je sais bien, et c'est pour cela que je pense de plus en plus qu'un java 2 serait une solution alléchante. Pas forcément pour les gros comptes du JCP dont le seul but est de sécuriser leurs propres investissements mais pour les nouveaux projets.
    Cette backward compatibility au nom de laquelle on a tant sacrifié, je ne suis pas sûr qu'on l'ait vraiment toujours dans la pratique.

  7. #7
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 932
    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 932
    Points : 22 982
    Points
    22 982
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    Les annotations qui disparaissent après compilation,
    Les annotations ne disparaissent pas après la compilation.
    Par défaut elles sont bien stockées dans le fichier *.class, mais inaccessible via l'API de reflection. Cela permet de les utiliser dans les outils de manipulation de classes.

    Mais on peut changer ce comportement pour via l'annotation @Retention


    Citation Envoyé par Gugelhupf Voir le message
    les syntaxes sucrées pour le try-with-ressources et lambdas...
    Les lambdas ne sont pas tout à fait du sucre syntaxique.
    Cela implique pas mal de changement au niveau de la JVM...

    Mais sinon je ne vois pas le mal à utiliser du sucre syntaxique.
    Quel problème y-a-t-il avec cela pour le try-with-ressources ??? Je n'en vois aucun !



    Citation Envoyé par Gugelhupf Voir le message
    Le backward compatibility force à créer des compromis en Java.
    En même temps cela force à réellement à l'impact d'une fonctionnalité, et d'en mesurer chaque aspect avant de les implémenter.

    Les Generics sont perdus à la compilation, mais offre à 95% les mêmes fonctionnalités tout en permettant une rétrocompatibilité avec le code existant.
    Je doute que la migration existante aurait été si rapide si la totalité des librairies utilisant l'API de Collection serait devenu obsolète...



    Perso, pour avoir suivi quelques discussions sur les mailing-lists du projet "Coins" ou sur les lambda, j'ai été surpris de voir les réflexions prise en compte avant l'intégration d'une features, en particulier sur les impacts et implications que cela pourrait apporter.


    Après l'évolution du langage peut sembler plus lente par rapport à .NET par exemple, mais personnellement elle me semble aussi plus réfléchi par certains points...


    a++

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

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

    Informations forums :
    Inscription : avril 2007
    Messages : 25 461
    Points : 48 730
    Points
    48 730

    Par défaut

    Citation Envoyé par _skip Voir le message
    Je sais bien, et c'est pour cela que je pense de plus en plus qu'un java 2 serait une solution alléchante. Pas forcément pour les gros comptes du JCP dont le seul but est de sécuriser leurs propres investissements mais pour les nouveaux projets.
    Même les nouveaux projet ont besoin de la compatibilité. Aujourd'hui, rares sont les projets qui ne réutilisent pas spring, hibernate, quartz, apache commons et d'autres librairies, open source ou closed source. Si tu refuse la compatibilité avec l'existant, tu peux presque être sur que ta techno ne sera pas adoptées facilement. Et si tu ne me crois pas, regarde javafx. Sur papier, c'est génial. Mise à jour automatique de l'interface en fonction des données, composants graphiques et démos magnifique. Mais concrètement, pour le java fx 1, tu ne pouvais pas incorporer de code java, fallait tout recoder. Résultat, j'attends toujours de voir de belles applications desktop en javafx. Les gens préfèrent se baser sur netbeans ou eclipse RCP, apache pivot ou simplement swing. Il sacrifient les belles interface pour pouvoir utiliser les outils existants.

  9. #9
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 415
    Points
    7 415

    Par défaut

    Citation Envoyé par tchize_ Voir le message
    Même les nouveaux projet ont besoin de la compatibilité. Aujourd'hui, rares sont les projets qui ne réutilisent pas spring, hibernate, quartz, apache commons et d'autres librairies, open source ou closed source. Si tu refuse la compatibilité avec l'existant, tu peux presque être sur que ta techno ne sera pas adoptées facilement. Et si tu ne me crois pas, regarde javafx. Sur papier, c'est génial. Mise à jour automatique de l'interface en fonction des données, composants graphiques et démos magnifique. Mais concrètement, pour le java fx 1, tu ne pouvais pas incorporer de code java, fallait tout recoder. Résultat, j'attends toujours de voir de belles applications desktop en javafx. Les gens préfèrent se baser sur netbeans ou eclipse RCP, apache pivot ou simplement swing. Il sacrifient les belles interface pour pouvoir utiliser les outils existants.
    Alors ça c'est clair... Mais je pense que ça fonctionnerait justement parce que ça s'appelle java et que les grands frameworks s'empresseraient de s'aligner.

    Cependant il y a, je pense, pas besoin d'aller aussi loin. Si tu regardes du côté de ceylon, ils ont une modularité au niveau langage (pas pour le JDK hein, ça c'est un gros module) et des reified generic (au sens ou les types sont dispos au runtime) et ça tourne sur la JVM et l'interop avec les librairies pur java est possible.
    C'est pas source compatible en revanche puisque c'est un autre compilateur. Donc je me dis que si un langage pour la JVM arrive quasiment à avoir les features demandées sans toucher au code de la JVM (bon c'est pas *TOUS* les éléments prévus par jigsaw mais déjà assez pour tacler une bonne série de problèmes) je vois pas pourquoi un Java 2 avec un JDK 2 ne le pourrait pas.

    La backward compatibility, tu l'as au niveau de la source, en revanche avec le paquet de services J2EE qui exigent une JVM spécifique pour fonctionner normalement, je suis pas sûr qu'on l'ait à 100%.

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

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

    Informations forums :
    Inscription : avril 2007
    Messages : 25 461
    Points : 48 730
    Points
    48 730

    Par défaut

    Citation Envoyé par _skip Voir le message
    Alors ça c'est clair... Mais je pense que ça fonctionnerait justement parce que ça s'appelle java et que les grands frameworks s'empresseraient de s'aligner.
    Je n'ai pas vu beaucoup de grand framework s'aligner sur javafx....

    Jeter pour recommencer de 0 c'est une décision de programmeur, parce que, qu'on le veuille ou non, c'estp lus facile d'écrire du code que de lire le code qu'un autre à écrit. Ce n'est pas une décision rationnelle d'un point de vue maintenance et fiabilité.

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

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

    Informations forums :
    Inscription : avril 2007
    Messages : 25 461
    Points : 48 730
    Points
    48 730

    Par défaut

    Citation Envoyé par _skip Voir le message
    et ça tourne sur la JVM et l'interop avec les librairies pur java est possible.
    C'est pas source compatible en revanche puisque c'est un autre compilateur.
    On a jamais dit que ça devait être 100% source compatible, pour autant que tu puisse zapper d'un compilo 7 à 8 et vice versa suivant le type de code que tu veux compiler. Java a rajouté des mots clés (enum par exemple) ce qui empeche certaisn vieux codes de compiler sous java 5 sans être remaniées. Ce n'est pas possible de compiler un code avec des generics sous java 4. Ce qu'il faut c'est une compatibilité binaire. Ce que tu décrit, c'est exactement ce que tu refuse plus haut: quelque chose de compatible. Je ne comprend pas trop ta logique :/

  12. #12
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 932
    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 932
    Points : 22 982
    Points
    22 982
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par _skip Voir le message
    Cependant il y a, je pense, pas besoin d'aller aussi loin. Si tu regardes du côté de ceylon, ils ont une modularité au niveau langage (pas pour le JDK hein, ça c'est un gros module) et des reified generic (au sens ou les types sont dispos au runtime) et ça tourne sur la JVM et l'interop avec les librairies pur java est possible.
    Il y a des choses qui sont plus facile à faire sur un nouveau langage que sur un langage qui a plus de 15 ans...

    Le gros problème de la modularité, c'est justement les APIs standards.
    Si elle ne sont pas bien "séparé" cela ne servira à rien. D'ailleurs il y a déjà eu un gros travail de ce coté là dans Java 8.




    Sinon franchement : vous avez souvent été gêné par la non-réification des Generics ?


    a++

  13. #13
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 257
    Points : 3 433
    Points
    3 433
    Billets dans le blog
    12

    Par défaut

    @adiguba
    Les lambdas ne sont pas tout à fait du sucre syntaxique.
    Lambda -> On dirait du sucre syntaxique pour les classes Anonyme
    Moi je ne suis pas contre du tout contre la sucre syntaxique. Le try-with-ressources c'est bien, j’inciterais même les utilisateurs à migrer vers Java 7 pour utiliser cette syntaxe.

    Les Generics sont perdus à la compilation, mais offre à 95% les mêmes fonctionnalités
    C'est justement à ce niveau là qu'il y a des compris... où sont passé les 5 autres pourcents ? L'impossibilité de créer ou d'instancier des tableaux génériques par exemple.


    En fait, en entreprise, je me suis rendu compte que les décideurs étaient très frileux de migrer d'une version à une autre de Java ("Java 7 est sorti il y a un an ? Ben tiens on va migrer à Java 6"). Mais au fond ça ne sert à rien de s'inquiéter car j'ai l'impression qu'un bytecode Java 7 pourrait fonctionner avec un environnement Java 1.4 (ou antérieur)
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  14. #14
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 932
    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 932
    Points : 22 982
    Points
    22 982
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    Lambda -> On dirait du sucre syntaxique pour les classes Anonyme
    Justement non ce n'est pas du sucre syntaxique, puisque cela ne crée pas une classe anonyme.
    En fait cela crée une méthode private, qui sera appelé avec les bons paramètres via l’invocation dynamique de Java 7...


    Citation Envoyé par Gugelhupf Voir le message
    C'est justement à ce niveau là qu'il y a des compris... où sont passé les 5 autres pourcents ? L'impossibilité de créer ou d'instancier des tableaux génériques par exemple.
    Ca fait partie des limitations en effet. Mais est-ce vraiment aussi problématique ?

    Pour simplement pouvoir faire new T[] ou new T() plus simplement ils auraient dû casser toute la rétrocompatibilité et remplacer toutes les APIs existantes par des nouvelles ?

    Sans compter l'occupation mémoire supplémentaire lié à la duplication de code que cela implique...


    Citation Envoyé par Gugelhupf Voir le message
    En fait, en entreprise, je me suis rendu compte que les décideurs étaient très frileux de migrer d'une version à une autre de Java ("Java 7 est sorti il y a un an ? Ben tiens on va migrer à Java 6"). Mais au fond ça ne sert à rien de s'inquiéter car j'ai l'impression qu'un bytecode Java 7 pourrait fonctionner avec un environnement Java 1.4 (ou antérieur)
    Alors imagine un peu ce que cela aurait été si toutes les librairies utilisant l'API de Collections avaient étés pointés du doigts du jour au lendemain...


    C'est ce qui s'est passé avec les Generics de C#, qui a proposé une nouvelle API de Collections (mais comme le langage était plus jeune, du coup c'était moins problématique)


    a++

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

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

    Informations forums :
    Inscription : avril 2007
    Messages : 25 461
    Points : 48 730
    Points
    48 730

    Par défaut

    Citation Envoyé par adiGuba Voir le message
    Sans compter l'occupation mémoire supplémentaire lié à la duplication de code que cela implique...
    Ca aurait été un catastrophe. On a déjà sur les grosse appli des classloader bien chargés, imaginer cela fois 3 ou 4 à cause des generics, ça m'aurais fait peur

    Les generics sur les tableau: depuis que java 5 est sorti : 1 fois ça m'a posé problème, une fois en 9 an j'ai été coincé par le language..... C'est fou, c'est inadmissible (que d'autres languages ne soient pas aussi stables)

  16. #16
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 257
    Points : 3 433
    Points
    3 433
    Billets dans le blog
    12

    Par défaut

    Citation Envoyé par adiGuba Voir le message
    Ca fait partie des limitations en effet. Mais est-ce vraiment aussi problématique ?

    Pour simplement pouvoir faire new T[] ou new T() plus simplement ils auraient dû casser toute la rétrocompatibilité et remplacer toutes les APIs existantes par des nouvelles ?
    Pour faire new T() il faudrait utiliser les templates comme en C++ (mais le bytecode deviendrait alors plus lourd).

    Ce n'est pas catastrophique non plus, mais à cause de ces compromis il n'est pas possible de déclarer un tableau générique : T[] t = new T[10];
    ... chose qui ne fait qu'indiquer que c'est un tableau d'une seule dimension avec 10 emplacements.

    Ou bien encore, impossible de surcharger une méthode utilisant la généricité :
    void methode(ArrayList<Foo> liste) { }
    void methode(ArrayList<Toto> liste){ }
    // Impossible, "existe déjà"


    Ou bien encore : ArrayList<Integer>[] list = new ArrayList<Integer>[10];
    Et non il faut faire : ArrayList<Integer>[] list = new ArrayList[10];

    Choses qui sont par exemple possible en C#, mais ce n'est pas le sujet. Et pour finir le cast est théoriquement couteux.

    Plus haut j'avais dis que les entreprises étaient très frileuses lorsqu'il s'agissait d'effectuer migration, pourtant Java est backward compatible, donc autant en profiter pour casser la compatibilité et donner raison à leur frilosité. De toute façon à un moment donné il faudra la casser, c'est ce qui est arrivé en C# comme tu le dis, en Python 2.x à 3 et avec jQuery 1.X à 2
    De plus ça permettrait surement d'ajouter des features sympas comme le mot-clé yield ou bien un équivalent d'SQL-92 (vas y Oracle ! ) comme LINQ.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  17. #17
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 932
    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 932
    Points : 22 982
    Points
    22 982
    Billets dans le blog
    1

    Par défaut

    @Gugelhupf : les tableaux sont dangereux car ils fonctionnent de la manière inverse des Generics : le code n'est pas typesafe à la compilation.
    Toutes les vérifications sont effectuées à l'exécution, ce qui peut entrainer toutes sortes d'erreurs, contrairement aux Generics qui garantissent un code typesafe à partir du moment où la compilation passe sans erreur ni warning !

    Mais dans tous les cas à la place d'un tableau la solution est d'utiliser une ArrayList<T>.

    C'est drôle parce que d'un coté tu parles de casser la rétrocompatibilité, mais de l'autre tu t'accroches à vouloir utiliser des tableaux à tout prix !
    Qu'aurais-tu dis si Java 5.0 aurait utiliser des Generics incompatible qui supprimait l'usage des tableaux ???




    Quand au problème de surcharge, oui c'est vrai. Mais encore une fois est-ce un si gros problème que cela ?
    On peut toujours renommer la méthode si la présence de deux méthodes est vraiment obligatoire.




    Bref je trouve que c'est vraiment du chipotage pour peu de chose.
    A mes yeux la rétrocompatibilité est bien plus importante que ces détails...






    Citation Envoyé par Gugelhupf Voir le message
    Et pour finir le cast est théoriquement couteux.
    Théoriquement... En pratique je doute que ce soit vraiment le cas.




    Citation Envoyé par Gugelhupf Voir le message
    Plus haut j'avais dis que les entreprises étaient très frileuses lorsqu'il s'agissait d'effectuer migration, pourtant Java est backward compatible, donc autant en profiter pour casser la compatibilité et donner raison à leur frilosité.
    Comme çà au lieu d'être simplement frileuses, les entreprises ne migreront pas du tout !

    • Avec une retrocompatibilité tu peux migrer l'existant relativement facilement (car il faut malgré tout quand même tester et valider la migration).
      Ensuite tu peux utiliser les nouvelles fonctionnalités dans le "nouveau" code, et/ou faire évoluer le code existant petit à petit.
    • Sans rétrocompatibilité, tu dois retravailler tout le code existant pour l'adapter et le migrer vers la nouvelle plateforme, avant de tester et valider la migration. Selon les changements apportées cela peut être un très gros travail qui demandera beaucoup de temps... qui impactera l'évolution des applications.



    Perso lorsqu'on est passé de Java 1.4 à Java 5.0, on a eu un gros boulot pour migrer toutes nos collections vers les Generics.
    Ce fut un long travail mais il a été possible petit à petit car on a pu migrer l'application AVANT, et que la modif restait compatible.
    Cela aurait été beaucoup plus long si on devait changer d'API... au risque de rester sur les anciennes... voir sur du Java 1.4 tout court !


    Citation Envoyé par Gugelhupf Voir le message
    De toute façon à un moment donné il faudra la casser, c'est ce qui est arrivé en C# comme tu le dis, en Python 2.x à 3 et avec jQuery 1.X à 2
    De plus ça permettrait surement d'ajouter des features sympas comme le mot-clé yield ou bien un équivalent d'SQL-92 (vas y Oracle ! ) comme LINQ.
    L'ajout de fonctionnalité ne passe pas obligatoirement par des incompatibilités.

    Et pour le coup le mot-clef "yield" correspond vraiment à du sucre syntaxique, puisque cela va générer un itérateur correspondant au code de la méthode...

    Perso si on doit vraiment casser Java, ce serait avant tout pour lui corriger certaines de ces erreurs de jeunesses (comme les méthodes de synchronisation notify()/wait() dans la classe Object !)




    a++

  18. #18
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 257
    Points : 3 433
    Points
    3 433
    Billets dans le blog
    12

    Par défaut

    Citation Envoyé par adiGuba Voir le message
    @Gugelhupf : les tableaux sont dangereux car ils fonctionnent de la manière inverse des Generics : le code n'est pas typesafe à la compilation.
    Toutes les vérifications sont effectuées à l'exécution, ce qui peut entrainer toutes sortes d'erreurs, contrairement aux Generics qui garantissent un code typesafe à partir du moment où la compilation passe sans erreur ni warning !

    Mais dans tous les cas à la place d'un tableau la solution est d'utiliser une ArrayList<T>.
    Et si j'utilise get(int index) pour une liste, ce n'est pas aussi dangereux qu'un tableau ?

    Les tableaux et les listes génériques peuvent cohabiter. Théoriquement un tableau c'est pour des emplacements de taille fixe, et les listes pour des emplacements de taille dynamique. Et puis même si avec une ArrayList<T> on peut faire tout ce qu'on a besoin de faire avec un tableau, il ne pourrait pas y avoir d'ArrayList<T> sans tableau...


    EDIT : En fait je dis une bêtise pour la méthode get(int index), l'objet List doit surement avoir un attribut indiquant une intervalle de valeur possible.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  19. #19
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 932
    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 932
    Points : 22 982
    Points
    22 982
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    Et si j'utilise get(int index) pour une liste, ce n'est pas aussi dangereux qu'un tableau ?
    C'est l'implémentation d'ArrayList qui t'assure que le code sera typesafe

    Tout ce que tu peux avoir avec get() c'est une erreur d'index, mais là on sort des problèmes de type et donc des Generics...

    Citation Envoyé par Gugelhupf Voir le message
    Les tableaux et les listes génériques peuvent cohabiter.
    Ca dépend.
    Tu peux très bien le faire avec quelques précautions, mais il reste que le code utilisant des tableaux n'est pas typesafe (c'est à dire que le compilateur ne pourra pas assurer qu'il compilera sans erreur).

    Par exemple le code suivant compilera très bien avec les tableaux, mais génèrera une exception à l'exécution :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    	Double[] doubleArray = new Double[10];
    	Number[] numberArray = doubleArray; // OK
    	numberArray[0] = new Integer(0); // ArrayStoreException
    Hors l'objectif des Generics est de supprimer toutes ces erreurs à l'exécution, et de les détecter dès la compilation.
    Si un code utilisant des Generics compile sans erreurs ni warnings, alors le compilateur t'assure que tu es sûr de ne pas obtenir d'erreur de typeage à l'exécution (sur le code Generics en tout cas).

    Ce qu'il est impossible de faire avec les tableaux !
    Les tableaux Java ne sont pas sûr du fait de leurs fonctionnement...


    Pour info le code équivalent avec les Generics et les List<T> génère une erreur dès la compilation :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    	List<Double> doubleList = new ArrayList<>();
    	List<Number> numberList = doubleList; // ERROR
    	numberList.add(new Integer(0));




    Alors c'est vrai que des Generics "reified" aurait permis des tableaux de types Generics... mais cela n'aurait rien changer au fait que cela soit un code non-typesafe (et donc à l'encontre même du principe des Generics).





    Citation Envoyé par Gugelhupf Voir le message
    Théoriquement un tableau c'est pour des emplacements de taille fixe, et les listes pour des emplacements de taille dynamique. Et puis même si avec une ArrayList<T> on peut faire tout ce qu'on a besoin de faire avec un tableau, il ne pourrait pas y avoir d'ArrayList<T> sans tableau...
    Les tableaux sont avant tout une facilité du langage, mais à utiliser avec précaution du fait des problèmes qu'il peuvent générer...


    Et justement si c'était à refaire et qu'on puisse avoir un Java incompatible, je verrais bien les tableaux disparaitre au profit d'une éventuelle classe Array<T>...


    a++

  20. #20
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 257
    Points : 3 433
    Points
    3 433
    Billets dans le blog
    12

    Par défaut

    Ah oui en effet, après avoir vu ces exemples je comprends mieux... mais comme dit plus haut, au niveau de l'implémentation, les ArrayList (il me semble) se servent des tableaux. Il y aura toujours des tableaux, c'est un moyen d'optimiser le tri.

    Et justement si c'était à refaire et qu'on puisse avoir un Java incompatible, je verrais bien les tableaux disparaitre au profit d'une éventuelle classe Array<T>...
    Comme en C++11 (mais les tableaux existent toujours).
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

Discussions similaires

  1. Java : Oracle adopte une nouvelle nomenclature pour les mises à jour du JDK
    Par Cedric Chevalier dans le forum Général Java
    Réponses: 8
    Dernier message: 20/05/2013, 18h58
  2. Réponses: 2
    Dernier message: 03/11/2010, 00h38
  3. Nordea lance une nouvelle application iPhone pour ses fonds
    Par Mejdi20 dans le forum Communiqués
    Réponses: 0
    Dernier message: 11/10/2010, 23h27
  4. Réponses: 0
    Dernier message: 03/05/2010, 15h58
  5. Réponses: 0
    Dernier message: 20/04/2010, 11h53

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