static und dynamic linking?

[Guest]

Mhm,

kann mir bitte jemand mal ein Beispiel geben wie ich eine Lib z.B. in 123.jar statisch und wie dynamisch verlinken würde?

Besten Dank

 

[foobar]

Öhm, statisch und dynamisch linken? DU bist wohl im falschen Märchen. Sowas gibt in C/C++ aber nicht in Java.
In Java werden Klassen mit Hilfe eines Classloaders aus Jars geladen.

 

[Gast]

In diversen Lizenzen wird immer über statisch / dynamisches linking gesprochen. Nur ich kann mir in Java keinen Reim darauf machen was das sein soll.

 

[Ebenius]

Betrachte alle Verknüpfungen zwischen JARs als dynamisch gelinked. Das passt meines Erachtens sauber.

 

[foobar]

In diversen Lizenzen wird immer über statisch / dynamisches linking gesprochen. Nur ich kann mir in Java keinen Reim darauf machen was das sein soll.

Das ist in Java nicht so einfach zu beantworten, weil es so viele verschiedene Möglichkeiten gibt. Wenn man z.b. in einer kommerziellen Anwendung den Mysql-Treiber (GPL) verwendet, muß man seine Anwendung aber nicht unter die GPL stellen, da man ja nur per JDBC Interfaces auf den Treiber zugreift.

Es ist aber generell nicht leicht bestimmtbar was jetzt als derived work gilt und was nicht.

Der Spring dmServer steht auch unter der GPL man kann diesen aber nutzen um kommerzielle Anwendungen zu erstellen, da man ja keine Veränderungen am Server vornimmt.

Im Einzelfall sollte man sich daher immer professionellen Rat suchen.

 

[Ebenius]

Zur LGPL vs. Java™ habe ich jüngst bzgl. eines anderen Foren-Threads diesen Beitrag von David Turner (FSF) gefunden.

 

[Spacerat]

Bin mir nicht Sicher...

Statisch verlinken:
Die einzelnen Klassen eines Jar-Archives werden per "import"-Direktive eingebunden. Die erstellte Klasse läuft nur, wenn das Jar-Archiv vorhanden ist.

Dynamisch verlinken:
Auf die einzelnen Klassen eines Jar-Archives wird ausschliesslich über das Reflection-API zugegriffen. Die erstellte Klasse bleibt auch ohne das Jar-Archiv lauffähig.

mfg Spacerat

 

[Ebenius]

Statisch verlinken:
Die einzelnen Klassen eines Jar-Archives werden per "import"-Direktive eingebunden. Die erstellte Klasse läuft nur, wenn das Jar-Archiv vorhanden ist.

Dynamisch verlinken:
Auf die einzelnen Klassen eines Jar-Archives wird ausschliesslich über das Reflection-API zugegriffen. Die erstellte Klasse bleibt auch ohne das Jar-Archiv lauffähig.

Entschuldige, aber das ist eine völlig unsinnige und falsche Erklärung. Lies mal in der Wikipedia, was ein Linker tut! DLLs sind dynamisch gelinkt. Funktioniert Dein Windows ohne sie?

Ebenius

 

[byte]

Statisch verlinken:
Die einzelnen Klassen eines Jar-Archives werden per "import"-Direktive eingebunden. Die erstellte Klasse läuft nur, wenn das Jar-Archiv vorhanden ist.

Dynamisch verlinken:
Auf die einzelnen Klassen eines Jar-Archives wird ausschliesslich über das Reflection-API zugegriffen. Die erstellte Klasse bleibt auch ohne das Jar-Archiv lauffähig.

Das macht keinen Sinn, denn auch beim Zugriff per Reflection hast Du die entsprechenden Imports im Code.

 

[Ebenius]

Das macht keinen Sinn, denn auch beim Zugriff per Reflection hast Du die entsprechenden Imports im Code.

Das wiederum ist auch Unsinn... :lol:

 

[Spacerat]

@Ebenius: Kommt wohl auf die DLL an. Windows kann z.B. völlig auf eine "opengl.dll" verzichten. Was ein Linker tut ist mir durchaus bewusst. Wenn man versucht, in Java eine Klasse mit

Object o = Class.forName("javax.media.opengl.GLCanvas").newInstance();

