Jar Dateien in Classpath laden ab JDK 9+

[lam_tr]

Hallo zusammen,

kennt jemand eine Lösung wie ich Jar Dateien in den Classpath laden kann?
Ich habe in Java 8 immer gut mit den folgenden Code mein Ziel erreicht.

URLClassLoader sysloader = (URLClassLoader) ClassLoader.getSystemClassLoader();
Method method = URLClassLoader.class.getDeclaredMethod("addURL", new Class[]{URL.class});
method.invoke(sysloader, new Object[]{file.toURI().toURL()});

Ab Java 9 ist es nicht mehr möglich. Ich habe hier eine Lösung gefunden https://stackoverflow.com/questions/48041764/add-jar-to-classpath-at-runtime-under-java-9 womit ich über einen Agenten hinzufügen kann. Ich muss den Agenten aber in MANIFEST.MF eintragen, was nicht möglich ist.

Gibts da noch andere Wege?

Viele Grüße
lam_tr

 

[Robert Zenz]

Wenn ich mich richtig erinnere, ist "addURL" "protected", also du kannst "URLClassLoaser" erweitern und die Methode einfach mit einer "public" ueberschreiben. So wie hier im DynamicClassLoader.

Implikationen betreffend Multi-Threading und aehnliches weisz ich aber gerade nicht, musst du testen.

Also du musst dann natuerlich die Applikation mit dem ClassLoader laden.

 

[lam_tr]

Wenn ich mich richtig erinnere, ist "addURL" "protected", also du kannst "URLClassLoaser" erweitern und die Methode einfach mit einer "public" ueberschreiben. So wie hier im DynamicClassLoader.

Implikationen betreffend Multi-Threading und aehnliches weisz ich aber gerade nicht, musst du testen.

Also du musst dann natuerlich die Applikation mit dem ClassLoader laden.

Ja genau hier der vollständige Code den ich bis einschließlich Java 8 benutzen kann

    @Override
    public void addPluginToClassPath(File jar) {
        // Get the ClassLoader class
        ClassLoader cl = ClassLoader.getSystemClassLoader();
        Class<?> clazz = cl.getClass();

        // Get the protected addURL method from the parent URLClassLoader class
        try {
            Method method = clazz.getSuperclass().getDeclaredMethod("addURL", new Class[] { URL.class });
            // Run projected addURL method to add JAR to classpath
            method.setAccessible(true);
            method.invoke(cl, new Object[] { jar.toURI().toURL() });
        } catch (NoSuchMethodException | SecurityException | IllegalAccessException | IllegalArgumentException
                | InvocationTargetException | MalformedURLException e) {
            LOGGER.error("Failed to add module " + jar.getName() + " to classpath", e);
        }
    }

Leider funktioniert das nicht für Java 9+.

Übrigens wenn ich im Java 16 das ausführe, bekomme ich diese Fehlermeldung

java.lang.NoSuchMethodException: jdk.internal.loader.BuiltinClassLoader.addURL(java.net.URL)
    at java.base/java.lang.Class.getDeclaredMethod(Class.java:2613)

 

[mrBrown]

Der übliche Weg wäre ein eigener ClassLoader für das Plugin, statt die Classen in den SystemClassLoader zu laden. Spricht da bei dir irgendwas gegen?

 

[lam_tr]

Der übliche Weg wäre ein eigener ClassLoader für das Plugin, statt die Classen in den SystemClassLoader zu laden. Spricht da bei dir irgendwas gegen?

Dann müsste ich jedes mal wenn ich per Reflections die Klasse instanziiere, zuerst mal schauen welchen ClassLoader zu welchem Plugin gehört und dann den richtigen ClassLoader mein Class.forName mitgeben oder?

