Workaround einpflegen

[SimProtect]

Hallo,

Mein Problem: Ich verwende eine optionale Erweiterung für ein Framework. Diese liegt als .jar-File vor und wurde entsprechend als "referenced library" eingebunden (Eclipse).
Zwei Klassen dieser Erweiterung beinhalten einen Fehler. Zur Lösung wurden mir zwei neue Klassen als Workaround geschickt, welche die alten ersetzen sollen.
Aufgrund hoher Abhängigkeiten innerhalb der Erweiterung, kann ich die Klassen nicht einfach compilieren und selbst wieder einbinden (die Referenzen innerhalb der Erweiterung würden ja weiterhin auf die "defekten" Klassen verweisen). Auch verfüge ich nicht über die uncompilierten Klassen der Erweiterung. Ich kann also auch nicht einfach das Projekt neu packen.

Nun möchte ich gerne die beiden Workaround-Klassen in die bestehende Erweiterung einpflegen.
Wie mache ich das?

Kann ich die beiden neuen Klassen einfach compilieren und dann mit einem Dateimanager in das .jar-Archiv der Erweiterung einfügen (und damit die "defekten" Klassen ersetzen) oder ist das nicht möglich? (wenn nein, würde mich auch interessieren, warum nicht - einfach für mein persönliches Verständnis als Umsteiger auf Java und Javaumgebungen)

Gruß

 

[Natac]

Kann ich die beiden neuen Klassen einfach compilieren und dann mit einem Dateimanager in das .jar-Archiv der Erweiterung einfügen (und damit die "defekten" Klassen ersetzen) oder ist das nicht möglich? (wenn nein, würde mich auch interessieren, warum nicht - einfach für mein persönliches Verständnis als Umsteiger auf Java und Javaumgebungen)

Ich würde behaupten das kommt darauf an, ob das jar signiert ist oder nicht.

Wenn du im MANIFEST-Ordner nur die Datei MANIFEST.MF geht es auf jeden Fall.

 

[turtle]

Zur Lösung wurden mir zwei neue Klassen als Workaround geschickt, welche die alten ersetzen sollen

Das legt wohl nahe, das der Tausch der Class-Dateien in der JAR das Problem beheben sollte, oder?

 

[SimProtect]

Es lag für mich durchaus nahe, allerdings war ich mir nicht sicher, ob das bei Java-Files einfach so möglich ist. Ich arbeite noch nicht so lange mit Java und hatte mich bisher mehr mit der Syntax und den Möglichkeiten der Sprache selbst befasst, als mit dem Aufbau solcher Archive.

Ich kenne das aus anderen Umgebungen, in denen einer einmal gepackten 'assembly' oder auch einer Bibliothek nur noch unter ziemlichen Aufwand etwas hinzugefügt werden konnte. Da war meistens da neu-packen Mittel der Wahl - wozu natürlich die Source-Files hätten vorhanden sein müssen.

Danke für Eure Antworten

Allerdings habe ich immer noch ein Problem:
Die Workaround-Klasse liegen als .java-Dateien vor - also als Sourcefiles. Den Befehl "javac" kann ich allerdings nicht anwenden, da der Compiler zahlreiche Fehler feststellt - liegt offensichtlich daran, dass sämtliche Referenzen auf die anderen Klassen der Erweiterung fehlerhaft sind. Die liegen ja bereits in der fertigen, aber fehlerhaften Erweiterung...

Kann ich die irgendwie unfallfrei compilieren und dem Compiler sagen, er solle die Fehler ignorieren? (nachdem die fertigen .class-Files eingebunden sind, müssten ja eigentlich alle Referenzen passen)
Oder gibt es eine andere Möglichkeit?

Gruß

 

[turtle]

Kann ich die irgendwie unfallfrei compilieren und dem Compiler sagen, er solle die Fehler ignorieren?

Was bezeichnest du denn als "unfallfrei"? Offensichtlich ist doch der Compiler wohl der Ansicht, das da Fehler enthalten sind, dieses bezeichne ich als grösseren Unfall, oder?

Daher hast du auch keine richtigen Class Datei erzeugt und kannst also die Datei(en) in der JAR nicht tauschen.

