Le remplacement de la méthode d'accès par défaut à travers différents classloaders rompt le polymorphisme

Question

Je rencontre un comportement étrange en essayant de surcharger une méthode avec accesseur par défaut (ex: void run()). Selon Java spec, une classe peut utiliser ou remplacer les membres par défaut de la classe de base si les classes appartiennent au même package. Tout fonctionne correctement lorsque toutes les classes sont chargées à partir du même chargeur de classe. Mais si j'essaie de charger une sous-classe de séparé classloader alors le polymorphisme ne fonctionne pas.

est Voici un exemple:

App.java:

import java.net.*; 
import java.lang.reflect.Method; 

public class App { 
    public static class Base { 
     void run() { 
      System.out.println("error"); 
     } 
    } 
    public static class Inside extends Base { 
     @Override 
     void run() { 
      System.out.println("ok. inside"); 
     } 
    } 
    public static void main(String[] args) throws Exception { 
     { 
      Base p = (Base) Class.forName(Inside.class.getName()).newInstance(); 
      System.out.println(p.getClass()); 
      p.run(); 
     } { 
      // path to Outside.class 
      URL[] url = { new URL("file:/home/mart/workspace6/test2/bin/") }; 
      URLClassLoader ucl = URLClassLoader.newInstance(url); 
      final Base p = (Base) ucl.loadClass("Outside").newInstance(); 
      System.out.println(p.getClass()); 
      p.run(); 
      // try reflection 
      Method m = p.getClass().getDeclaredMethod("run"); 
      m.setAccessible(true); 
      m.invoke(p); 
     } 
    } 
} 

Outside.java: devrait être dans le dossier séparé. sinon classloader sera le même

public class Outside extends App.Base { 
    @Override 
    void run() { 
     System.out.println("ok. outside"); 
    } 
} 

La sortie:

class App$Inside 
ok. inside 
class Outside 
error 
ok. outside 

Alors j'appelle Outside#run() je suis arrivé Base#run() ("erreur" en sortie). Les réflexions fonctionnent correctement.

Qu'est-ce qui ne va pas? Ou est-ce un comportement attendu? Puis-je contourner ce problème en quelque sorte?

Answer 1

De Java Virtual Machine Specification:

5,3 Création et chargement
...
A temps d'exécution, une classe ou une interface est déterminée non pas uniquement par son nom, mais par une paire: son nom complet et son chargeur de classe de définition. Chaque classe ou interface appartient à un package d'exécution .Le package d'exécution d'une classe ou d'une interface est déterminé par le nom du package et en définissant le chargeur de classes de la classe ou l'interface .

---

5.4.4 Contrôle d'accès

... un champ ou une méthode R est accessible à une classe ou d'une interface D si et seulement si l'une des des conditions suivantes est remplie:

• ...
• R est soit protected ou package privé (qui est, ni public ni protected ni private), et est déclarée par une classe dans le même package d'exécution en tant que D.

Answer 2

La spécification de langage Java stipule qu'une classe peut uniquement remplacer les méthodes auxquelles elle peut accéder. Si la méthode super classe n'est pas accessible, elle est ombrée plutôt que remplacée. La réflexion "fonctionne" parce que vous demandez Outside.class pour sa méthode d'exécution. Si vous demandez Base.class à la place, vous aurez la super mise en œuvre:

 Method m = Base.class.getDeclaredMethod("run"); 
     m.setAccessible(true); 
     m.invoke(p); 

Vous pouvez vérifier que la méthode est jugée inaccessible en faisant:

public class Outside extends Base { 
    @Override 
    public void run() { 
     System.out.println("Outside."); 
     super.run(); // throws an IllegalAccessError 
    } 
} 

Alors, pourquoi est la méthode pas accessible? Je ne suis pas tout à fait sûr, mais je soupçonne que, tout comme les classes nommées par différents chargeurs de classes, aboutissent à des classes d'exécution différentes, les paquets nommés de la même manière par différents chargeurs de classes aboutissent à des paquets d'exécution différents.

Modifier: En fait, l'API de réflexion dit que c'est le même paquet:

Base.class.getPackage() == p.getClass().getPackage() // true 

Answer 3

J'ai trouvé le (pirater) façon de charger la classe externe principale classloader si ce problème a disparu.

Lire une classe en tant qu'octets et appeler la méthode protégée ClassLoader#defineClass.

code:

URL[] url = { new URL("file:/home/mart/workspace6/test2/bin/") }; 
URLClassLoader ucl = URLClassLoader.newInstance(url); 

InputStream is = ucl.getResourceAsStream("Outside.class"); 
byte[] bytes = new byte[is.available()]; 
is.read(bytes); 
Method m = ClassLoader.class.getDeclaredMethod("defineClass", new Class[] { String.class, byte[].class, int.class, int.class }); 
m.setAccessible(true); 
Class<Base> outsideClass = (Class<Base>) m.invoke(Base.class.getClassLoader(), "Outside", bytes, 0, bytes.length); 

Base p = outsideClass.newInstance(); 
System.out.println(p.getClass()); 
p.run(); 

sorties ok. outside comme prévu.