Reflection Problem

[AccountJava123]

Hallo,

zu meinem Problem: Ich benutze eine API. Es existieren dort mehrere Konstruktor in einer Klasse. Mein Problem jedoch ist, dass ein Konstruktor eben die Annotation @NotNull hat, d.h. ich kann in der Regel diese weglassen (zumindest in der API), das funktioniert auch (ohne Reflection).

So sieht es aus:
http://prntscr.com/bjk6uj

Das Problem an der Sache ist, wenn ich eine neue Instanz ohne Reflections erstelle, dann kann ich den 2. Parameter weglassen. Das ist ja an sich kein Problem.
Aber dasselbe funktioniert leider nicht mit Reflections. Ich habe probiert, den zweiten Parameter "null" zu setzen, jedoch hat dies nicht wirklich etwas gebracht.

An sich verstehe ich die Logik von NotNull überhaupt gar nicht.
Ich habe eine kleine "API" geschrieben:

public class ReflectionUtil {

    public ReflectionUtil( String name, @NotNull String s ) {
     
    }

    public static class Reflect {

    }
 
}

Dieser Code ist in einer externen Jar und ich verwende es als API. Ich möchte es eben testen. Das Problem jedoch ist, ich habe 2x @NotNull Imports zur Verfügung. Ich habe beim ersten Mal von com.sun.istack.internal.NotNull, beim zweiten Mal com.avaje.ebean.validation.NotNull-

Der 2. Import funktioniert leider nicht, wie ich es will. Der erste Import funktioniert, aber dann habe ich eben folgendes Problem:
http://prntscr.com/bjk9j2

Wie Sie sehen, wurde irgendwie alles vertauscht ("komisch verändert worden"), obwohl ich nur beim zweiten Parameter @NotNull gesetzt habe.

Ich habe versucht, die eigentliche API zu decompilen, habe jedoch keine Annotations gefunden. (IntelliJ Decompiler + JD Gui getestet)

Kann mir einer bitte helfen? Warum ist es vertauscht? Warum funktioniert dort keine Reflection mit einem Parameter (die eigentliche API)?

Danke im Voraus,

LG

 

[mrBrown]

Erstmal müsste man wissen, welche @NotNull dort verwendet wird, die haben alle unterschiedliche Funktionen. Wahrscheinlich ist das nur ein Hinweis für statische CodeAnalyse, hat also nichts mit deinem Problem zu tun - sagt aber aus, das niemals null übergeben werden darf.

@Nullable ist das Gegenstück (eines) @NotNull, deshalb taucht es überall auf, wo nicht (das passende) @NotNull gesetzt ist, du benutz also höchstwahrscheinlich ein falsches - nämlich den für Validation, nicht für CodeAnalyse.

Warum willst du überhaupt Reflection verwenden?
Mit einem Parameter funktioniert es nicht, weil es die Methode mit einem Parameter eben nicht gibt.

 

[AccountJava123]

Danke erstmal für deine Antwort.
Das merkwürdige an der Sache ist eben, dass nur 3 Konstruktoren existieren.
1x ohne Parameter
2x 2 Parameter

Ich kann aber die Instanz mit einem Parameter erstellen, dank dem Annotation.
Beim Decompilen sah ich keine Annotations oder ähnliches, aber beim Aufrufen des Konstruktors wird, wie oben schon beschrieben, @NotNull angezeigt, trotzdem kann ich das einfach weglassen. Ich hatte es auch mit Nullable probiert, bringt trotzdem leider nichts.

Ich habe alle Imports getestet, die es für die beiden gibt.

Der Grund, warum ich das für Reflections schreiben will: Es soll quasi ohne Imports alles laufen. Falls die API geupdated wird, dass ich da später keine Probleme mehr habe.
(Versionsnummer & uvm.)

 

[mrBrown]

Mit welcher IDE arbeitest du? UU sind die automatisch von der IDE ergänzt, und in der API nicht vorhanden.

