dynamische imports?

[chrisi_01]

Hallo,

ich wollte mal fragen, ob es in Java sowas wie dynamische imports gibt?

Zweck des Ganzen wäre, dass wir im Studium, zwei Versionen einer Jar-File auf Fehler testen sollen.
Dh eine Jar ist das Orginal und an der Anderen wurde etwas geändert,
wodurch die Funktionalität einiger Methoden nicht mehr übereinstimmt.
Da sie strukturell und namentlich (Klassen und Methoden) gleich sind, wäre der import einer Klasse gleich.
Wie bekomme ich es hin, dass ich eine Instanz der Klasse A aus der einen und eine Instanz der Klasse A aus der anderen Jar erstelle,
um die Rückgabewerte der Methoden zuvergleichen.

Es wäre sicher eine Möglichkeit zwei Klassen mit unterschiedlichem Namen zu erstellen, wobei eine von von der Klasse der einen und die andere von der Klasse der andern Jar erbt. Aber bei 20 Klass wäre das 40 Klassen die nichts anderes tun als von einer anderen Klasse zu erben, was ich nicht wirklich elegant finde.

Hab jemand von euch eine Idee, wie ich das hinbekommen könnte?

PS: Ich hoffe, dass ich so halbwegs rüberbringen konnte, was das Problem ist.
Falls nicht, schreibt bescheid.

 

[Illuvatar]

Ein paar Stichworte:

Reflection
ClassLoader
URLClassLoader

 

[Landei]

Entweder wie vorgeschlagen mit ClassLoader, oder so:

Einen kleinen Client basteln. Zweimal installieren, einmal mit Referenz auf das eine Jar und einmal auf das andere.
Kleinen Server basteln, der die Clients "parallel" auf unterschiedlichen Ports abfragen kann. Wie man die Abfrage am besten macht usw. hängt natürlich sehr von der Aufgabenstellung ab.

 

[Der Müde Joe]

Könntest auch den
http://www.java-forum.org/allgemeine-java-themen/81589-eigener-classloader.html
JarClassLoader benutzen. Eventuell die JarResource auf Gleichheit testen.

 

[chrisi_01]

Hallo, danke erst mal für den Hinweis auf den ClassLoader und das konkrete Beispiel mit dem JarClassLoader.

Ich habe nur ein bisschen damit rumgespielt und bin auf ein neues Problem gestoßen.

1.
Ist es Möglich auf protected Variablen und Mehoden (aus einer,in einer JarFile steckenden, Klasse) zuzugreifen bzw. auszuführen?

2.
Ist es Möglich von einer Klasse zu erben, die man per ClassLoader geladen hat?

 

[Wildcard]

1. ja, sofern der SecurityManager es nicht verhindert. Mit getDeclaredFields kommt man an nicht public Member, mit setAccessible(true) werden sie dann 'freigeschaltet'
2. Jein, mit dynamischen Proxies und Invocation Handler kannst du dynamisch Interfaces implementieren, aber nicht von Klassen erben.

Die Kombination dynamische Klasse laden + dynamischer Proxy ist allerdings äusserst ungewöhnlich und ich wüsste aus dem Stehgreif kein Beispiel wo sich das sinnvoll anwenden ließe. Bist du sicher das du in die richtige Richtung läufst? Vielleicht beschreibst du mal kurz deinen Use-Case.

 

[chrisi_01]

Ich habe zwei Versionen einer JarFile, ein Orginal und einen veränderte Version ... mit Fehlern sozusagen.
Nur will (soll) ich die Funktion(en) dieser vergleichen, also eine Art Regressionstest durchführen.
Da beide strukturell (Paketaufbau, Klassen- und Methodennamen) gleich sind, brauchte ich den ClassLoader, um zu bestimmen, aus welcher Jar die jeweilige Klasse geladen wird.
Das würde so weit auch alles passen, wenn es nicht so wäre, dass die auszuführende Klasse nur eine main-Methode zur Verfügung stellen würde, die dann den "Rest" machen.
Nahe zu alle anderen Methoden und Variablen sind protected.

Die Main bekommt als Parameter einen Path einer Datei und erstellt aus dieser eine XML-Datei.
Ich kann also mit beider Jars eine XML-Datei erstellen und diese dann vergleichen,
aber um die Fehler näher zu bestimmen, müsste ich die protected Methoden testen.

 

[Wildcard]

Und warum willst du dafür dynamisch von etwas erben?
Das ganze kommt mir ohnehin vor als würdest du von hinten durch die Brust ins Auge gehen.
Du willst Funktionalität einzelner Methoden Testen? Mach Unit Tests, genau dazu sind sie da.
Deine Unit Tests definierst du im im gleichen Package wie die zu testende Klasse, damit hast du Zugriff auf die protected Felder und Methoden.
Dann startest du deine Tests einmal mit der einen, dann mit der anderen Version und fertig ist die Wurst (dafür kann man zB ein kleines Ant Script bemühen).

 

[chrisi_01]

Aber selbst die Konstruktoren der Klassen sind protected,
dh ich kann noch nicht mal ein Objekt erzeugen, dessen Methoden ich mit JUnit oder was auch immer testen könnte, da ich dann ein "is not visible" bekomme.
Ich könnte sicher die class-Dateien aus der Jar dekompilieren, sie in ein neues Projekt packen und sie dann durch testen, aber das dart ich höchstwahrscheinlich nicht.

Wir gesagt, die XML-Dateien kann ich untereinander durchtesten,
aber ich hatte gedacht, dass ich vielleich auch noch rausbekommen kann in welchen Methoden die Fehler stecken.

 

[Wildcard]

Ich sag doch: Die Test Klassen kommen ins gleiche Package, dann siehst du alle protected Methoden und Konstruktoren.

 

[ModellbahnerTT]

Doofe Frage: warum schreibst du nicht ein Programm und führst es einfach zweimal aus, einmal mit der eien jar, einmal mit der anderen ajr im classpath?

 

[chrisi_01]

Das mit dem zweimal ausführen habe ich auch schon in betracht gezogen,
aber ich wollte erstmal schau, ob ich es auch so hingekomme.
Es hat halt den Vorteil, dass man für einen Test nicht erst 2 Programm starten muss,
außerdem beschäftige ich mich gleich ein Bisschen mit ClassLoadern.

 

[Wildcard]

Ich würde fast wetten das es auch so gedacht war Unit Tests zu verwenden.
Also nochmal: warum machst du keine Unit Tests und willst stattdessen irgendwelche Reflection Magic wirken?

 

[chrisi_01]

Hallo Wildcard,
ich werde es sicherlich so machen, dass ich UnitTests verwende,
aber wie schon geschrieben, wollte ich mal schauen, ob es auch anders möglich wäre.