Reflection - Eine Library für ... Reflection

Ich weiß, es gibt schon

Aber trotzdem habe ich, streng NIH befolgend (…), mal ein paar Utility-Funktionen für Reflection in einer Library zusammengepackt:

Das meiste davon sind einfach nur Wrapper um die bestehenden Methoden, jeweils in

  • einer Unchecked-Variante, die die ganzen (checked) Exceptions in einer (unchecked) ReflectionException zusammenfasst, und
  • einer Optional-Variante, die Fehler ignoriert. (Ja, das ist “gefährlich”. Man sollte wissen, was man tut, wenn man sie verwendet).

Das einzige, was, soweit ich das überblicke, nicht in anderen libraries enthalten ist, ist die Möglichkeit, Method und Constructor-Objekte aus ihren jeweiligen String-repräsentationen zu parsen (also aus dem, was aus toString oder toGenericString rauskommt). Das ist kein Hexenwerk, aber … war eben was, was ich in meinem Zusammenhang brauchte, und da hab’ ich halt den Rest, den ich auch “so brauchte”, mal mit dazugepackt.

Benutzen wird (muss oder sollte) das wohl kaum jemand, aber … trotzdem lasse ich mal den Pointer hier.

Jetzt auch gleich in der Maven Central:

<dependency>
  <groupId>de.javagl</groupId>
  <artifactId>reflection</artifactId>
  <version>0.0.1</version>
</dependency>

Es gibt ein update. Nur mit einem kleinen Bugfix für den Method-Parser.

<dependency>
  <groupId>de.javagl</groupId>
  <artifactId>reflection</artifactId>
  <version>0.0.2</version>
</dependency> 

Auch wenn das niemanden interessiert. Ich zieh’ hier meinen shyce durch.

Und gleich noch ein update, bei dem man Typparameter-Namen in generischen Method-Strings akzeptieren kann:

<dependency>
  <groupId>de.javagl</groupId>
  <artifactId>reflection</artifactId>
  <version>0.0.4</version>
</dependency> 

Moin, aber wofür brauche ich es denn, also könntest du ein (klassisches) Anwendungsszenario beschreiben?

“Klassisch” … nun, in https://github.com/javagl/Flow kann man mit sehr wenig Aufwand Module erstellen, die nichts anderes machen, als eine bestimmte Methode aufzurufen. Und wenn man sich so einen Flow mit solchen Modulen erstellt hat, dann kann man den als XML-Datei abspeichern.

Die Frage ist nun: Was speichert man in einer Datei, um klarzumachen, dass so ein Modul einen Aufruf einer bestimmten Methode repräsentiert? Im Moment ist das eben so, dass in der Datei dann ein “instantiation string” steht, der unter anderen die method.toGenericString()-Repräsentation der aufgerufenen Methode enthält. Das ist dann z.B. so ein String hier:

"public static de.javagl.timeseries.TimeSeries&lt;java.lang.Long, java.lang.Double&gt; de.javagl.flow.modules.timeseries.ops.TimeSeriesOps.add(de.javagl.timeseries.TimeSeries&lt;java.lang.Long, java.lang.Double&gt;,de.javagl.timeseries.TimeSeries&lt;java.lang.Long, java.lang.Double&gt;)"

Und um aus so einem String dann wieder das Method-Objekt rauzuholen, gibt es in der Reflection-Lib dann eben eine Methode Methods#parseMethodUnchecked, die genau das macht.