zu instanzieren, kann man die ClassNotFoundException abfangen, weil der Klassenname komplett am Linker vorbei geht (dynamisch verlinkt). Würde man stattdessen die Klasse importieren, kann man seine eigene nichtmal kompilieren, wenn "JOGL" im ClassPath nicht gefunden wurde. Völlig "Unsinnig und Falsch" kann ich deswegen nur zurückgeben.

mfg Spacerat

 

[maki]

Spacerat,

in Java wird ausschliesslich dynamisch gelinkt.

Statisch hiesse hier dass alle benötigten Klassen etc. mit in das übersetzte Kompilat (.class Datei) gepackt (gelinkt) würden. Dynamisch bedeutet dass zur Laufzeit die benötigten Libs geladen werden (Jars, andere .class Dateien), das macht Java immer so.
In C/C++ zB. hat man die Wahl ob man statisch oder dynmisch linken will.

 

[Ebenius]

Bei einer statisch gelinkten Applikation entsteht ein Binary. Danach kann man die Bibliothek nicht mehr von der Applikation trennen. Wenn ich jedoch gegen eine JAR-Datei kompiliere, kann ich sie nachträglich jederzeit durch eine andere (Implementation oder Version) austauschen. Damit kann in Java zwischen zwei JARs nicht statisch gelinkt sein.

Dynamisch kann man eine Anwendung auch nur Linken, wenn die entsprechenden Header-Files vorhanden sind. Die gehören normaler Weise zur selben Bibliothek mit der selben Lizenz.

Lies Dir doch den Artikel von David Turner (siehe oben) durch. Der Mann weiß, wovon er redet.

Ebenius

 

[byte]

Das macht keinen Sinn, denn auch beim Zugriff per Reflection hast Du die entsprechenden Imports im Code.

Das wiederum ist auch Unsinn... :lol:

Zumindest sobald Du Dich auf eine spezifische XYZ.class beziehst, brauchst Du auch den Import. Wenn man hingegen auf Typsicherheit bei Reflection pfeift, gehts auch ohne. :roll:

 

[Ebenius]

Zumindest sobald Du Dich auf eine spezifische XYZ.class beziehst, brauchst Du auch den Import. Wenn man hingegen auf Typsicherheit bei Reflection pfeift, gehts auch ohne. :roll:

Das Wort Typsicherheit passt bei Reflection allgemein nicht recht. ;-)

Ich hatte eigentlich in Bezug auf Deinen vorhergehenden Kommentar gemeint ─ und leider nicht näher ausgeführt, mein Fehler ─, dass die Erklärung keinen Sinn ergibt, weil die Tatsache, dass eine Klasse (per Import oder per qualifizierter Benennung) einer anderen bekannt gemacht wird, nichts darüber aussagt, ob sie statisch oder dynamisch gelinkt ist.

Ebenius

 

[byte]

Zumindest sobald Du Dich auf eine spezifische XYZ.class beziehst, brauchst Du auch den Import. Wenn man hingegen auf Typsicherheit bei Reflection pfeift, gehts auch ohne. :roll:

Das Wort Typsicherheit passt bei Reflection allgemein nicht recht. ;-)

Wieso? Siehe: Class#isInstanceOf(obj) ;-)

Ich hatte eigentlich in Bezug auf Deinen vorhergehenden Kommentar gemeint ─ und leider nicht näher ausgeführt, mein Fehler ─, dass die Erklärung keinen Sinn ergibt, weil die Tatsache, dass eine Klasse (per Import oder per qualifizierter Benennung) einer anderen bekannt gemacht wird, nichts darüber aussagt, ob sie statisch oder dynamisch gelinkt ist.

Na dann wollten wir ja genau das gleiche sagen. Schön.

 

[Spacerat]

Lies Dir doch den Artikel von David Turner (siehe oben) durch. Der Mann weiß, wovon er redet.

Ok... gemacht... Hab' gerade das Gefühl, dass das von dem er da schreibt zunehmend in Vergessenheit gerät. Für mich erschloss sich das statische oder dynamische Einbinden irgendwelcher Librarys bisher nur darin, die Ausfürung eines Programms von einer solchen abhängig zu machen oder nicht. Die Möglichkeit alles in ein Binary zu packen ist im übrigen auch in Java gegeben. Aber ist das Sinnvoll? Ist das OOP? Wie würdest du denn meine beiden Arten, Jar-Archive einzubinden unterscheiden? Abhängig->Unabhängig?

