Reflections und final

[SnooP]

Moin... - ich versuche momentan Objekte per Reflection zu kopieren (deep copy) und bin jetzt auf ein ärgerliches kleines Problem gestoßen. Normale selbstgemachte Objekte auch mit Zyklen und Referenzen auf diverse andere Objekte funktioniert ganz wunderbar - primitive Felder werden ebenfalls ohne Probleme kopiert.
Wenn ich jedoch ein Objekt kopieren möchte, welches finale Objekte enthält, wie z.B. nen Integer oder nen String (da passiert irgendwie noch was ganz besonderes...), bekomme ich von der Reflection die Fehlermeldung "Field is final", wenn ich mit field.set(theObject, value); darauf zugreifen will. Logischerweise ist das so, da ja das entsprechende Feld tatsächlich final ist und ein schreibender Zugriff darauf tatsächlich nicht gehen sollte... ich möchte aber ja auch gar nicht weiter darauf zugreifen - nur beim Erstellen des Objekts soll er das tun... wie kopiere ich also möglichst auch diese speziellen Felder mit? Any ideas?

Hat jemand Ahnung von der sun.reflect.ReflectionFactory, bzw. weiß jemand woher die überhaupt kommt? also welche library und woher ich da Infos bekommen könnte, z.B. nen javadoc würde mir schon reichen?

 

[byte]

Versuch mal vorher ein:

field.setAccessible(true);

Edit: sun.reflect.ReflectionFactory findest Du in jre/lib/rt.jar

 

[SnooP]

jo - das setAccessible mach ich schon... das bezieht sich aber nur auf private fields. Es scheint so, als ginge es für final-Fields tatsächlich nicht... - allerdings hab ich in der ReflectionFactory ne copyField-Methode gefunden, die evtl. das Feld auf einer anderen Art und Weise kopiert und das Problem umgehen könnte... - hübsch ist das alles nicht, weil ja offenbar die sun.* Klassen nicht wirklich diejenigen sein sollen, die vom "Kunden" benutzt werden sollen... aber ohne die ReflectionFactory kann man numal keine Objekte von Klassen instanzieren, die keinen parameterlosen Konstruktor besitzen... - naja ich bin gespannt wo meine nächsten Grenzen auftauchen werden

edit: wobei mich das javadoc zur set-Methode etwas wundert, wo ja drin steht, dass auch nen zugriff auf final member gehen sollte... mit genau der Anwendungseinschränkung die ich verfolge

 

[AlArenal]

aber ohne die ReflectionFactory kann man numal keine Objekte von Klassen instanzieren, die keinen parameterlosen Konstruktor besitzen...

Weshalb die Doku zu Hibernate beispielsweise auch darauf hinweist, dass zu persistierende POJOs einen solchen Konstruktor besitzen müssen, der aber auch private sein darf. Ist also kein Problem, dass alleine dich betrifft.

 

[byte]

jo - das setAccessible mach ich schon... das bezieht sich aber nur auf private fields.

Naja, nicht wirklich. Die API Doc sagt:

If the underlying field is final, the method throws an IllegalAccessException unless setAccessible(true) has succeeded for this field and this field is non-static.

Aber das ganze klappt nur für blank final Fields. Ist das Feld nicht blank, so wird zwar keine Exception mehr geschmissen, aber das Feld wird trotzdem nicht geändert. ???:L

 

[thE_29]

Was bitte bringt es ein blank Field final zu machen?!?!


final Object o = null;

Sehr sinnvoll im Programm :bae:


Nachtrag: Also bei mir geht das final Ändern:

    testoor or = new testoor();
    
    Field field = or.getClass().getDeclaredField("ing");
    field.setAccessible(true);
    System.out.println(field.get(or));
    field.set(or, new Integer(29));
    System.out.println(field.get(or));    

    field = or.getClass().getDeclaredField("in");
    field.setAccessible(true);
    System.out.println(field.get(or));
    field.setInt(or,129);
    System.out.println(field.get(or));