Ich kann aber die Instanz mit einem Parameter erstellen, dank dem Annotation.

Du rufst also einen Konstruktor auf, der so gar nicht existiert?
Kannst du mal Code zeigen? Sowohl deinen (funktionierenden Aufruf), also auch die aufgerufenen API-Methoden.

Der Grund, warum ich das für Reflections schreiben will: Es soll quasi ohne Imports alles laufen. Falls die API geupdated wird, dass ich da später keine Probleme mehr habe.
(Versionsnummer & uvm.)

Mit Reflection wirst du vermutlich in wesentlich mehr Probleme laufen.
imports etc sollten sich durch Versionsupdates nicht ändern - und wenn sich doch was größeres ändert, funktioniert auch mit Reflection nicht mehr

 

[AccountJava123]

Ich benutze IntelliJ.

Du rufst also einen Konstruktor auf, der so gar nicht existiert?
Kannst du mal Code zeigen? Sowohl deinen (funktionierenden Aufruf), also auch die aufgerufenen API-Methoden.

    public DataGetter() {

    }

    public DataGetter(xxx var1, xxx var2) {
        this.d = var1;
        xxx[] var3 = var2;
    }

    public DataGetter( xxx var1, Iterable<xx> var2) {
        this.e = var1;
        Iterator var3 = var2.iterator();


    }

Ich musste paar Sachen zensieren, die sind aber nicht wirklich relevant.
Aufrufen tue ich einfach mit new DataGetter( var1 ); das war's auch schon.
Der Code wird aktuell nichts bringen, da es eine große API ist und allein keinen Nutzen hat.

Mit Reflection wirst du vermutlich in wesentlich mehr Probleme laufen.
imports etc sollten sich durch Versionsupdates nicht ändern - und wenn sich doch was größeres ändert, funktioniert auch mit Reflection nicht mehr

Leider schon. Die Packages ändern sich (Versionsnummer). Ich kann aber die benutzte Versionsnummer aufrufen (wenn das Programm gestartet ist), deswegen ist Reflection quasi Pflicht.
Es ist etwas kompliziert zu verstehen.

 

[Flown]

Welchen von den beiden Konstruktoren möchtest du jetzt aufrufen?

 

[mrBrown]

Ich musste paar Sachen zensieren, die sind aber nicht wirklich relevant.
Aufrufen tue ich einfach mit new DataGetter( var1 ); das war's auch schon.
Der Code wird aktuell nichts bringen, da es eine große API ist und allein keinen Nutzen hat.

Ohne Verwendung andere externer libs wird das so in keinem Fall kompilieren^^

Leider schon. Die Packages ändern sich (Versionsnummer). Ich kann aber die benutzte Versionsnummer aufrufen (wenn das Programm gestartet ist), deswegen ist Reflection quasi Pflicht.
Es ist etwas kompliziert zu verstehen.

Eigentlich ziemlich leicht zu verstehen...Wenn die Versionsnummer im Package steht, ist die API halt schlecht programmiert. Wenn die neue API-Version kompatibel zur alten ist, sollte man die nicht einfach künstlich inkompatible machen. Und wenn sie wirklich inkompatible ist, dann müsste man es auch bei Reflection anpassen.

 

[AccountJava123]

Welchen von den beiden Konstruktoren möchtest du jetzt aufrufen?

Das Problem ist, keins von den. Wie im Screenshot (prntscr) oben zusehen ist, werden bei mir in den Parametern @NotNull angezeigt (beim 2.). Ich kann aber trotzdem eine neue Instanz mit einem Parameter erstellen.

Ohne Verwendung andere externer libs wird das so in keinem Fall kompilieren^^


