Java - comment charger les différentes versions de la même classe?

J'ai lu beaucoup de choses sur Java chargeurs de classes, mais jusqu'à présent, je n'ai pas réussi à trouver une réponse à cette simple question:

J'ai deux versions de com.abc.Hello.class dans des bocaux v1.jar et v2.jar. Je veux utiliser les deux dans mon application. Quelle est la façon la plus simple de faire cela ?

Je ne m'attends pas à être aussi simple que cela, mais quelque chose le long de ces lignes serait génial :

Classloader myClassLoader = [magic that includes v1.jar and ignores v2.jar]
Hello hello = myclassLoader.load[com.abc.Hello]

Et dans une classe différente :

Classloader myClassLoader = [magic that includes v2.jar and ignores v1.jar]
Hello hello = myclassLoader.load[com.abc.Hello]

Je voudrais éviter d'utiliser OSGi.

  • Personnellement, je ne pense pas que je voudrais une telle magie car elle conduirait à une opération de maintenance/dépannage cauchemar... pourriez-vous expliquer pourquoi vous avez besoin de cela?
  • Plusieurs plugins qui dépendent de différentes versions de la même bibliothèque partagée serait une raison pour cela.
InformationsquelleAutor kms333 | 2012-08-01
  1. 41

    Vous êtes dans la bonne voie. Vous devez prendre certaines choses en considération.

    La chose normale est des classes qui existent dans les chargeurs de classes parent sont utilisés. Donc, si vous voulez deux versions de ces classes ne doit pas être là.

    Mais si vous souhaitez interagir vous pouvez utiliser la réflexion, ou encore mieux une interface commune. Donc je vais le faire:

    common.jar:
BaseInterface

v1.jar:
SomeImplementation implements BaseInterface

v2.jar:
OtherImplementation implements BaseInterface

command-line:
java -classpath common.jar YourMainClass
//you don't put v1 nor v2 into the parent classloader classpath

Then in your program:

loader1 = new URLClassLoader(new URL[] {new File("v1.jar").toURL()}, Thread.currentThread().getContextClassLoader());
loader2 = new URLClassLoader(new URL[] {new File("v2.jar").toURL()}, Thread.currentThread().getContextClassLoader());

Class<?> c1 = loader1.loadClass("com.abc.Hello");
Class<?> c2 = loader2.loadClass("com.abc.Hello");

BaseInterface i1 = (BaseInterface) c1.newInstance();
BaseInterface i2 = (BaseInterface) c2.newInstance();
    • upvoted en raison de l'explication au sujet de ne PAS avoir les deux versions dans les principaux classpath. Il serait utile si vous pouviez aussi expliquer comment ils utiliseraient c1 et c2 dans le code, et quelle serait la compilation. C'est, comment font-ils invoquer c1.someMethod()?
    • Merci! Un plus de détail: "ordinaires" classes peuvent être transmis code principal et v1/v2 code. commune de classes sont des classes chargé par le chargeur de classe parent afin qu'ils soient disponibles à l'un d'eux (parents, v1 base et v2 en fonction). Tous les JRE classes entrent dans cette catégorie. C'est pourquoi vous pouvez passer de java.lang.Chaîne le long des méthodes par exemple.
    • eh bien, peut-être que je l'ai fait implicite. De toute façon: vous pouvez toujours utiliser BaseInterface, et il est présent dans le chargeur de classe parent et à cause de cela, disponible à partir de code principal (sous forme de Chaîne est, ou de toute autre JRE classe). Vous n'utilisez jamais de code principal de classes chargées que dans l'enfant chargeurs de classes. Bas de ligne: BaseInterface doit avoir les méthodes que vous aurez besoin de code principal.
    • J'ai trouvé le code ci-dessus pour charger le premier de la classe dans le classpath, malgré lui demandant de charger à partir de deux différents pots. La raison pour cela est probablement du chargeur de classe parent délégation. En définissant le parent null, j'ai été en mesure de charger la même classe à partir de deux pots: loader1 = new URLClassLoader(nouvelle URL[] {new File("v1.jar").toURL()}, null); loader2 = new URLClassLoader(nouvelle URL[] {new File("v2.jar").toURL()}, null);
    • J'ai mis en œuvre de votre proposition pour gérer les non-compatible version de elasticsearch l'utilisation des clients. Checkout github.com/atulsm/ElasticsearchClassLoader
    • J'ai le même problème mais que faire si ils n'implémentent la même interface. comme le code de la bibliothèque n'est pas disponible pour moi. je ne peux donc pas ajouter de l'interface de mise en œuvre moi-même. donc je ne peut pas lancer à mon choix de la version de la classe. droit?

    InformationsquelleAutor helios
  2. 6

    Vous avez presque écrit la solution.
    J'espère que le fragment de code suivant vous aidera.

    ClassLoader cl = new URLClassLoader(new URL[] {new File("v1.jar").toURL()}, Thread.currentThread().getContextClassLoader());
Class<?> clazz = cl.loadClass("Hello");

    Remplacer v1.jar par v2.jar et ce code permet de charger la version #2.

    • +1. J'ai ajouté votre nouveau URLClassLoader ligne de mon post 🙂 c'était ce Que j'étais en manque...
    InformationsquelleAutor AlexR
  3. 0

    cela dépend de ce que sont u va faire avec les deux versions et le comment, mais en général, vous pouvez au moins de la charge 2 version de classe dans les différents chargeurs de classes, puis définissez la Fil.contextClassloader() et jouer...

    voir http://www.javaworld.com/javaqa/2003-06/01-qa-0606-load.html et http://docs.oracle.com/javase/jndi/tutorial/beyond/misc/classloader.html

    InformationsquelleAutor Andrey Borisov
  4. 0

    Pour un exemple de mise en œuvre de la accepté de répondre par @helios caisse github.com/atulsm/ElasticsearchClassLoader

    • Cet exemple semble avoir quelques problèmes: 1: Il jette exception: "org.elasticsearch.client.de transport.NoNodeAvailableException: Aucun des nœuds configurés sont disponibles", 2: Il y a un "CustomClassLoader" qui ne semble pas être utilisés à tous. Un bon exemple doit être un cas sans d'inutiles supplémentaires des informations trompeuses...
    InformationsquelleAutor Atul Soman