Spoon is Open Source software that can be used in standalone mode to validate, transform or generate Java source code and produce bytecode out of it. Unlike tools that work on bytecode only (such as Javassist or ASM), Spoon can be parameterized with source-level annotations, and access source-code level information such as comments and parameter names. Working at a source-code level, rather than at a bytecode level, allows for validation of the source code structure, which is usually more accurate to estimate its quality. Spoon provides an Eclipse plugin for better integration with the IDE, however, Spoon can be used in any IDE and NetBeans support is currently under investigation. Spoon defines a Java meta-model which is closely related to the javac AST: you can access any program element, including statements and expressions. On contrary to APT and JSR 269, this model can be accessed for both reading and writing. This allows for program modifications as well as regular processing. Spoon’s principles are close to APT’s: you will find the notion of a processor, and a visitor pattern is used to scan the program and upcall a process method when an element to be processed is found. Here is a simple example showing a Spoon processor reporting warnings when non-documented public methods are found in your program:import spoon.processing.AbstractProcessor; import spoon.processing.Severity; import spoon.reflect.declaration.CtMethod; import spoon.reflect.declaration.ModifierKind; public class JavadocProcessor extends AbstractProcessor { public void process(CtMethod m) { if (m.getModifiers().contains(ModifierKind.PUBLIC)) { if (m.getDocComment() == null) { getEnvironment().report(this, Severity.WARNING, m, "undocumented method"); } } } }It can be annoying to get a warning for each undocumented method. To implement an equivalent to the @SuppressWarnings annotation, you can modify your processor as follows:import java.util.Arrays; import spoon.processing.AbstractProcessor; import spoon.processing.Severity; import spoon.reflect.declaration.CtMethod; import spoon.reflect.declaration.ModifierKind; public class JavadocProcessor extends AbstractProcessor { public void process(CtMethod m) { SuppressSpoonWarnings sw = m.getAnnotation(SuppressSpoonWarnings.class); if (sw != null && Arrays.asList(sw.value()).contains("javadoc")) { return; } if (m.getModifiers().contains(ModifierKind.PUBLIC)) { if (m.getDocComment() == null) { getEnvironment().report(this, Severity.WARNING, m, "undocumented method"); } } } }You can then apply this processor to the following program:public class MyClass { public void test() {} // --> will report a warning @SuppressSpoonWarnings("javadoc") @Override public String toString() { // --> will not return super.toString(); } }What do you think of this project? Would the capability to access the source-level elements in an annotation processor be useful to you?

so time ago, I search a similar tool to develop a solution against get/set generation. Finally, I used ASM. But your tool seams interesting, I'll try it. Is it possible to integrate de Spoon processing into a maven or ant build ? If yes how ?

Yes, there is an Ant task: http://spoon.gforge.inria.fr/Doc/FAQ#toc6 BTW, we have a setter/getter (called fieldaccess) example in the distribution. http://gforge.inria.fr/plugins/scmcvs/cvsweb.php/spoon/examples/?cvsroot=spoon It is quite sophisticated because it uses Spoon templates. You might want to simplify it.

so time ago, I search a similar tool to develop a solution against get/set generation. Finally, I used ASM. But your tool seams interesting, I'll try it.

Is it possible to integrate de Spoon processing into a maven or ant build ? If yes how ?

Hmmm, reading your post...

Use public attribute as property, instead of private attribute and accessors methods.

That's the worst way of resolving this issue. As much as I hate the idea of getters and setters, at least you are providing a poor interface. Exposing your fields is always a horrible coupling issue and will come back to haunt you later, unless it's some trivial app. Automatic (source/byte) code get/set generators are a solution to a bigger overall problem of even using accessors and mutators. Why? One must really look at the design. Unfortunately, today, we're tied to frameworks that make use expose application state. You should see the quite large thread on this... http://www.theserverside.com/news/thread.tss?thread_id=42293

Why do we continue to use getter and setter ?

Same reason people continue to put business logic inside their JSP code? Who knows, and I personally don't care, unless they are working with me. I wouldn't event expect a junior programmer to do such a thing, but you'd be amaze how many commercial apps I've seen with such garbage. Ilya

It has been probably said, but IMO, Java is not very well suited to these kind of tricks on fields because the best way to do good design in Java is to use interfaces. If interfaces were supporting properties (or equivalent), then it would probably be less of a problem. Anyway, it is undeniable that having properties makes the business code much clearer and less relying on conventions. They have been using this for ages in VB and C# and it was never a problem :) BTW, properties are just some kind of language support to make the use of getters/setters more formal. See this: http://www.c-sharpcorner.com/Language/PropertiesInCSRVS.asp. Maybe Spoon it a good tool to support it, but I am afraid of the Java limitations on interfaces...

It has been probably said, but IMO, Java is not very well suited to these kind of tricks on fields because the best way to do good design in Java is to use interfaces. If interfaces were supporting properties (or equivalent), then it would probably be less of a problem. Anyway, it is undeniable that having properties makes the business code much clearer and less relying on conventions. They have been using this for ages in VB and C# and it was never a problem :)

BTW, properties are just some kind of language support to make the use of getters/setters more formal. See this: http://www.c-sharpcorner.com/Language/PropertiesInCSRVS.asp. Maybe Spoon it a good tool to support it, but I am afraid of the Java limitations on interfaces...

Agree, C# properties look like a clean way to support mutators/accessors. I'd almost vote for some sort of a language feature in java that allows to tie a callback to some property. It's basically as you said, the same thing, though supported through a language construct. Since it's never a good idea to expose the fields as public, as then your implementation is completely dependent upon that state. But even with C#-like support, accessors/mutators, although perfectly fine in many situations, are completely abused these days in many designs, though exposing implementation details vs. actually designing an OO domain model. Ilya

It's not the right place to talk about GetSet (it's a thread about Spoon). But : 1) Thanks to have a look at GetSet 2) I read lot of thread/forum (some are listed in the site), include "getter and setter are evils". Today an application is composed by services that don't need to expose its internal states or properties (setter are use only to inject dependency), and by data/structure that hold properties. Using public field is IMHO the most natural and pragmatic way to create data structure. I'll be please to have extra exchanges about it (on Get/Set mailing list or directly via email).

It's not the right place to talk about GetSet (it's a thread about Spoon). But :
1) Thanks to have a look at GetSet
2) I read lot of thread/forum (some are listed in the site), include "getter and setter are evils". Today an application is composed by services that don't need to expose its internal states or properties (setter are use only to inject dependency), and by data/structure that hold properties.

Using public field is IMHO the most natural and pragmatic way to create data structure.

I'll be please to have extra exchanges about it (on Get/Set mailing list or directly via email).

I wrote up a few things on my blog, we can take it from there. http://www.ilyasterin.com/enteprise_software/2006/10/yet_another_acc.html Ilya