Utiliser des classes solaires internes avec javac

Existe-t-il un moyen de désactiver les ressortingctions de javac 1.6.0_22 qui m’empêchent d’utiliser des classes internes à JRE comme sun.awt.event.* ?

Je ne cherche pas :

  1. une explication pourquoi c’est interdit.
  2. suggestion d’utiliser différentes classes
  3. suggestion d’utiliser la reflection
  4. suggestion d’utiliser ecj / eclipse

Je veux juste savoir si c’est possible ou non, et si c’est alors comment.

J’ai trouvé la réponse moi-même.

Lorsque javac comstack du code, il n’est pas rt.jar par défaut à rt.jar . Au lieu de cela, il utilise le fichier de symboles spécial lib/ct.sym avec les lib/ct.sym de classes.

Étonnamment, ce fichier contient plusieurs classes de soleil internes, mais pas toutes. Dans mon cas, l’une de ces classes plus internes qu’habituelles était sun.awt.event.IgnorePaintEvent .

Et la réponse à ma question est: javac -XDignore.symbol.file

C’est ce que javac utilise pour comstackr rt.jar .

En plus de la réponse de @ marcin-wisnicki, si vous utilisez Maven, notez que le plug-in du compilateur supprimera en silence tous les indicateurs -XD , à moins que vous ne spécifiiez aussi true : par exemple

    org.apache.maven.plugins maven-comstackr-plugin 3.3  1.7 1.7  -XDignore.symbol.file  true  ... 

Normalement, cela ne produit qu’un message d’avertissement; par exemple

 [javac] /media/disk/opensso2/opensso/products/federation/openfm/source/com/sun/identity/wss/xmlsig/WSSSignatureProvider.java:46: warning: com.sun.org.apache.xpath.internal.XPathAPI is Sun proprietary API and may be removed in a future release [javac] import com.sun.org.apache.xpath.internal.XPathAPI; 

Vous avez peut-être dit au compilateur Java de traiter les avertissements comme des erreurs.

Il y a une meilleure solution. Ajoutez d’abord l’option à javac -XDenableSunApiLintControl , puis utilisez @SupressWarnings("sunapi") dans votre code.