Nachtrag:
Theoretisch könnte man es doch so wurschteln oder? Anstatt der addUrl kann ich appendClassPath machen.

    @Override
    public void addPluginToClassPath(File jar) {
        // Get the ClassLoader class
        ClassLoader cl = ClassLoader.getSystemClassLoader();
        Class<?> clazz = cl.getClass();

        // Get the protected addURL method from the parent URLClassLoader class
        try {
            Method method = clazz.getSuperclass().getDeclaredMethod("appendClassPath", new Class[] { String.class });
            // Run projected addURL method to add JAR to classpath
            method.setAccessible(true);
            method.invoke(cl, new Object[] { jar.toURI().toURL().toExternalForm() });
        } catch (NoSuchMethodException | SecurityException | IllegalAccessException | IllegalArgumentException
                | InvocationTargetException | MalformedURLException e) {
            LOGGER.error("Failed to add module " + jar.getName() + " to classpath", e);
        }

Allerdings bekomme ich diese Fehlermeldung

Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make void jdk.internal.loader.BuiltinClassLoader.appendClassPath(java.lang.String) accessible: module java.base does not "opens jdk.internal.loader" to unnamed module

 

[mrBrown]

Dann müsste ich jedes mal wenn ich per Reflections die Klasse instanziiere, zuerst mal schauen welchen ClassLoader zu welchem Plugin gehört und dann den richtigen ClassLoader mein Class.forName mitgeben oder?

Ja, aber üblicherweise klappt das völlig problemlos. So ein Class.forName was völlig ohne Kontext irgendwo aufgerufen wird, gibt's ja eher selten?
Schon den Klassennamen muss man ja irgendwoher bekommen, und darüber hat man doch meist den Bezug zum Plugin und damit dann auch zum ClassLoader. Im Idealfall hat man ja nicht mal ein Class.forName, sondern löst das über die vorhandenen Mechanismen wie zB ServiceLoader.


Als Bonus bekommt man halt saubere Trennung zwischen den Plugins.

 

[lam_tr]

Ja, aber üblicherweise klappt das völlig problemlos. So ein Class.forName was völlig ohne Kontext irgendwo aufgerufen wird, gibt's ja eher selten?
Schon den Klassennamen muss man ja irgendwoher bekommen, und darüber hat man doch meist den Bezug zum Plugin und damit dann auch zum ClassLoader. Im Idealfall hat man ja nicht mal ein Class.forName, sondern löst das über die vorhandenen Mechanismen wie zB ServiceLoader.


Als Bonus bekommt man halt saubere Trennung zwischen den Plugins.

Vieleicht ist mein Ansatz auch nicht so gut, aber ich hole die Klassennamen aus einer XML Datei und die werden dann sozusagen zur Laufzeit geladen. Bevor das geschieht, werden alle bnötigten Dependencies in das Classpath hinzugefügt.

 

[mrBrown]

Vieleicht ist mein Ansatz auch nicht so gut, aber ich hole die Klassennamen aus einer XML Datei und die werden dann sozusagen zur Laufzeit geladen. Bevor das geschieht, werden alle bnötigten Dependencies in das Classpath hinzugefügt.

Das ist auch ein völlig üblicher Ansatz, macht zB IntelliJ intern genauso. Aber die XML-Datei ist doch vermutlich irgendwie einem Plugin zugeordnet und fällt nicht völlig aus der Luft?

Und da du Dependencies erwähnst: bei deinem Ansatz sind die Dependencies aller Plugins gemischt, das will man potentiell ja auch nicht, weil die uU inkompatibel sind.


Was btw auch möglich ist: einen Allgemeinen Plugin-Classloader, und der delegiert intern an einen ClassLoader pro Plugin. Du musst dann weiterhin nicht wissen, welches Plugin du grad benutzt, sondern sprichst die über den allgemeinen an – hast aber trotzdem die saubere Trennung zwischen denen.

 

[lam_tr]

Das ist auch ein völlig üblicher Ansatz, macht zB IntelliJ intern genauso. Aber die XML-Datei ist doch vermutlich irgendwie einem Plugin zugeordnet und fällt nicht völlig aus der Luft?

Und da du Dependencies erwähnst: bei deinem Ansatz sind die Dependencies aller Plugins gemischt, das will man potentiell ja auch nicht, weil die uU inkompatibel sind.


Was btw auch möglich ist: einen Allgemeinen Plugin-Classloader, und der delegiert intern an einen ClassLoader pro Plugin. Du musst dann weiterhin nicht wissen, welches Plugin du grad benutzt, sondern sprichst die über den allgemeinen an – hast aber trotzdem die saubere Trennung zwischen denen.

Ja das ist richtig, zu jedem Plugin gibt es eine sogenannte plugin.xml wo die ganzen Services registiert sind.

Der Ansatz mit Plugin Classloader hört sich gut an. Allerdings weiß ich noch nicht genau was damit gemeint ist für die Umsetzung. Soll ich eine Klasse PluginAClassLoader der von ClassLoader erbt anlegen. Und von außerhalb soll man sich an die Klasse bedienen für die Erstellung der Instanzen?

Wie komme ich von Main Projekt auf die ganzen PluginClassLoaders? oder soll an der Stelle die PluginClassLoader auch in der plugin.xml definiert werden?

 

[mrBrown]

Allerdings weiß ich noch nicht genau was damit gemeint ist für die Umsetzung. Soll ich eine Klasse PluginAClassLoader der von ClassLoader erbt anlegen.

Nein, nicht spezifisch pro Plugin sondern nur einen PluginClassLoader, der wird dann für jedes Plugin instanziiert mit den Dependencies für das entsprechenden Plugin.

Wie komme ich von Main Projekt auf die ganzen PluginClassLoaders? oder soll an der Stelle die PluginClassLoader auch in der plugin.xml definiert werden?

Irgendwo findest du doch alle Plugins raus, die existieren? Wenn du dann das Plugin "lädst", erstellst du einen PluginClassLoader für das Plugin und merkst dir den irgendwo. Alle Klassen für das Plugin werden dann immer über den ClassLoader geladen.

 

[lam_tr]

Nein, nicht spezifisch pro Plugin sondern nur einen PluginClassLoader, der wird dann für jedes Plugin instanziiert mit den Dependencies für das entsprechenden Plugin.



Irgendwo findest du doch alle Plugins raus, die existieren? Wenn du dann das Plugin "lädst", erstellst du einen PluginClassLoader für das Plugin und merkst dir den irgendwo. Alle Klassen für das Plugin werden dann immer über den ClassLoader geladen.

Die Idee war schon ganz cool, aber mir ist gerade bei der Umsetzung erst aufgefallen, dass in der plugin.xml eine Referenzierung auf ein anderes plugin gibt. D.h. über den Plugin ClassLoader kann es so auch nicht gehen.

Gibt es keinen Weg gleich alle jars in Classpath zu machen wie vor Java 9?

Okay alternativ, kann ich alle Jars in den Plugin ClassLoader stopfen und alle Instanzen über ihn instanzieren. Nicht so schön, aber möglich.

 

[mrBrown]

Die Idee war schon ganz cool, aber mir ist gerade bei der Umsetzung erst aufgefallen, dass in der plugin.xml eine Referenzierung auf ein anderes plugin gibt. D.h. über den Plugin ClassLoader kann es so auch nicht gehen.

Das geht trotzdem problemlos, das wird uU minimal komplexer, weil man ein bisschen aufpassen muss, was an den parent-classloader delegiert wird, und was man im eigenen sucht, aber möglich ist das.

Gibt es keinen Weg gleich alle jars in Classpath zu machen wie vor Java 9?

Spätestens mit 16 & 17 gibt’s dann die nächsten Probleme.

Okay alternativ, kann ich alle Jars in den Plugin ClassLoader stopfen und alle Instanzen über ihn instanzieren. Nicht so schön, aber möglich.

Geht, ist aber eben unschön. Saubere Trennung und saubere Konzepte für Abhängigkeiten sind deutlich besser.