# Reflektionsfrage - Dynamisch Klassen instanzieren



## H3llGhost (8. August 2010)

*Reflektionsfrage - Dynamisch Klassen instanzieren - Annotations*

Hallo zusammen,

ich schreibe zur Zeit an einem kleinen Programm, welches leicht erweiterbar sein soll.
Dem entsprechend muss ich manche Funktionen sehr dynamisch anlegen.
Damit Funktionen beschrieben werden können und ähnliches, habe ich mir eine RuntimeAnnotation angelegt, in welcher alle Informationen drin stehen, die ich auch bei der Verarbeitung benutze.

Da die Annotationklasse von der aufrufenden Klasse abhängig ist, muss ich diese auch dynamisch behandeln.

Dazu habe ich bis jetzt folgenden Code:


```
String[] cmdMethNames = this.getAvailableCommandNames();
		
		Class<?> annotationClass = Class.forName(this.annotationClassName);	
		
		for( Method meth : cmdMeth )
		{
			HashMap<String, String> tempAnno = new HashMap<String, String>();
			if (meth.isAnnotationPresent((Class<? extends Annotation>) annotationClass))
			{
				Class<?> anno = (Class<?>) meth.getAnnotation(annotationClass);
				[...]
			}
			[...]
		}
```

Jedoch in Zeile 8 bekomme ich eine Warnung, dass der Type nicht überprüft wird und in Zeile 10 gibt es folgenden Fehler: "*Bound mismatch: The generic method getAnnotation(Class<T>) of type AnnotatedElement is not applicable for the arguments (Class<capture#5-of ?>). The inferred type capture#5-of ? is not a valid substitute for the bounded parameter <T extends Annotation>*"

Meine Annotation-Klasse sieht bis jetzt wie folgt aus:

```
@Retention( RetentionPolicy.RUNTIME )
public @interface ExtendedCommandAnnotation
{
	String   annoPropUseTab() default "0";
	String   annoPropStartTag() default "";
	String   annoPropEndTag() default "";
}
```

Woran kann das liegen bzw. wie kann ich das beheben?
Danke für eure Hilfe im Vorraus!


----------



## Der Wolf (10. August 2010)

Hi,
also deine Warnung bekomme ich nicht, aber in Zeile 10 die Methode .getAnnotation liefert dir kein ClassObject zurück sondern ein Object vom Typ T ... wenn du das ClassObject haben willst müsste es also eher
Class<?> anno = method.getAnnotation((Class<? extends Annotation>) annotationClass).getClass(); 
heissen


----------



## SPiKEe (10. August 2010)

zu klären wäre jetzt wie du das mit dem dynamischen instanzieren meinst
wenn du sowas wie eine art plugin-system meinst kann ich dir hier im forum die beiträge anbieten welche sich damit befassen ... mir hats auch geholfen und ich hatte sowas änliches vor *also zur runtime dynamisch erweiterbar*
wenns nur um die dierekte erweiterbarkeit mit abhängigkeiten geht reicht es wenn du entsprechende klassen in ihre JAR files packst und diese als classpath zur runtime angibst ...
ansonsten müsstest du mal erklären was genau du mit dynamischer erweiterbarkeit meinst


----------



## Der Wolf (11. August 2010)

Was ich zum Beispiel gerade damit gemacht habe, war ein Mapping zu basteln, dass von annotierten Klassennamen auf die genaue Klassenbezeichnung schliessen kann. Also man gibt im zum Beispiel in einem XML an das man ein "MotionAttribute" braucht und dann wird im Programm per Reflection eine passende Instanz des Attributes erzeugt. Meinst du sowas? Allerdings ist das mapping im Moment auch nicht zur Laufzeit erweiterbar bei mir.


----------



## SPiKEe (12. August 2010)

dein XML-file gestütztes mapping lässt sich sehr leicht in ein system welches zur runtime veränderbar ist abändern
einfach den part in der das file eingelesen und geparst wird durch einen dynamischen loader ersetzen der vllt als initialisierung beim start noch das xml file parsed um zum. seine grund-klassen laden zu können *wobei ich core-files lieber hardcoden würde*
wie gesagt ... es gibt verschiedene ansätze für sowas ... die einen machen es halb-statisch über xml-files ... die anderen *wie ich* machens dynamisch mit nem url-loader ... wieder andere würdens vllt kombinieren oder total anders machen ...
gut : du hast nun schon den weg mit den annotations und reflection quasi durch deinen post vorgegeben ...
aber achtung : reflections sollten wenn möglich immer vermieden werden ... laut sun selbst sollten bei sowas dynamische class-loader oder statische , parseable files verwendet werden um den overhead zu minimieren
außerdem ist reflection ein sehr mächtiges werkzeug was sogar zugriffe auf als PRIVATE deklarierte daten erlaubt *für debugger und ide's notwendig*
das heißt das auch jeder andere damit deine codes selbst ohne de-compilen fast vollständig auseinandernehmen kann
du solltest dir hier wirklich eine andere methode überlegen


----------



## Der Wolf (12. August 2010)

Ja, das kann sein. Ich hab das auch mehr zum experimentieren gemacht um mal zu sehen wie man sowas angehen kann. Das war auch nur ein Beispiel für den eigentlichen Thread-Ersteller. Für mich ging es hauptsächlich darum in meinen XML-Files zu umgehen, dass ich immer den kompletten Klassennamen angeben muss. Bei meiner Anwendung habe ich es benutzt um zu deklarieren, welche Daten aus einem XML File ich welcher Variable in einer Klasse zuordnen will.
Das ganze dient wie gesagt auch als Experiment. Mit den dynamischen Classloadern oder den parseable files weiss ich gerade nicht genau worauf du dich beziehst. Vielleicht etwas neues was ich mal ausprobieren kann?  

Nebenbei hatte ich nicht vor jemanden mit meinem Beispiel zu nahe zu treten. 

Gruß
Der Wolf


----------



## SPiKEe (14. August 2010)

mit "dynamischen classloadern" meine ich dinge wie zum bleistift den URLClassLoader der es ermöglicht während der runtime normale class-files zu laden als auch ganze JAR-files *mit entsprechenden decodern natürlich auch alle anderen archiv-formate*
als parsable files beziehe ich mich lediglich auf die von dir genannten xml-files ... da du ja durch diese mit einem parser gehst der dir die daten da raus holt ... da ich gerne etwas abstract bleibe wenns um files geht bezeichne ich solche *und auch properties-files* generell als "parsable" files ... *gibt doch sicher noch mehr als XML und properties ... aber sind denke mal die gebrächlichsten .. wenn nicht > sags mir bitte =)*

zum eigentlich thread und problem zurück
da ich mich persönlich nicht mit annotations und auch nicht mit reflections *warum nicht reflections ? ... hatte es mal vor hab dann aber bei sun gelesen das man es nich machen sollte > sicherheits-probleme* befasse kann ich dir so jetzt erstmal auf dein beispiel nicht weiter helfen was du uns im ersten post geboten hast
wenn es darum geht das die files NICHT zur runtime geladen werden müssen sondern vorher angegeben werden können > die variante von wolf
wenn die files allerdings während der runtime dynamisch geladen werden müssen > sag bescheid ich kram dir meinen thread noch mal raus in dem das richtig schön breit diskutiert wurde wie man das am besten OHNE relfections macht


----------

