Annotation für "NativeAccess"

[Spacerat]

Hallo...

Bin neu hier... Zumindest was Annotations angeht. Ich habe da immer so ein problem mit privaten Methoden in einer Klasse, die von der Klasse selbst nicht aufgerufen werden. Eine diesbezügliche Warnung kann man ja mit "Supress Warnings" unterbinden. Die Existenzberechtigung erhalten diese Methoden dadurch, das sie über JNI noch aufgerufen werden können (wohl auch der Grund, warum sie mitkompiliert werden). Ich finde "SupressWarnings("unused")" trifft hier nicht mehr zu. Deswegen möchte ich für diese Zwecke eben eine eigene Annotation (@NativeAccess) kreieren, die letztenendes nichts weiter tut als SupressWarnings.
Die Klasse:

public class Jabbel
{
    @SupressWarnings("unused")
    private Schronk harbsch()
    {
        Schronk rc = new Schronk();
        // die lustigen Platzhalter sind grad' aus...
        return Schronk();
    }
}

soll dann so aussehen:

public class Jabbel
{
    @NativeAccess
    private Schronk harbsch()
    {
        Schronk rc = new Schronk();
        // die lustigen Platzhalter sind grad' aus...
        return Schronk();
    }
}

Die IDE (z.B. Eclipse) soll dann genau wie SupressWarnings die Warnung nicht Anzeigen.

mfg Spacerat

 

[Landei]

Ich kann mir nicht vorstellen, dass das funktioniert. Bei Annotations gibt es keine Vererbung, also fällt das schonmal weg. Und wie willst du Eclipse sonst beibringen, was das heißen soll? Und selbst wenn es Eclipse weiß, was machen andere IDEs, und was sollen sich andere Leute bei deinem Code denken?

SuppressWarnings hat eine klar definierte Bedeutung, also warum nicht nehmen? Notfalls kannst du ja deine eigene Annotation zusätzlich dranschreiben, oder mach einfach einen Kommentar.

 

[Spacerat]

was sollen sich andere Leute bei deinem Code denken?

Du weist schon was das Java Native Interface (JNI) ist? Die anderen Leute sollen nicht denken, dass eine derartige Funktion "unused" ist, denn das ist sie keineswegs. Sie sollen vielmehr wissen, das sie vom JNI aufgerufen wird. Fakt ist, das sie benötigt wird. Und wenn irgend so ein Fanatiker derartige Dinge entfernt, gibts ein Problem (nicht mit mir, aber mit der Software ). Deswegen sollte dort @NativeAccess statt @SupressWarnings("unused") stehen. Wie gesagt... Annotations sind absolutes Neuland. Deswegen weis ich z.B. auch nicht, wozu sie sonst Gut sein könnten, wenn nicht für diesen Zweck. Das heisst nu mehr oder weniger: Ich will nicht wissen das es Funktioniert, sondern vielmehr wie. Von Vererbung war auch nie die Rede.

mfg Spacerat

 

[Tobias]

Es funktioniert nicht. Und @SuppressWarnings("unused") bedeutet gerade "Unterdrücke die 'Unused'-Warnung, denn diese Methode (Parameter, etc) ist SEHR WOHL in Gebrauch!".

 

[Landei]

SpaceRat, bitte erleuchte mich: Werden JNI-Aufrufe nicht mit dem Schlüsselwort native gekennzeichnet, und werden in diesem Fall die unused-Warnungen nicht unterdrückt?

 

[Spacerat]

Sicher hast ja Recht... (JVM->JNI) Aber nein... hier ist die andere Richtung gemeint (JNI->JVM). Es geht darum, das in einer Java-Klasse eine private Methode deklariert wird und die Klasse selber aber nicht darauf zugreift. In der IDE erscheint dann eine Warnung, die mit SupressWarnings("unused") unterdrückt werden kann. "unused" passt hier aber in keinem Fall! Aber Tobias sagte es schon: Die Methode ist sehr wohl in Gebrauch (wenn man es genau nimmt hat er sogar Recht: supress; engl. "unterdrücke"). Das JNI kann diese Methode nämlich noch erreichen. Solche Konstrukte sind beim JNI auch alles andere als selten, wenn es z.B. darum geht ein "Handle" in einer Java-Klasse zu speichern, worauf man innerhalb der JVM nicht zugreifen darf. Ich habe solche Dinge in irgendwelchen Quelltexten immer gerne gelöscht... bis ich mich mit dem JNI beschäftigt habe. Hatte mich bis dahin immer gewundert, wieso die Betroffenen Apps nicht liefen...

mfg Spacerat

 

[foobar]

Benutz SupressWarnings und schreib nen Javdoc aus dem hervorgeht was die Methode macht z.b. daß diese von JNI verwendet wird. Ist doch wohl die sauberste Lösung.