My newest toy (a preprocessing bean @Property annotation)
It works with javac6, (although you can cross-compile java5 code with it). Trying out some IDEs to see how well it works before trying to release it for wider consumption. (Of course, I realize this is against the JSR269 specification -- no preprocessing...)
[pfnguyen@ares panno]$ ls
A.java B.java
[pfnguyen@ares panno]$ cat A.java
import com.hanhuy.panno.Property;
publicclass A{
private @Property String fool ="I pity the foo!";
private @Propertyboolean alwaysRight =false;
}
[pfnguyen@ares panno]$ cat B.java
publicclass B{
publicstaticvoid main(String args[]){
A a =new A();
System.out.println(a.getFool());
a.setFool("I am not a fool");
System.out.println(a.getFool());
System.out.println(a.isAlwaysRight());
a.setAlwaysRight(true);
System.out.println(a.isAlwaysRight());
}
}
[pfnguyen@ares panno]$ javac -classpath ~/development/panno/build/hanhuy-panno.jar *.java
[pfnguyen@ares panno]$ java B
I pity the foo!
I am not a fool
false
true
[pfnguyen@ares panno]$ javap A
Compiled from"A.java"
publicclass Aextends java.lang.Object{
public A();
publicvoid setFool(java.lang.String);
public java.lang.String getFool();
publicvoid setAlwaysRight(boolean);
publicboolean isAlwaysRight();
}
[pfnguyen@ares panno]$
http://www.hanhuy.com/pfn/java_property_annotation
[edit: obligatory remark about jsr269]
Message was edited by:
pfnguyen
[2807 byte] By [
pfnguyena] at [2007-11-27 2:53:19]
# 1
> It works with javac6, (although you can cross-compile
> java5 code with it). Trying out some IDEs to see how
> well it works before trying to release it for wider
> consumption. (Of course, I realize this is against
> the JSR269 specification -- no preprocessing...)
Hmm, specifically the Filer has rules about overwriting files. We might have to implement some more aggressive checks we've thought of :-)
To get these effects without overwriting "revision controlled" source or class files, we recommend using a variant of the decorator pattern (see earlier threads in the forum) or using a tool like Jackpot (jackpot.netbeans.org/ ) if you do want to modify revision controlled files.
# 2
> Hmm, specifically the Filer has rules about
> overwriting files. We might have to implement some
> more aggressive checks we've thought of :-)
>
> To get these effects without overwriting "revision
> controlled" source or class files, we recommend using
> a variant of the decorator pattern (see earlier
> threads in the forum) or using a tool like Jackpot
> (jackpot.netbeans.org/ ) if you do want to modify
> revision controlled files.
The Filer doesn't seem to have rules about overwriting files, (I tried using it and it overwrote and wiped out my original source file, oops). However, modifying the source file in that manner is after the analyze stage, which results in javac not compiling the modified code.
I went through many approaches trying to get the modified code compiled, I tried replacing the file mid-compile, tried modifying the cached JavaFileObject.getContent() within the Context, etc.
Finally, I accessthe parsed AST generated by javac and modify that directly, in memory; javac produces the desired code with that approach.
My implementation:
http://svntrac.hanhuy.com/repo/browser/hanhuy/trunk/panno/src/com/hanhuy/panno/processing/PropertyProcessor.java
(this was written based off of jad decompiled code of the java6 javac, I didn't know about openjdk at the time.....)
# 3
> > Hmm, specifically the Filer has rules about
> > overwriting files. We might have to implement
> some
> > more aggressive checks we've thought of :-)
> >
> > To get these effects without overwriting "revision
> > controlled" source or class files, we recommend
> using
> > a variant of the decorator pattern (see earlier
> > threads in the forum) or using a tool like Jackpot
> > (jackpot.netbeans.org/ ) if you do want to modify
> > revision controlled files.
>
> The Filer doesn't seem to have rules about
> overwriting files, (I tried using it and it overwrote
> and wiped out my original source file, oops).
> However, modifying the source file in that manner is
> after the analyze stage, which results in javac not
> compiling the modified code.
[snip]
The Filer doesn't let you open the same type twice within the filer. A requirement is that you can overwrite a previously generated output file. A goal would be to not let you overwrite "originating" files that were under source code management. The difficulty is telling the two kinds of existing files apart. A configuration recommendation is to always set the output directory to something different than the classpath.
Such a configuration would allow an additional check; if the type already exists (because it is on the classpath) don't let the file be overwritten; otherwise, if there is only a file in the output directory, let the file be overwritten.