public class testoor{
private final Integer ing = new Integer(25);
private final int in = 125;
}

25

29

125

129

 

[byte]

Was bitte bringt es ein blank Field final zu machen?!?!

final Object o = null;

Sehr sinnvoll im Programm :bae:

Naja, das bringt in der Tat nix, aber wie wäre es denn so?

class Foobar {

  final Object o;

  public Foobar(Object o) {
    this.o = o;
  }
}

Ansonsten: Teste es mal mit Objekten anstatt primitiven Datentypen.

 

[thE_29]

Das geht net

final Variablen muss man deklarieren..

Ich krieg jedenfalls nen Fehler!

 

[SnooP]

Hmm... ja - ich habs grad nochmal getestet - die Fehlermeldung war irreführend - es geht nicht bei static final. Wobei ich mich da frage ob die variablen nicht ohnehin schon in meiner Instanz gesetzt sind, da die ja durch die klasse selbst festgelegt werden, wenn ich also vorher rausfinde, ob das entsprechende feld static ist, dann muss ich auch nicht mehr drauf zugreifen! right?

 

[thE_29]

Nachtrag:

@byto: doch geht, man musses halt in den Konstruktoren setzen!! (hatte ich vergessen..)

 

[byte]

Das geht net

final Variablen muss man deklarieren..

Ich krieg jedenfalls nen Fehler!

Dann hast Du nicht richtig getestet. Sicher müssen final Variablen deklariert werden, aber wenn sie blank sind, kann das auch im Konstruktor passieren. Dort ist es dann aber natürlich obligatorisch.

 

[SnooP]

Ahja okay - damit scheint es jetzt zu gehen... ich prüfe mit getModifiers() ob sowohl das static, als auch das final bit gesetzt ist und übergehe solche Felder entsprechend.

Das letzte Problem was ich jetzt noch bekomme ist, dass arrays nicht primitiv sind und offensichtlich gesondert behandelt werden wollen - mal gucken, wie ich die jetzt noch am sinnigsten kopiere..

 

[thE_29]

Für Arrays gibts da auch eigene Methoden!

 

[byte]

Arrays sind Objekte.

 

[SnooP]

Naja... ganz so aber auch nich ... - ich kopiere Arrays jetzt mit System.arraycopy - das funktioniert soweit auch ganz prima... - wobei ich dann nochmal gucken muss, was bei enums passiert *g* - aber das ist eine andere spielwiese

 

[byte]

Hm, enums sind implizit immer static. Die musste dann ja nicht kopieren, oder?

 

[Wildcard]

Naja... ganz so aber auch nich ... - ich kopiere Arrays jetzt mit System.arraycopy - das funktioniert soweit auch ganz prima... - wobei ich dann nochmal gucken muss, was bei enums passiert *g* - aber das ist eine andere spielwiese

Vorsicht! arraycopy funktioniert zwar für primitive Datentypen, aber wenn das Array aus Objekten besteht werden nur die Referenzen kopiert. Das musst du wohl selbst implementieren.

 

[SnooP]

Ja da hast du natürlich recht... - da muss ich mir noch was überlegen, im Prinzip müsste ich das Array nur genauso durchiterieren, wie die Felder auch... - schaun ma mal

 

[Wildcard]

Genau. Auf die Objekte eines Arrays kannst du deine Methode ja rekursiv anwenden.

 

[SnooP]

So erledigt ... - der ReflectionCopier ist fertig. Sollte inzwischen alles kopieren können. Klassen die nicht serializable sind, transient Felder, Arrays und mit enums etc. macht es auch keine Probleme.

Wer nen Fehler findet - bitte melden ... wer die sourcen haben will:
bitte hier: http://www-public.tu-bs.de:8080/~y0016815/src/Copier.zip

und viel Spaß damit ... ist auch nen gutes Stück schneller als die Serialisierungs-Methode (die auch mit dabei ist)...

Edit: soo - und jetzt sind auch die überflüssigen imports etc. draußen