Standard Klassen "überlagern"

[heinzepreller]

Hi,

in unseren Java Projekten werden leider immer wieder wenns hart auf hart kommt Klassen aus Bibliotheken "überlagert" (und nein ich meine keine Ableitungen).

D.h. man bastelt sich eine neue Klasse mit der gleichen Signatur wie die die man modifizieren will (gleicher Name und package Pfad) und veranlasst sie außerdem dass sie vor allen anderen Klassen und jars geladen wird.

Und nun kann man nach Herzenslust darin rummurksen weil die Murks Klasse ja die aus der Bibliothek überlagert.

Diese "Technik" hat leider X Haken wie sich jeder Denken kann und die Anzahl dieser "Überschattungen" erhöht sich ständig.

Mein großes Problem ist wie kann ich diese bösen Klassen ausfindig machen. Ich weiß leider nicht mal obs für diese Art von Bananencode Hack eine offizielle Bezeichnung gibt.

Was besseres als Überschattung oder Überlagerung ist bislang noch niemandem eingefallen.

Kennt jemand den Begriff dafür und/oder ein Tool/Bibliothek mit der man sowas aufspüren kann ?

bin für jede Hilfe dankbar

heinzepreller

 

[Joker]

kannst du mal ein Beispiel posten? Überschattung hab ich persönlich noch nie gehört und ob du mit Überlagern Überschreiben meinst (steht @Override drüber?) oder Überladen oder was ganz anderes könnte man auch nur erraten Am besten klärst du erstmal die Begriffe auf (was Überladen und Überschreiben sind findest du z.B. http://www.softwareacademy.de/java/JAVA-Training/Default.aspx?Java=110 )

 

[Gast]

man kann java "bescheissen", indem man den voll qualifizierten namen einer klasse so hindreht, dass sie in denselben namensraum externen klassen eingebunden wird. so kann man z.b. auf protected / package scope methoden von klassen aus externen libraries zugreifen. das ganze ist aber wirklich ein unglaublich ekliger hack und soweit mir bekannt, gibt es auch keine möglichkeit, das ganze zur laufzeit zu unterbinden.

 

[heinzepreller]

Hallo,

ich weiß sehr wohl was handelsübliches überlagern bzw. überschreiben ist und habe weder das eine noch das andere gemeint, da ich aber den Begriff für das was ich suche ja nicht kenne, musste ich es so umschreiben.

Ich weiß auch das diese Vorgehensweise unterste Schublade und ganz übler Stil ist aber was will mann machen es taucht halt immer wieder auf.

Ein Beispiel:

Ich habe eine beliebiege Java Applikation mit beliebiger package Struktur.

In meinem Projekt verwende ich z.B. die Xalan Bibliothek.

Sagen wir mal es wäre für mich von Bedeutung das XString aus Xalan bei der length() Methode immer "0" liefert, ich aber ansosnten die volle Funktionalität der Xalan Bibliothek nutzen kann ohne 20 Klassen abzuleiten und 10 Interfaces implementieren zu müssen.

Nun lege ich die Klasse XString im package org.apache.xpath.objects an.

Diese existiert in genau diesem package auch in der Xalan Bibliothek.

Also hol ich mir die Xalan Sourcen und bastel bei der length Methode (nehmen wir an die gitbs dort im Klartext) einfach "return 0;" hin fertig.

Beim bauen meiner Anwendung pass ich noch auf dass das jar meiner Anwenung im Classpath des Manifest vor dem xalan.jar landet und fertig. Fortan wenn meine Anwendung XString aus Xalan verwendet wird meine verpfuschte 'Xstring' Klasse benutzt.

Ich hoffe jetzt ist ein wenig klarer was ich meine.

Und mir gehts auch nicht darum diese Vorgehensweise zur Laufzeit zu unterbinden ich hätte nur gern ein Mittel/Werkzeug diese Klassen zu finden oder wüsste wenigstens ganz gerne den Namen für diesen "Beschiss".

 

[Wildcard]

in unseren Java Projekten werden leider immer wieder wenns hart auf hart kommt Klassen aus Bibliotheken "überlagert" (und nein ich meine keine Ableitungen).

Von euren eigenen Java Entwicklern? Warum? Was soll das denn? ???:L
Einen Namen kann ich dir leider auch nicht nennen, aber ich kann dir als Gegenmaßnahme OSGi empfehlen.
Da OSGi Bundles ihren eigenen Classloader Context bekommen, kann man sich nicht so einfach dazwischen setzen.

 

[heinzepreller]

Warum, kann ich dir schon sagen...

Es 10 mal bequemer einfach mal schnell auf diese Art Funktionalität zu ändern, als eine Handvoll Interfaces zu implementieren und sich einen Pfad an Abhängigkeiten entlangzuhangeln (die leider meistens auch nicht ganz klar sind).

Rein nach dem Motto: nach mir die Sintflut.

Dass man sich die Probleme damit zwar nur in die Zukunft verlagert will niemand wissen.

 

[Wildcard]

Und da schreitet weder Teamleiter, noch QA ein? Erschreckend...

 

[heinzepreller]

Ich weiß...

Aber was willst du machen wenn diese Vorgehensweise leider teilweise von den Projektleitern als legitime Technik angesehen wird.

Und damit unsere QS wirklich darauf aufmerksam wird bräuchten wir ein Tool um diese Stellen ausfindig zu machen.

 

[Wildcard]

Wie sieht's damit aus:
Schreib doch selbst ein Tool, das eure Projekte auscheckt und jede Klasse rausschreibt die nicht in eurem Namespace com.heinzeprellers.company liegt.

 

[FArt]

Es gibt Situationen, da ist es nötig, Ressourcen auszutauschen bzw. zu überlagern. Dafür gibt es sogar einen Standard. Wenn man sich daran hält, muss man auch nicht lange suchen, weil alle diese Ressourcen in besitmmten JARs und diese in bestimmten Verzeichnissen liegen.

Java Endorsed Standards Override Mechanism

Trotzdem: das Verfahren ist eine Notlösung und kein Normalbetrieb. Wenn ihr das so in der Regel betreitbt, braucht ihr euch um Qualität wirklich keine Sorgen mehr zu machen... sie ist schlichtweg nicht vorhanden.

 

[heinzepreller]

@ FArt

danke, danke, danke endlich kenn ich den Namen des Teufels.. :lol:

@ Wildcard

Das mit dem selber Tool schreiben möchte ich wenns gar nicht anders geht eigentlich immer vermeiden, jede Tool das nicht von einem selber ist muss man auch nicht warten. Deshalb hab ich auch hier gepostet..., aber trotzdem danke.

 

[Wildcard]

@ FArt

danke, danke, danke endlich kenn ich den Namen des Teufels.. :lol:

Naja, nicht ganz. Endorsed Override ist es ja nur wenn du was nach /lib/endorsed (weiche Satan) packst und das hat auch nur Einfluss auf die 'endorsed packages'.

 

[heinzepreller]

ja schon klar, hab's mir schon durchgelesen aber ich bin ja schon froh drüber wenn ich einen Begriff dafür kenne...