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

  1. #1
    Membre émérite
    Avatar de olivier.pitton
    Homme Profil pro
    Développeur Java
    Inscrit en
    juin 2012
    Messages
    355
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2012
    Messages : 355
    Points : 2 953
    Points
    2 953
    Par défaut Suppression de classes sun.misc dans la version 8 de Java
    Suppression de classes sun.misc dans la version 8 de Java
    Le nettoyage continue


    Après la suppression de la méthode Reflection.getCallerClass, le nettoyage de classes et de méthodes dans le JDK 8 continue. Aujourd'hui, c'est l'interface sun.misc.Compare et la classe sun.misc.Sort qui sont supprimées (code review ici).

    L'interface sun.misc.Compare offre une méthode de comparaison d'objets, prenant deux Object et renvoyant un int, possédant une signature très proche de l'interface java.util.Comparator. La classe sun.misc.Sort permet de trier un tableau passé en argument avec l'algorithme quicksort.

    Mais pourquoi une telle suppression ?
    Les développeurs du projet ont tout d'abord pensé à les mettre en @Deprecated, mais ont finalement statué qu'elles devaient être supprimées. La discussion complète autour de la suppression se trouve ici. Il faut dire qu'il y a un bogue important, de priorité 4, concernant la suppression de classes inutiles, puisque facilement remplaçables comme les deux présentées ici.

    Les utilisateurs de sun.misc.Compare peuvent se tourner vers java.util.Comparator et ceux de sun.misc.Sort vers la méthode Arrays.sort.

    Enfin, un nouvel utilitaire appelé jdeps arrive avec le JDK 8. Celui-ci permettra d'aider les développeurs à comprendre les dépendances statiques dans leurs projets et à identifier les usages des API non standards et internes au JDK, en tant que complément des warnings du compilateur. Vous trouverez le post associé à cet outil ici.

    Il faut bien se rappeler que les classes définies dans les package sun.* sont internes à Oracle, ne sont pas portables entre les JVM et ne devraient pas être utilisées de manière publiques dans les applications.

    Source :InfoQ

    Et vous ?
    Pensez-vous qu'Oracle peut se permettre de supprimer des méthodes aussi facilement ? Saviez-vous qu'il ne fallait pas utiliser directement les API sun.* ?

  2. #2
    Membre éprouvé Avatar de Grom61736
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2013
    Messages
    169
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Finance

    Informations forums :
    Inscription : février 2013
    Messages : 169
    Points : 1 147
    Points
    1 147
    Par défaut
    Citation Envoyé par olivier.pitton Voir le message
    Pensez-vous qu'Oracle peut se permettre de supprimer des méthodes aussi facilement ?
    Je pense que oui, maintenant des gens crieront crieront peut-être au scandale en disant que c'est des bout de sun qui disparaissent de plus en plus et qu'Oracle c'est pas bien etc. Maintenant, en IT plus qu'ailleurs faut se mettre à jour.

    Citation Envoyé par olivier.pitton Voir le message
    Saviez-vous qu'il ne fallait pas utiliser directement les APIs sun.* ?
    Oui, grace au warning à la compilation. (comme dit dans l'actu en lien)

  3. #3
    Membre émérite
    Avatar de olivier.pitton
    Homme Profil pro
    Développeur Java
    Inscrit en
    juin 2012
    Messages
    355
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2012
    Messages : 355
    Points : 2 953
    Points
    2 953
    Par défaut
    Surtout que les classes supprimées sont dupliquées comme je l'ai dit. Il devrait arriver de même à sun.misc.Service à cause de java.util.ServiceLoader.

  4. #4
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 291
    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 291
    Points : 3 543
    Points
    3 543
    Billets dans le blog
    12
    Par défaut
    Bien que très limité, il y a des sun.* qui restent utiles.
    Je pense notamment à sun.audio.*, et la connexion à une base Access (sun.jdbc.odbc.JdbcOdbcDriver) dont j'ai déjà eu à me servir.

    Limité pourquoi ?
    • Déjà pour accéder à une base Access il faut être sous Windows et avoir le JDK 32bits. Il existe des bridges oui, mais ceux que j'ai essayés n'étaient pas de bonne qualité.
    • Pour la manipulation de son j'ai aussi rencontré des problèmes "bas niveau" avec des messages d'erreurs liés à little/big endian sous certaines machines. Le format et poids de fichier à lire est très limité. Et puis de toute façon dès que ça touche un peu au matériel, Java n'aime pas ça (liaison RS232 avec javacomm ou la lib RXTX par exemple ).
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  5. #5
    Rédacteur
    Avatar de lunatix
    Homme Profil pro
    Architecte technique
    Inscrit en
    novembre 2002
    Messages
    1 959
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : novembre 2002
    Messages : 1 959
    Points : 3 665
    Points
    3 665
    Par défaut
    a un moment ils le faisaient sur les updates du jdk7, et ca c'etait limite.

    sur le jdk8 : oui, le cleaning de ces classes est une tres bonne idée

  6. #6
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    mai 2004
    Messages
    9 882
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : mai 2004
    Messages : 9 882
    Points : 26 955
    Points
    26 955
    Par défaut
    Et dire qu'a chaque fois que je dis que Java n'est pas backward compatible, on me lynche...

    Peut-etre que cette fois-ci les gens vont commencer a se demander s'il est raisonnable de continuer avec ce langage...
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  7. #7
    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 : 37
    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 469
    Points
    7 469
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    Et dire qu'a chaque fois que je dis que Java n'est pas backward compatible, on me lynche...

    Peut-etre que cette fois-ci les gens vont commencer a se demander s'il est raisonnable de continuer avec ce langage...
    Tu veux dire qu'il serait déraisonnable de continuer à utiliser un langage dont le propriétaire supprime d'obscures classes non standardisées, non documentées dont l'usage déclenche depuis des années des warnings parfaitement clairs lors de la compilation?

    A part pour quelques cas très pointus comme ceux cités par Gugelhupf, y'a vraiment aucune raison d'utiliser directement les implémentations propriétaires de sun et ce n'est pas comme si les possibles conséquences étaient cachées. Il y a que très peu de chance pour que tu utilises ces classes sans connaître les risques.

  8. #8
    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 : 35
    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 257
    Points
    7 257
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    Et dire qu'a chaque fois que je dis que Java n'est pas backward compatible, on me lynche...

    Peut-etre que cette fois-ci les gens vont commencer a se demander s'il est raisonnable de continuer avec ce langage...
    Il ne faut pas confondre langage, API et implémentation.

    Comme dans toute technologie si tu t'appuies sur des mécanismes internes dépendant d'une implémentation, tu perds en portabilité/compatibilité.
    C'est comme si dans un source C++ tu t'appuies sur Win32 et tu voudrais être compatible Linux ...


    Le soucis c'est que certaines fonctionnalités ne sont pas exposées au niveau de l'API, tu n'as donc pas toujours le choix. Par exemple, les fonctions d'un FileSystem.

    Le tout c'est de savoir quel est le périmètre. Par exemple sur mes applis Web, je sais que je vais tourner sous une machine Red Hat 6 Enterprise avec une JVM Sun/Oracle 6u20.
    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

Discussions similaires

  1. [VB.NET] COM Class dans une version Express
    Par Jean-Philippe André dans le forum Débuter
    Réponses: 0
    Dernier message: 14/02/2012, 10h14
  2. classes SUN dans quel JAR
    Par Lolitaaa dans le forum API standards et tierces
    Réponses: 0
    Dernier message: 24/12/2009, 16h17
  3. [VB.NET] Suppression d'un fichier chargé dans un WebBrowser
    Par Vonotar dans le forum Windows Forms
    Réponses: 9
    Dernier message: 27/09/2004, 12h09
  4. Réponses: 6
    Dernier message: 04/03/2004, 10h35
  5. Réponses: 3
    Dernier message: 12/06/2002, 22h15

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