Verwirrungsverhalten bei Java -Standardmethoden in Kombination mit Reflexion, irgendwelche Ideen? ⇐ Java

[Anonymous]

Ich stieß in einem Problem auf, wenn ich Groovy in Kombination mit dem neuesten Hapi -Fhir verwendete. Die Klassenreferenz implementieren diese Schnittstelle und überschreiben die Methode. Debugger zeigt, dass TestCase 1, die Reflexion auf die Standardmethode der Schnittstelle (die NULL zurückgeben) und der TestCase 2 auf den GetIdentifier der Klasse aufgerufen wird. < /P>

Code: Select all

import static org.junit.jupiter.api.Assertions.assertNotNull;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

import org.hl7.fhir.r4.model.BaseReference;
import org.hl7.fhir.r4.model.Identifier;
import org.hl7.fhir.r4.model.Reference;
import org.junit.jupiter.api.Test;

public class ReflectionTestOnSuperMethods {

@Test
public void testJavaReflection1() throws NoSuchMethodException, SecurityException, IllegalAccessException, InvocationTargetException {
var example1 = new ExampleDto1();
Identifier id = new Identifier();
id.setValue("abc");
example1.setIdentifier(id);

Method method = BaseReference.class.getMethod("getIdentifier");
assertNotNull(example1.getIdentifier());
assertNotNull(method.invoke(example1, new Object[0]));
}

@Test
public void testJavaReflection2() throws NoSuchMethodException, SecurityException, IllegalAccessException, InvocationTargetException {
var example2 = new ExampleDto2();
Identifier id = new Identifier();
id.setValue("abc");
example2.setIdentifier(id);

Method method = BaseReference.class.getMethod("getIdentifier");
assertNotNull(example2.getIdentifier());
assertNotNull(method.invoke(example2, new Object[0]));
}

public static class ExampleDto1 extends Reference {
/*public Identifier getIdentifier() {
return super.getIdentifier();
}*/
}

public static class ExampleDto2 extends Reference {
public Identifier getIdentifier() {
return super.getIdentifier();
}
}

}

Das TestCase -Projekt wird jetzt unter:
https://github.com/thopap/reflectionest/
Kann jemand erklären, warum der Bevavior hier unterschiedlich ist? "GetIdentifier" zeigt
public org.hl7.fhir.r4.model.identifier org.hl7.fhir.r4.model.Reference.getIdentifier ()
öffentlicher Standard -Standard org.hl7.fhir.instance.model.api.icomposittype org.hl7.fhir.instance.model.api.ibasereference.getIdentifier () < /p>
Inspektionsuntersuchung für "getIdentifier" Shows
öffentlich org.hl7.fhir.r4.model.Identifier de.thopap.example.reflectionTestonSuperMethods $ explodThe2.getIdentifier ()
public org.Hl7.fhir.instance.model.api.icompositetype de.thopap.example.reflectionTonSuperMethods $ psalePledTo2.) /> Hintergrund
Das Problem wurde ursprünglich in einem Testpase von IPF (https://github.com/oehf/IPF) identifiziert. Beim Versuch, auf Hapi FHIR 8.4 zu aktualisieren, schließen einige groovige Tests fehl. Nach dem Drill-Down stellt Hapi die Standardmethode in 8.4 ein. org.hl7.fhir.r4 < /li>
< /ul>
Jetzt wurde die Standardmethode zur Schnittstelle hinzugefügt, aber die Implementierungsklasse wurde nicht mit dieser Version neu kompiliert. Es sieht so aus, als ob Java die Bytecode beim Implementieren einer Methode aus einer Schnittstelle verbessert. Aber wenn diese Definition während der Zusammenarbeit nicht vorhanden war, kann sie jetzt während des Reflexionszugriffs Probleme verursachen. />https://docs.oracle.com/javase/specs/jl ... l#jl-15.12
Ist meine Annahme hier korrekt?>