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

API standards et tierces Java Discussion :

[Java 6] JSR-270 - retrait d'API potentiel -commentaires [Débat]


Sujet :

API standards et tierces Java

  1. #1
    Rédacteur/Modérateur

    Avatar de bouye
    Homme Profil pro
    Information Technologies Specialist (Scientific Computing)
    Inscrit en
    Août 2005
    Messages
    6 900
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Information Technologies Specialist (Scientific Computing)
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : Août 2005
    Messages : 6 900
    Billets dans le blog
    54
    Par défaut [Java 6] JSR-270 - retrait d'API potentiel -commentaires
    Une mise a jour du blog de Kirill Grouchnikov sur un sujet non-lié a attiré mon attention sur cet article qui discute d'une révision de la JSR-270 : la possibilité d'avoir certaines API qui se verraient être retirées (javax.sound.midi pour ne citer qu’elle) du JRE (pas du JDK, ce que Kirill Grouchnikov remarque correctement car cela semble idiot).

    Le principe d'avoir un JRE plus léger ne me répugne pas du tout, au contraire. L’un des arguments avancé par certains vient du fait que des programmes genre Flash demandent une installation bien plus légère coté client que Java pour avoir un résultat final similaire. Et donc qu’en améliorant "l’expérience utilisateur" (plus rapide et moins d’étapes) lors de la phase d’installation initiale on améliorerait la perception de Java (que certains utilisateurs moyens peuvent considérer comme "pénible" à installer/mettre en œuvre par rapport à d’autres technologies).
    L’idée est très bonne en soit, simplement il faudrait que Sun pense à quelques petites choses supplémentaires, histoire de faciliter la vie de ses utilisateurs, avant de se lancer dans ce genre d'actions :

    1) Rendre l'accès aux extensions plus aisé pour l’utilisateur novice ! C’était déjà le bazar auparavant (trop de sous-sites séparés tous avec des présentations différentes et des procédures d’installation différentes pour chaque extension), mais depuis que le site de Java a été redésigné c’est en fait plus difficile de trouver les sites des extensions que l’on cherche (... quand on a reussit à déterminer laquelle on cherche...).

    2) Pour l’utilisateur lambda Windows (et/ou Mac – comment faire sur Mac d’ailleurs ? Apple fournit ces extensions ?) avoir des installeurs pour la plupart de ces extensions qui copieraient les JAR et DLLs fournis dans les répertoires bin et lib/ext des JRE appropriés (public et privés -notamment si le JDK est installé en plus du JRE, reps pour le repertoire src et doc du JDK quand l'extension est fournie avec sa doc et ses sources), plutôt que de simple fichiers ZIP dont le péquin commun ne sait pas quoi faire. Bref uniformiser et bien mieux automatiser les procédures d’installation.

    3) Faire que le JRE soit capable d’aller télécharger de lui-même l’extension appropriée quand cela est nécessaire (idem pour l’installation quand un JDK est présent). Maintenant il est prévu/envisagé que dans le futur on ait un JRE allégé/minimal qui soit capable d’aller les lib requises quand nécessaire ; cela serait bien si cela fonctionnait avec toutes les extensions javax.

    4) En plus du JRE allégé, fournir au contraire une distribution du JRE complète contenant toutes les extensions* (stables) pour la plateforme choisie (JavaHelp, Beans activation Framework, JavaMail, JAI, JMF, Java3D, etc…). Par exemple dans la zone où je suis qui peut encore être considérée comme le tiers-monde d’Internet on a pas des débits rapides et on n’est pas non-plus connecté en permanence au Net ; il est plus préférable de récupérer une grosse installation en une seule fois (surtout que le JRE complet ne serait pas si gros que ca) que des tas de petits paquets séparés à droite et à gauche. Un point de téléchargement unique et centralisé est nécessaire.

    La connexion de la Nouvelle-Calédonie au reste du monde est certes lente mais stable et surtout continue (l'ile est connectée en permanence sauf problème satellitaire) et notre situation devrait s’améliorer courant l’an prochain (tirage d’un cable vers l’Australie) MAIS on ne peut pas du tout dire la même chose des autres pays/etats/archipels/iles de la région (et ca doit être similaire en Afrique et dans certains pays/régions d’Asie ou d’Amérique du Sud). => Bref au niveau connexion, le reste du monde n’est pas au niveau des USA, de l’Europe ou du Japon…

    *Je sais que le principal problème empêchant cela vient du fait que les extensions ont des cycles de développement différents et séparés des classes Core/faisant parties du JRE.

    5) Lors d’une mise-à-jour du JRE/JDK, notamment par le processus de mise-à-jour intégré, penser à importer les extensions vers la nouvelle version de la JVM (...). C’est encore le fout@!!@ à ce niveau il faut tout déplacer soi-même (en se souvenant que certaines ont des JAR mais aussi des DLLs a déplacer...). Encore une fois l’utilisateur moyen ne comprend pas grand chose à tout ceci.

    Note : d’ailleurs un jour il faudrait qu’ils changent le procéder de mise-à-jour pour que celui-ci demander à l’utilisateur s’il veut garder ou supprimer ses anciens JVM (…).

    Voilà mon avis sur les effets engendrés par cette révision de la JSR. Maintenant si Gfx pouvait donner son avis et/ou transmettre s’il trouve que je ne raconte pas trop d’âneries.
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  2. #2
    Expert éminent
    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
    Billets dans le blog
    1
    Par défaut
    Salut,


    J'en avais déjà parlé sur le blog : Java SE 6 en public review !

    Déjà il faut bien prendre en compte que cette suppression ne concernera pas Java 6 mais Java 7 ! C'est à dire que dans la JSR de Java 6 le package javax.sound.midi a été proposé à la "suppression", mais que cette dernière ne pourra être effective que dans la version suivante (Java 7).

    De plus même si le package est "supprimé", il pourra toujours faire partie intégrante du JRE (chaque constructeur sera libre de l'intégrer ou pas).


    Enfin, concernant la plupart des problèmes que tu cites, je pense qu'ils devraient être pris en compte par la JSR 277 (Java Module System), qui devra proposer un format de distribution du code en remplacement du jar, ainsi qu'un système de repository avec recherche et chargement des codes et resources...


    a++

  3. #3
    Membre Expert
    Avatar de ®om
    Profil pro
    Inscrit en
    Janvier 2005
    Messages
    2 815
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 2 815
    Par défaut
    [UTOPIQUE]
    Moi je serais pour un nettoyage complet du JDK/JRE (virer Vector, Hashtable, Enumeration, toutes les méthodes depréciées -de Date par exemple-, ainsi que de rendre tout générique -genre Swing-).
    [/UTOPIQUE]

  4. #4
    Rédacteur/Modérateur

    Avatar de bouye
    Homme Profil pro
    Information Technologies Specialist (Scientific Computing)
    Inscrit en
    Août 2005
    Messages
    6 900
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Information Technologies Specialist (Scientific Computing)
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : Août 2005
    Messages : 6 900
    Billets dans le blog
    54
    Par défaut
    Toujours sur Javadesktop, il me semblait que quelqu'un avait indique, il y a quelques temps, qu'il existait deja une implementation "genericifiee" de Swing ou du moins qu'une personne l'avait propose a Sun dans le cadre des contributions externes. Peut-etre existe-t-il d'ailleurs une JSR a ce propos pour une evaluation ou une inclusion future.

    Gfx avait deja indique pourquoi il pensait que jamais ces APIs ne seraient retirees. Enfin.. la JSR contredit un peu cela (pas completement puisqu'il ne s'agit pas d'un retrait definitif mais plutot d'absence de l'API dans le JRE)puisque meme si elles ne sont peut-etre pas legions, il doit quand meme deja exister des applications utilisant le MIDI.
    Mais meme s'il est clairement indique que le contenu des packages javax peut ne pas etre dans la JVM, combien d'entre nous on ecrit (par exemple) du code Swing en testant en premier si ce package est present ou pas ? La derniere fois que je l'ai fait moi, c'etait dans la pre-1.2 quand Swing etait encore dans un package sun...

    Donc tant que leur procedure de telechargement automatique des APIs necessaire n'est pas fonctionnnelle... la mise en application de cette JSR n'est guere viable : cela briserai la compatiblite des applications existantes.
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  5. #5
    Rédacteur/Modérateur

    Avatar de bouye
    Homme Profil pro
    Information Technologies Specialist (Scientific Computing)
    Inscrit en
    Août 2005
    Messages
    6 900
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Information Technologies Specialist (Scientific Computing)
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : Août 2005
    Messages : 6 900
    Billets dans le blog
    54
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  6. #6
    Expert éminent
    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
    Billets dans le blog
    1
    Par défaut
    Cela à l'air intérressant

    mais ce n'est pas la même chose :
    • La JSR 270 est la JSR détaillant le contenu de Java SE 6
    • La JSR 277 concerne le nouveau format d'archive (Java Module) qui devrait être inclut dans Java SE 7

    a++

  7. #7
    Rédacteur/Modérateur

    Avatar de bouye
    Homme Profil pro
    Information Technologies Specialist (Scientific Computing)
    Inscrit en
    Août 2005
    Messages
    6 900
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Information Technologies Specialist (Scientific Computing)
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : Août 2005
    Messages : 6 900
    Billets dans le blog
    54
    Par défaut
    C'est clair mais le retrait d'API via la JSR-270* implique la mise en place d'une fonctionnalite necessitant le telechargement automatique de modules pour supporter les applications existantes** utilisant ces APIs, ce qui implicitement est lie a la JSR-277 (comme tu l'as fait toi-meme remarquer).

    *le blog de Mark Reinhold parle bien de Java 6 http://blogs.sun.com/mr/entry/removing_features
    Ici aussi http://www.sdtimes.com/article/story-20060915-04.html
    So why remove the MIDI capabilities from Java SE 6? Even Reinhold is uncertain as to why this feature is not used much by Java developers. He said that the JSR 270 team was able to reach a unanimous decision only on MIDI, and that if there is a backlash, the Java SE 7 team can add the support back into the platform.
    **il y a peu quelqu'un demandait dans le forum multimedia comment generer du son MIDI ... de telles applications utilisant cette API existent meme si elles ne sont pas legions. Il va donc y avoir de la casse du cote des applications de clavier/piano/synthetiseurs virtuel, dans les lecteurs multimedia, dans certains jeux videos a la sortie de Java 6.

    Quand au retrait du support de RMI-IIOP la c'est carrement ridicule. Cela voudrait-il dire que nous aurions ete obliges de deployer JEE sur les postes clients faisant tourner des applications CORBA ??? Encore heureux que ce choix n'ait pas ete retenu...

    Encore une fois dans un monde ou theoriquement tout le monde serait connecte, avec des debits rapides, et avec un JSR-277 (ou de la JSR-291 sa concurrente) fonctionnelle et eprouvee la question ne se poserai pas. Dans le monde reel... de tels retrait (avant meme que la modularisation ne soit en place) sont assez stupides et ennuyants (avis personnel) tant pour les devellopeurs que les utilisateurs.

    Sinon une revue plus positive que les autres de la JSR-277 : http://weblogs.java.net/blog/stanley..._early_dr.html
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

Discussions similaires

  1. Erreur "login.java uses or overrides a deprecated API"
    Par nabil123456 dans le forum Interfaces Graphiques en Java
    Réponses: 1
    Dernier message: 14/05/2015, 11h02
  2. Java 8: Utilisation de la nouvelle API time
    Par bsar69 dans le forum API standards et tierces
    Réponses: 2
    Dernier message: 27/01/2014, 19h47
  3. Réponses: 12
    Dernier message: 02/12/2010, 09h22
  4. [2.2.2][Java] Signalement de bug dans l'API
    Par Stephane73 dans le forum BIRT
    Réponses: 2
    Dernier message: 23/06/2008, 09h52
  5. Réponses: 4
    Dernier message: 22/01/2004, 08h27

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