Suppression de classes sun.misc dans la version 8 de Java,
Le nettoyage continue

Le , par olivier.pitton, Membre émérite
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.* ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Grom61736 Grom61736 - Membre éprouvé http://www.developpez.com
le 10/09/2013 à 17:40
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)
Avatar de olivier.pitton olivier.pitton - Membre émérite http://www.developpez.com
le 10/09/2013 à 19:09
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.
Avatar de Gugelhupf Gugelhupf - Modérateur http://www.developpez.com
le 11/09/2013 à 10:21
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 ).
Avatar de lunatix lunatix - Rédacteur http://www.developpez.com
le 11/09/2013 à 12:04
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
Avatar de gangsoleil gangsoleil - Modérateur http://www.developpez.com
le 12/09/2013 à 14:50
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...
Avatar de _skip _skip - Expert éminent http://www.developpez.com
le 16/09/2013 à 23:53
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.
Avatar de Logan Mauzaize Logan Mauzaize - Rédacteur/Modérateur http://www.developpez.com
le 19/09/2013 à 19:54
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.
Offres d'emploi IT
DESSINATEUR INDUSTRIEL (H/F)
AGENCE SUPPLAY - Poitou Charentes - Châtellerault (86100)
Technico Commercial
Imerys SA - Centre - Orleans
Ingénieur Etudes et Développement Confirmé .net H/F
Talan - Ile de France - Paris (75008)

Voir plus d'offres Voir la carte des offres IT
Responsables bénévoles de la rubrique Java : Mickael Baron - Robin56 -