Denis Koroskin: > I think "do not affect the generated code" is a bit restricting. > [...] There are endless possibilities.
Lombok gives annotations to reduce boring lines of Java code: http://projectlombok.org/features/index.html Some of those annotations: @Getter / @Setter: Never write public int getFoo() {return foo;} again. @ToString: No need to start a debugger to see your fields: Just let lombok generate a toString for you! (I think this can be automatic for D structs). @EqualsAndHashCode: Equality made easy: Generates hashCode and equals implementations from the fields of your object. @Synchronized: synchronized done right: Don't expose your locks. More info on the @Synchronized: >@Synchronized is a safer variant of the synchronized method modifier. Like >synchronized, the annotation can be used on static and instance methods only. >It operates similarly to the synchronized keyword, but it locks on different >objects. The keyword locks on this, but the annotation locks on a field named >$lock, which is private. If the field does not exist, it is created for you. >If you annotate a static method, the annotation lo cks on a static field named >$LOCK instead. If you want, you can create these locks yourself. The $lock and >$LOCK fields will of course not be generated if you already created them >yourself. You can also choose to lock on another field, by specifying it as >parameter to the @Synchronized annotation. In this usage variant, the fields >will not be created automatically, and you must explicitly create them >yourself, or an error will be emitted. Locking on this or your own class >object can have unfortunate side-effects, as other code not under your cont! rol can lock on these objects as well, which can cause race conditions and other nasty threading-related bugs.< Bye, bearophile
