Erste Schritte Wo steht eigentlich das ein jar keine andere jars enthalten darf?

  • Themenstarter Themenstarter schnatter08
  • Beginndatum Beginndatum
S

schnatter08

Gast
Hallo,

ich habe schon oft gelesen, dass ein jar keine anderen jars enthalten darf. Gibt es da auch ne offizielle Festlegung? Also ich kann zwar jars in jars haben, aber das würde ja keinen Sinn machen wenn ich die in den inneren jars enthaltenen Klassen brauche.
 
Wo steht denn eigentlich, dass man Jars in Jars verschachteln darf?

Muss es für jede seltsame Idee ein "Geht nicht" Dokument geben?

Abgesehen davon geht das mit OSGi, steht auch so in der OSGi Doku 😉
 
ich habe schon oft gelesen, dass ein jar keine anderen jars enthalten darf. Gibt es da auch ne offizielle Festlegung?
Von dem "Verbot" hab ich noch nirgends gelesen... ;-)
Also ich kann zwar jars in jars haben, aber das würde ja keinen Sinn machen wenn ich die in den inneren jars enthaltenen Klassen brauche.
Ja, direkt aus dem Jar kannst du die Klassen im "inneren" Jar nicht nutzen. Jar ist ja ein Archiv Format (zip/rar...)
 
Klar geht das! Schon mal ein Runnable Jar bei Eclipse exportiert? Entweder werden die Jars dann zu einer zusammengefügt, oder sie bleiben als Ganzes in dem entstehenden Jar enthalten.

Also alle abhängikeiten in eine Jar repacken ist s*****e, da dies Lizenzrechtliche Probleme bringt.
Und jars in jars verschachteln geht in diesem Fall auch nur, dadurch dass Eclipse einen eigenen jar-in-jar Classloader mit reinpackt. Funktioniert aber auch nicht immer zuverlässig.
 
Man sollte aber nicht immer nur den technischen Aspekt, sonder auch den lizenrechtlichen betrachten.

IMHO finde ich, die Jars in einem Ordern neben der Jar zu legen viel besser, da man bei Updates nicht immer die ganze Anwendung ausliefern muss.
 
Ich hab in meinem aktuellen Projekt eine Kombination gewählt. Plugins kann man als einzelnes JAR ausliefern, wenn man nur Abhängigkeiten gegen das Framework hat oder als ZIP wenn man eigene Abhängigkeiten hat (z.B. an nen Cache System wie EHcache). Letzteres wird dann in ein temporäres Verzeichnis (work/myzip/...) entpackt und von da geladen.
 
1. Jar-in-Jar ist ebenso Schwachfug wie IrgendEinAndererPacker-in-IrgendEinAndererPacker, weil das zuvor komprimierte stets weiteren und damit wieder mehr Platz einnimmt, z.B. ganz allein durch die Info, dass eine Datei unkomprimiert in ein Archiv eingefügt wurde.
2. Klassen aus Jar-in-Jar klappt immer dann vorzüglich, wenn man die URL zum Bytecode kennt. Leider muss dazu das innere Archiv in ein temporäres Verzeichnis kopiert werden, damit man eine solche bekommt. Aus diesem Grund kann man sich Jar-in-Jar von vorneherein ebenfalls sparen.
 
1. Jar-in-Jar ist ebenso Schwachfug wie IrgendEinAndererPacker-in-IrgendEinAndererPacker, weil das zuvor komprimierte stets weiteren und damit wieder mehr Platz einnimmt, z.B. ganz allein durch die Info, dass eine Datei unkomprimiert in ein Archiv eingefügt wurde.
2. Klassen aus Jar-in-Jar klappt immer dann vorzüglich, wenn man die URL zum Bytecode kennt. Leider muss dazu das innere Archiv in ein temporäres Verzeichnis kopiert werden, damit man eine solche bekommt. Aus diesem Grund kann man sich Jar-in-Jar von vorneherein ebenfalls sparen.

Nope man kann das durchaus machen wenn man mag:
http://www.java-forum.org/allgemeine-java-themen/60569-jar-jar-urlclassloader.html#post375414

Und das temporäre entpacken ist eher eine Art Deployment wie es Containersysteme machen, z.B. EAR, WAR, RAR, ...
 
Nope heisst unbedingt Nein? Ich sag' mal, eine Anwendung zwecks Verbreitung mit all seinen Archiven und Zeugs in einem Container zu halten, geht durchaus in Ordnung. Aber eine solche Anwendung bei ständiger Verwendung in diesem Zustand zu belassen, ist celebrale Diarrhoe (mein neues Lieblingswort... kann mir nicht helfen :lol🙂. Wenn das jeder machen würde, wären wir bald bei Jar-in-Jar-in-Jar-uswmoe. Und ja, den URLClassloader kenn' ich bereits; Ist für das Nachladen von Jar-Archiven ausserhalb des eigentlich gesetzten Klassenpfades sehr hilfreich.
Kurzum: Nirgends steht, das Jar-in-Jar verboten ist, aber auf jeden Fall sollte man wissen, wann es Sinn macht und wann nicht.
 
Naja, RMI und JNDI-Lookups, sicher auch Reflection darunter. Kurz zum testen als jar-in-jar exportiert, und bumm, ClassNotFoundException. Mit den Jars in einen Ordner neben der hauptjar hat es tadellos funktioniert.
 
Die Frage ist ja wie der arbeitet. Es reicht ja nicht, dass da nur ein Classloader ist, schließlich gibt es ja auch RMIClassLoader... ClassLoading ist halt kein einfaches Thema und doch behaupte ich, dass es in jedem Fall möglich ist diese Strategie zu fahren, eben immer mit der Einschränkung zu überlegen: Macht es überhaupt Sinn?
 

Zurück
Oben