Also ist das Erste was du tun musst, fehlerfrei Kompilieren der Klassen. Meine Vermutung ist, das die bestehenden Klassen notwendig sind. Wahrscheinlich musst du also die "alte" JAR als Lib deinem Projekt hinzufügen.

DANACH kannst du in der JAR die Dateien austauschen und da JAR nichts anderes als ZIP-Dateien sind, kannst du das mit jedem Tool machen, was du angemessen hältst. Ich nehme üblicherweise 7-Zip.

 

[SimProtect]

Ich hatte gehofft, ich könne dem Compiler irgendwie einen Parameter mitgeben und damit sagen: ignoriere die Fehler und mache in .class-File daraus. Muss aber selbst einsehen, dass das nicht wirklich zielführend / durchführbar wäre :-D

Das ist auch meine Vermutung. Wann steht eine Klasse schon mal für sich alleine? Eher selten.

Ich werde Deinen Weg mal anwenden - ich frag mich ja, warum die Torfnasen, die den Workaround geschrieben haben, nicht soweit gedacht haben. Immerhin entwickeln die regelmäßige solche Workarounds. Ich meine, sie müssen ja die source-Files haben - sonst wäre die Entwicklung schwierig gewesen. Na ja, sei es drum. Gleich für die zukunft gelernt, dass mir das nicht passiert

 

[turtle]

ich könne dem Compiler irgendwie einen Parameter mitgeben und damit sagen: ignoriere die Fehler und mache in .class-File daraus

:lol:
Diesen Schalter nenne ich immer DWIM (do-what-I-mean)

 

[Barista]

Prinzipiell sind Jar-Dateien Zip-Dateien.

Ich weiss nicht, ob Du das wusstest.

Du kannst die also einfach auspacken.

Dann könntest Du statt der Jar-Datei die ausgepackten class-Dateien verwenden.

Falls das Programm verteilt/verkauft wird, keine praktische Lösung.

Zum JDK gehört ein Jar-Tool, damit kannst Du auch selbst Jars bauen.

Die IDEs sollten so was auch können, ich nutze Eclipse, dort findet man einen entsprechenden Menüpunkt unter Projekt - Export.

Solltest Du (Deine Firma/Auftraggeber) für den Code in den Jar-Dateien bezahlt haben,
solltest Du eine Korrektur-Lieferung verlangen.

Dies ist auch rechtlich korrekt.

 

[SimProtect]

:lol:
Diesen Schalter nenne ich immer DWIM (do-what-I-mean)

Huch, meine Antwort von vorhin ist wohl leider nicht gesendet worden.
Zunächst einmal habe ich über den DWIM wirklich lachen müssen :-D
Ich hatte mein Hirn offenbar woanders. Natürlich weiß ich grob wie ein Compiler arbeitet und funktioniert und hätte wissen müssen, dass sowas unmöglich ist. *sich ein Holzbrett vor den Kopf schlägt*

Das Problem ist mittlerweile auch gelößt: Ich habe mich direkt an die Entwickler des Frameworks und der Erweiterung gehalten. Wir haben jetzt einen SVN-Zugang zu den Source-Files.
Mit freundlicher Genehmigung nutzen wir jetzt direkt die Source-Files, was natürlich auch künftige Änderungen einfacher macht

Hallo Barista,
Danke auch für Deine Antwort
Also, dass .jar-Datein wie zips behandelt werden, wusste ich. Ich bin kürzlich erst auf Java umgestiegen, habe aber schon ein paar Jährchen mit Programmierung zu tun. Beim Umstieg gab es einen Crashkurs. Aber natürlich hat mich sich nicht alles gemerkt und - leider - auch nicht überall aufgepasst :-D
Ich bin mittlerweile mit der Syntax der Sprache selbst und vielen Möglichkeiten ganz gut zu Hause - aber gut, das meiste gibt es ja in den anderen Sprachen auch, wird nur etwas anders geschrieben usw.
Auch ein paar Grundlagen in Eclipse laufen eigentlich (dazu gehören u.A. Import, Export, Addons, Buildpaths und so Späße) ganz gut. Aber es wird noch ein wenig dauern, bis ich da ganz zu Hause bin.

Im letzten Jahr habe ich z.B. kaum objektorientiert gearbeitet, sondern rein imperativ. Daran musste ich mich auch erstmal wieder gewöhnen.