Eigentlich ziemlich leicht zu verstehen...Wenn die Versionsnummer im Package steht, ist die API halt schlecht programmiert. Wenn die neue API-Version kompatibel zur alten ist, sollte man die nicht einfach künstlich inkompatible machen. Und wenn sie wirklich inkompatible ist, dann müsste man es auch bei Reflection anpassen.

Ich passe es auch in dem Reflection alles an.
Ich finde es auch schlecht, dass die Versionsnummer in dem Package drin steht, aber man kann dagegen wohl nichts machen.

 

[mrBrown]

Das Problem ist, keins von den. Wie im Screenshot (prntscr) oben zusehen ist, werden bei mir in den Parametern @NotNull angezeigt (beim 2.). Ich kann aber trotzdem eine neue Instanz mit einem Parameter erstellen.

Nein, zumindest mit den hier geposteten Konstruktoren kannst du das nicht. @NotNull/@Nullable ändern daran nichts, die haben damit nichts zu tun.

Ich passe es auch in dem Reflection alles an.
Ich finde es auch schlecht, dass die Versionsnummer in dem Package drin steht, aber man kann dagegen wohl nichts machen.

Was spricht denn dann noch für Reflection, wenn du es ehh anpassen musst (vs. anpassen der Imports, was die IDE automatisch macht)?
Offensichtlich klappt es ja grad mit Reflection ehh nicht, auf normalem Weg aber schon...

 

[tommysenf]

    public DataGetter(xxx var1, xxx var2) {
        this.d = var1;
        xxx[] var3 = var2;
    }

das kann so nicht Funktionieren. Ich vermute mal dass var2 ein Varargs Argument ist wenn der Aufruf klappt und würde daher mal versuchen den Konstruktor mit einem leeren xxx Array las 2. Argument aufzurufen.

 

[AndyJ]

Die Annotation com.avaje.ebean.validation.NotNull kann nicht als Parameter-annotation benutzt werden, zumindest wenn das der Code dafuer ist:
https://github.com/mochalov/avaje-e.../java/com/avaje/ebean/validation/NotNull.java

Das Target muesste den ElementType.PARAMETER haben damit das geht, sonst ist die einfach nicht sichtbar. Eigentlich muesste deine IDE sich darueber beschweren.

 

[mrBrown]

Die Annotation com.avaje.ebean.validation.NotNull kann nicht als Parameter-annotation benutzt werden, zumindest wenn das der Code dafuer ist:
https://github.com/mochalov/avaje-e.../java/com/avaje/ebean/validation/NotNull.java

Das Target muesste den ElementType.PARAMETER haben damit das geht, sonst ist die einfach nicht sichtbar. Eigentlich muesste deine IDE sich darueber beschweren.

Wie gesagt, es gibt verschiedene @NonNull - zb org.jetbrains.annotations.NotNull, welche dazu dient, ua bei Parametern anzugeben, das diese nicht Null sein dürfen (allerdings nur für statische Codeanalyse relevant, nicht zur Laufzeit).

 

[AndyJ]

Wie gesagt, es gibt verschiedene @NonNull - zb org.jetbrains.annotations.NotNull, welche dazu dient, ua bei Parametern anzugeben, das diese nicht Null sein dürfen (allerdings nur für statische Codeanalyse relevant, nicht zur Laufzeit).

It depends: @Retention(RetentionPolicy.RUNTIME)

 

[mrBrown]

It depends: @Retention(RetentionPolicy.RUNTIME)

Nein: @Retention(RetentionPolicy.CLASS) (zumindest bei der von mir genannten, welches auch die oben verwendete sein wird)

 

[AccountJava123]

Danke für eure Antworten.
Ich bin da leider nicht weitergekommen, also habe ich einfach den 2. Parameter benutzt, auch wenn ich da mehr verwalten musste.

 

[mrBrown]

Wird schon nen Grund haben, warum's da nen zweiten Parameter gibt, und und keinen Konstruktor mit einem

Wenn dir der aber egal ist, Kapsel das einfach hinter ner eigenen Methode