On Mon, Feb 13, 2017 at 5:12 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
> I agree that @Generated is awkward but I haven't suggested removing it. What do you suggest then? As far as I understood you, you were suggesting removing the module in Java 10 so the @Generated annotation would also be gone? Or did I misunderstand? > It would be useful to go through a few examples as it may be that > ACC_SYNTHETIC is more appropriate for some of these cases. > Not really. == ACC_SYNTHETIC Quote from the doc: "A class may be marked with the ACC_SYNTHETIC flag to indicate that it was generated by a compiler and does not appear in source code." == @Generated >From the javadoc: * The Generated annotation is used to mark source code that has been generated. * It can also be used to differentiate user written code from generated code * in a single file. When used, the value element must have the name of the * code generator. The recommended convention is to use the fully qualified * name of the code generator in the value field . In our case, the class is not generated by the compiler and it does appear in the source code. So it's really @Generated that we want. It's a way to document which code generator has generated the code and when. It has been created for exactly this purpose. Here are a couple of projects using it: - QueryDSL - https://github.com/immutables/immutables - https://thrift.apache.org/ - JBoss Logging - jOOQ - Bindgen And, for instance, there are static analyzers which rely on it: e.g. with https://github.com/google/error-prone, classes marked with @Generated do not report warnings. This is from a 2 minutes search on the Internet and from tools used during my career. There are a lot more out there. -- Guillaume