mfg Spacerat

 

[Ebenius]

Spacerat, abhängig ist das Programm in beiden Fällen. Unterscheiden kannst Du's daran, ob die Bibliothek ausgetauscht werden kann (ohne einen Decompiler o.ä. zu bemühen), oder ob eine konkrete Version in der Applikation fest verdrahtet ist. Wenn Du beispielsweise alle Klassen aus der Bibliothek nimmst und sie in Dein eigenes JAR legst, dann würde ein Richter das wahrscheinlich als equivalent zum Prinzip des statischen Linkens betrachten.

Rein technisch wäre es selbst dann noch dynamisch gelinkt. Beispielsweise könnte man einfach die neuere Version der Bibliothek weiter vorn in den CLASSPATH stecken und schon würde die eingebaute (auf normalem Weg) nicht mehr benutzt.

Rein technisch gesehen sind in Java alle Verbindungen zwischen verschiedenen statischen Klassen dynamisch. Rechtlich würde man sicher eher die Grenze ziehen.

Ebenius

 

[byte]

Wobei es keiner so genau sagen kann, denn ich bezweifel, dass es da schon Präzedenzfälle in Deutschland gibt.

 

[Guest]

Da habe ich ja eine Diskussion losgetreten.

Dennoch habe ich es nicht ganz verstanden:

The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's “import” functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is then generally a derivative work of the library. So, the copyright holder for the library must authorize distribution of the work. The LGPL permits this distribution.

If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications

Wenn ich es richtig übersetzt habe steht im ersten Absatz. Verwendest du ein import handelt es sich um ein "derivative work" und ich muss das ganze unter die LGPL stellen.

Zugleich steht im zweiten Absatz. Wenn ich das so mache, dann muss ich den Anwendern die Möglichkeit geben die genutzten Libs zu modifizieren und die Anwender dürfen meinen Code (der unter einer anderen Lizenz stehen kann?) "reverse engineer" = dekompilieren?

Wiederspricht sich da nicht der erste und der zweite Absatz?

 

[Ebenius]

Du hast das da falsch übersetzt:

So, the copyright holder for the library must authorize distribution of the work. The LGPL permits this distribution.

Da steht: Der Rechteinhaber der Bibliothek [nicht der Applikation] muss die Erlaubnis geben ...

Ebenius

 

[Guest]

Ok ich glaube wir reden aneinander vorbei.

Wenn ich "import" nutze um auf eine Klasse einer anderen JAR zu verlinken, dann darf ich das gar nicht (zumindest nicht mit der LGPL)?

Zugleich steht aber im zweiten Absatz wenn ich das doch mache, dann kann ich das unter der LGPL tun wenn ...

If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL

Mich stört hier das import. Und wie "importiere" ich dann ein Bibliothek die unter der LGPL steht, wenn ich das nur darf, wenn der Rechteinhaber zustimmen muss?

 

[Ebenius]

Der Rechteinhaber stimmt zu, indem er die LGPL-Lizenz vergibt.

 

[Guest]

Das ist jetzt aber ein Wiederspruch in sich oder?

Bevor man über die Frage spricht: Was darf ich unter der Lizenz mit der Bibliothek tun, muss das Werk erstmal eine Lizenz haben. Also hat der Rechteinhaber hat die Bibliothek bereits unter die LGPL gestellt.

Greift nun eine Applikation auf die Bibliothek zu und nutzt die "import"-Funktion dann geht das eben mit der LGPL nicht:

... The LGPL permits this distribution

Also bleibt nichts anderes übrig als ?

a) Alle LGPL-Bibliotheken schreddern ? (Keine Nutzung unter der LGPL ohne zusätzlich Erlaubnis?)

b) Die Bibliothek anders nutzen ?

c) Bei der Verwendung einer LGPL Bibliothek den Nutzer jedes mal um Erlaubnis zu bitten ?

Die Antwort b) scheidet nach meinem dafürhalten aus, da später geschrieben steht:

Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.

Also sind auch einfache Funktionsaufrufe auf die Bibliothek unter der LGPL nicht möglich.

 

[Ebenius]

