Les avertissements d'affichage du compilateur si vous utilisez les classes Java propriétaires de Sun. Je suis d'avis que c'est généralement une mauvaise idée d'utiliser ces classes. J'ai lu ça quelque part. Cependant, mis à part les avertissements, y a-t-il des raisons fondamentales pour lesquelles vous ne devriez pas les utiliser?C'est une mauvaise pratique d'utiliser les classes Java propriétaires de Sun.
Parce qu'ils sont des API internes: ils sont sujets à changement dans un sans papier ou non pris en charge chemin et ils sont liés à un environnement JRE/JDK spécifique (Sun dans votre cas), ce qui limite la portabilité de vos programmes. Essayez d'éviter les utilisations de ces API, préférez toujours une classe publique documentée et spécifiée.
Certaines API sous 'com.sun. *' Sont expérimentales (l'API APT originale était par exemple). IIRC, Alex Buckley a un blog sur les différents statuts de ces API. Mais oui, en général, ils peuvent changer ou disparaître dans les mises à jour et entre les fournisseurs. –
J'ai mis mon éditeur java (IntelliJ Idea) pour exclure com.sun des suggestions intellisense. Merci pour votre suggestion. – skiabox
Oui, car personne ne garantit que ces classes ou API seront les mêmes avec la prochaine version de Java et je parie qu'il n'est pas garanti que ces classes soient disponibles dans les versions Java d'autres fournisseurs. Vous associez donc votre code à une version Java spéciale et perdez au moins la portabilité.
Les classes Java propriétaires de Sun font partie de leur implémentation Java qui ne fait pas partie de l'API Java. Leur utilisation est non documentée et non prise en charge. Puisqu'ils sont internes, ils peuvent être modifiés à tout moment pour n'importe quelle raison que l'équipe travaillant à la JVM Sun décide. De plus, l'implémentation Java de Sun n'est pas la seule disponible! Votre code ne serait pas portable aux JVM d'autres fournisseurs comme Oracle/BEA et IBM.
Essayez d'exécuter votre code avec une machine virtuelle Java non-Soleil et voir ce qui se passe ...
(Votre code échouera avec une exception ClassNotFound)
J'ai eu récemment un cas qui a montré un monde réel problème que vous pouvez rencontrer quand vous utilisez ces classes: nous avions du code qui ne compilerait pas car une méthode qu'il utilisait sur un sun. * La classe n'existait tout simplement pas dans OpenJDK sous Ubuntu. Donc, je suppose que lorsque vous utilisez ces classes, vous ne pouvez plus dire des choses comme «cela fonctionne avec Java 5», car cela ne fonctionnera que sur une certaine implémentation Java.
Je peux fortement recommander d'exécuter vos unittets sur une plate-forme et une JVM différentes de celles que vous utilisez pour le développement. Beaucoup de choses intéressantes ont tendance à apparaître. –
Le JDK 6 Documentation inclut un lien intitulé Note About sun.* Packages. Ceci est un document de la Java 1.2 docs, donc des références à sun.* doivent être traitées comme si elles ont dit com.sun.*
Les points les plus importants de ce sont:
Les classes Sun comprend le Java 2 SDK, Standard Edition, tombent dans les groupes
java.*,javax.*,org.*etsun.*. Tous les packages saufsun.*sont une partie standard de la plate-forme Java et seront pris en charge dans le futur. En général, les emballages tels quesun.*, qui sont en dehors de la plate-forme Java , peut être différente selon les plates-formes OS (Solaris, Windows, Linux, Macintosh, etc.) et peuvent changer à tout moment sans préavis avec les versions SDK (1.2, 1.2.1, 1.2.3, etc.).Les programmes qui contiennent des appels directs aux packagessun.*ne sont pas 100% Java pur.
et
Chaque entreprise qui implémente la plate-forme Java fera à leur manière privée . Les classes sont
sun.*présentes dans le SDK pour soutenir la mise en œuvre Sun de la plate-forme Java: lessun.*classes sont ce que font les classes Java de la plate-forme de travail « sous les couvertures » pour le SDK Sun Java 2. Ces classes ne seront généralement pas présentes sur la plate-forme Java d'un autre fournisseur. Si votre programme Java demande une classe "sun.package.Foo" par son nom, il peut échouer avec ClassNotFoundError, et vous aurez perdu un avantage majeur de en Java.
Comme un commentaire "plusieurs années plus tard": Il n'y a aucune garantie que 'com.sun. *' Ne changera pas en 'com.oracle. *' Puisque Sun n'existe plus. – Powerlord
Ce n'est pas correct. De nombreux paquets 'com.sun. *' Font partie de la spécification documentée. Il serait impossible d'écrire du code JNDI LDAP ou COSNaming sans eux. Le problème concerne les paquets 'sun. *', Qui sont tout à fait différents et spécifiquement documentés en tant que tels. – EJP
btw, en essayant d'utiliser les classes 'sun. *' Et 'com.sun. *' Échoueront spectaculairement sur Java 9. – Powerlord
Voici la réponse d'Oracle: Why Developers Should Not Write Programs That Call 'sun' Packages
Bien que cela puisse théoriquement répondre à la question, [il serait préférable] (http: // méta. stackexchange.com/q/8259) pour inclure les parties essentielles de la réponse ici, et fournir le lien pour référence. – BoltClock
Toute fonctionnalité qui est suffisamment générale sera incarnée dans l'API Java officielle. Est-ce qu'il y a vraiment quelque chose dans les classes Sun dont vous avez besoin et que vous ne pouvez pas faire avec l'API Java standard? Pouvez-vous donner un exemple? –
(Je me suis parfois pris en utilisant les xerces internes pour le traitement xml) –
Bien xerces est l'implémentation XML par défaut lors du traitement XML en utilisant JAXP. Il n'est pas nécessaire d'utiliser directement les xerces. –