Implementierung von javax.annotation.processing.Filer

[Saheeda]

Hi,

mich würde interessieren, wie der Filer eigentlich funktioniert/implementiert ist. Filer selbst ist nur ein Interface und Eclipse zeigt mir dazu auch keine implementierenden Klassen an.
Aber irgendwie muss ja beim Aufruf der Methoden ne Datei erzeugt werden. Kann mir vielleicht jemand helfen?

Vielen Dank!

 

[Cymatoxa]

Ich habe nur kurz über das Thema drüber gelesen und keine Ahnung vom Großen und Ganzen - also keine Garantie für nix
Für mich sieht das so aus, als würde man, wenn man mit der Processing-Lib arbeitet, mit einer eigenen Implementierung von Processor arbeiten, bzw. von AbstractProcessor erben. Einige von den in Processor enthaltenen Methoden bekommen ein ProcessingEnvironment-Parameter übergeben, welches einen Getter für ein Filer-Objekt bereit stellt.
Ich gehe davon aus, dass die Implementierung des Filer-Interfaces private ist und man als User nur mit dem Interface arbeiten soll.

Ich hoffe das hilft. Das Thema sieht sehr interessant aus und ich werde mich auch mal etwas damit beschäftigen Vieleicht wird mir das dann klarer....
Viele Grüße

 

[Saheeda]

Hallo,

das Grundgerüst für einen eigenen Prozessor sieht so aus, ich lasse mir also nur die Referenz auf den Filer geben (bzw. arbeite nur gegen das Filer-Interface) und der Rest ist "magic".

@SupportedAnnotationTypes(value = { "de.shareil.codegenerator.annotation.MvcGenerator" })
@SupportedSourceVersion(SourceVersion.RELEASE_8)
public class MyGeneratorProcessor extends AbstractProcessor {

     private Filer filer;
    private Messager messager;
    private Class<MvcGenerator> annotationClassType = MyGenerator.class;
    private Elements elementUtils;
    private Types typeUtils;

    public MyGeneratorProcessor() {
    }

    @Override
    public synchronized void init(ProcessingEnvironment processingEnv) {
        super.init(processingEnv);
        typeUtils = processingEnv.getTypeUtils();
        elementUtils = processingEnv.getElementUtils();
        // filer = processingEnv.getFiler();
        messager = processingEnv.getMessager();

    }


    @Override
    public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {

        for (TypeElement entityClass : fetchAnnotatedClasses(roundEnv)) {
          
        }
        return true;
    }

}

Du hast mich allerdings auf eine Idee gebracht. Ich habe mir während der Generierung mal den vollqualifizierten Namen des Filers ausgeben lassen: com.sun.tools.javac.processing.JavacFiler
Nach etwas stöbern und "durchhangeln" bin ich letzten Endes hier rausgekommen:

• com.sun.tools.javac.util.JavacFileManager#getFileForOutput

Als SourceCode:

http://grepcode.com/file/repository...tion,java.lang.String,javax.tools.FileObject)


Was ich allerdings nocht nicht verstehe: Eclipse findet die Klasse weder als Implementierung von Filer, noch wenn ich explizit nach JavacFiler suche.
Trotzdem funktioniert die Generierung damit

 

[Cymatoxa]

Hi,

was hast du denn damit vor, dass die genaue Implementierung bekannt sein muss? Ein Interface ist ja unter anderem dafür gedacht, dass diese beliebig bzw. gekapselt sein kann und austauschbar ist. Bei dem Graphics-Objekt, das die draw-Methode von AWT/Swing erhält, verhält es sich wohl ähnlich. Es gibt bestimmt noch viele weitere Klassen mit diesem Muster.

Der Kommentar in JavacFiler.class sagt

This is NOT part of any API supported by Sun Microsystems. If you write code that depends on this, you do so at your own risk. This code and its internal interfaces are subject to change or deletion without notice.

Viele Grüße

 

[Saheeda]

@Cymatoxa

Die generierten Dateien sollen bearbeitbar sein. Über den Filer werden die Sachen im target-Verzeichnis abgelegt (bzw. in einem beliebigen Subverzeichnis), dieses wird aber regelmäßig gelöscht. Selbst wenn ich an den Dateien also was ändere, ist diese Änderung nicht wirklich persistent und der komplette Generator damit sinnlos.
Zudem brauche ich auch Dateien unter src/WEB-INF/...., was ich auch nach langem Probieren mit dem Standard-Filer nicht hinbekommen habe.

Aus diesem Grund habe ich mir überlegt, nicht auf den Standard-Filer zu setzen, sondern die Erzeugung der Dateien selbst zu übernehmen. Mein Code funktioniert an sich, ich bin mir nur nicht ganz sicher, ob ich mir damit irgendwelche Probleme einhandeln kann (Performance, Zugriffsrechte, etc...). Von daher wollte ich mir mal die Standardimplementierung anschauen.