to permit = erlauben...

 

[Gast]

Alles klar.

Danke da war der Übersetzungsfehler.

 

[Ebenius]

Weil ich's jetzt schon übersetzt habe: So nah wie möglich am Original, kein gutes Deutsch und "Reverse Engineering" kann ich nicht übersetzen. Natürlich gibt's keine Garantie auf Vollständigkeit oder inhaltliche Richtigkeit:

Typischer weise werden alle Bibliotheken die eine Java-Anwendung verwendet als JAR (Java-Archiv) verteilt. Die Anwendungen benutzen Java's "import"-Funktionalität um auf Klassen dieser Bibliotheken zuzugreifen. Wenn die Anwendung kompiliert wird, werden die Methodensignaturen gegen die Bibliothek geprüft und verknüpft. Die Anwendung ist damit allgemein eine auf die Bibliothek aufbauende Arbeit. Deshalb muss der Rechteinhaber der Bibliothek der Verteilung dieser Arbeit authorisieren. Die LGPL authorisiert diese Verteilung.

Wenn Sie eine Java-Anwendung verteilen die LGPL-Bibliotheken importieren, ist es einfach die LGPL einzuhalten. Die Lizenz Ihrer Anwendung muss es anderen erlauben, die Bibliothek zu modifizieren und Reverse Engineering Ihres Codes zu betreiben um diese Modifikationen zu testen.

Ebenius

 

[Gast]

Besten Dank!

Weil wir gerade bei dem Thema sind. Es ist in dem Text ja nichts darüber gesagt wo diese Bibliotheken liegen?

Ich darf also auch eine mit fatJAR / oneJAR erstelltes Archiv nutzen. Die Ordner-Struktur und damit eine Trennung zwischen meinem Code und den Bibliotheken bleibt erhalten. Oder seht ihr das anders?

Wie sieht es dann mit Java Wrappern aus, die aus einem JAR-Archiv eine EXE-Datei machen?

 

[Ebenius]

Weil wir gerade bei dem Thema sind. Es ist in dem Text ja nichts darüber gesagt wo diese Bibliotheken liegen?

Ich darf also auch eine mit fatJAR / oneJAR erstelltes Archiv nutzen. Die Ordner-Struktur und damit eine Trennung zwischen meinem Code und den Bibliotheken bleibt erhalten. Oder seht ihr das anders?

Du bekommst die Lizenz für eine Bibliothek. Nicht für einzelne Klassen. Ich würde beim Neuzusammenstellen lizenzrechtliche Probleme erwarten.

Wie sieht es dann mit Java Wrappern aus, die aus einem JAR-Archiv eine EXE-Datei machen?

An der Stelle bin ich mir halbwegs sicher, dass ein Gericht gegen Dich entscheiden würde.

Disclaimer: Ich drücke nur meine Meinung aus. Niemand sollte das mit einer Rechtsberatung verwechseln.

Ebenius

 

[L-ectron-X]

"Reverse Engineering" kann ich nicht übersetzen

Grob vielleicht so: "umkehrende Entwurfstechnik"?

Zu einer übersetzten LGPL geht's hier entlang.

 

[Leroy42]

Mann, ihr habt Probleme! :shock:

(Aber egal: Früher war ich auch so pedantisch! )

 

[Ebenius]

Mann, ihr habt Probleme! :shock:

(Aber egal: Früher war ich auch so pedantisch! )

Du bist ja nur neidisch!

 

[Guest]

Hallo Ebenius,

bzgl. dem Wrapper habe ich mir das schon gedacht. Das sehe ich ebenso kritisch.

Bzgl. oneJAR / fatJAR habe ich mich falsch ausgedrückt.

Du bekommst die Lizenz für eine Bibliothek. Nicht für einzelne Klassen. Ich würde beim Neuzusammenstellen lizenzrechtliche Probleme erwarten.

oneJAR übernimmt die gesamte Bibliothek (JAR-Datei). Diese wird nicht entpackt oder neu zusammengepackt, sondern wird so wie sie ist in ein JAR Archiv gepackt (quasi JAR in JAR). Drum herum wird ein ClassLoader gebastelt, der das JAR in der JAR lädt. Da hier die Strukturen beibehalten werden halte ich es für unkritisch.

Aber auch das ist nur meine private Meinung!