Java Annotations via IDL

[GoogleCodeExporter]

We would like to have the ability to add Java annotations to fields and classes 
in the Protostuff IDL. From a protocol stand point these annotations may not 
mean much (or could they?) but from the application stand point having this 
feature would allow developers to use protostuff generated beans application 
wide. From view layer all the way to the data layer. To support this feature an 
IDL file could look something like this:

//IDL START

package protostuffsample;

option optimize_for = LITE_RUNTIME;
option java_package = "test.protostuffsample.model";
option java_outer_classname = "Model";

//Ability to import annotation classes
@Import("org.hibernate.validator.constraints.NotBlank",
"com.company.AnotherClassAnnotation")
//Ability to annotate message/classes with one or more annotation using 
//fully qualified annotation class or imported class.
@Annotate("com.company.MyClassAnnotation", "AnotherClassAnnotation")
message Greet {
  optional int32 id = 1;

  //ability to annotate field with imported annotation
  @Annotate("NotBlank")

  optional string name = 2;

  //Ability to annotate fields with multiple annotations
  @Annotate("NotBlank", "javax.validation.constraints.Size(min=2, max=32)")
  optional string message = 3;

  enum Status {
    NEW = 0;
    ACKNOWLEDGED = 1;
  }
  optional Status status = 4;
}
//IDL END

The above IDL would generate a Java class that looks something like this:

//OUTPUT START
package protostuffsample;

...

import org.hibernate.validator.constraints.NotBlank;
import com.company.AnotherClassAnnotation;

@com.company.MyClassAnnotation
@AnotherClassAnnotation
public final class Greet implements Externalizable, Message<Greet> {
    ...
    Integer id;
    @NotBlank
    String name;
    @NotBlank
    @javax.validation.constraints.Size(min=2, max=32)
    String message;
    Status status;

    ...
}
//OUTPUT END

Hopefully this feature is easy to implement because its benefits would be 
enormous.

Original issue reported on code.google.com by mark.a...@gmail.com on 30 Oct 2012 at 7:45

[GoogleCodeExporter]

...this is an enhancement request not a defect.

Original comment by mark.a...@gmail.com on 30 Oct 2012 at 7:58

[GoogleCodeExporter]

"Hopefully this feature is easy to implement because its benefits would be 
enormous."
It is easy to implement.  I've already done something similar with an internal 
library I use.

All of the hibernate validations can easily be supported.
I generally use field annotations for validation, and options for everything 
else.

Here's how it would look like:

package sample;

option raw_java_import = "
import com.company.AnotherClassAnnotation;
";

message Greet {
  option raw_java_annotation = "
  @com.company.MyClassAnnotation
  @AnotherClassAnnotation
  ";

  optional int32 id = 1;

  @NotBlank // doesn't need an import, your codegenerator already knows all the possible annotations
  optional string name = 2;

  @NotBlank
  @Size(min=2, max=32)
  optional string message = 3;

  enum Status {
    NEW = 0;
    ACKNOWLEDGED = 1;
  }
  optional Status status = 4;
}

"From view layer all the way to the data layer".  
I use it on all layers (persistence, validation, rpc, views/widgets) on both 
sides (client/server)

Original comment by david.yu...@gmail.com on 31 Oct 2012 at 3:58

[GoogleCodeExporter]

That's fantastic. The only concern is the generator knowing about possible 
annotations. This is fine for current hibernate implementation but any new 
annotations in hibernate will require the generator to be updated. Knowing all 
possible annotations is a nice convince feature but we should also let users 
explicitly import and define field level annotations.

Can you give us a time-table as to when we should expect your code to be merged 
and this feature request implemented?

Original comment by mark.a...@gmail.com on 31 Oct 2012 at 12:08

[GoogleCodeExporter]

"but any new annotations in hibernate will require the generator to be updated"
Yes, though its not really a problem for me.

"Can you give us a time-table as to when we should expect your code to be 
merged and this feature request implemented?"
There aren't any plans to merge it.  All my codegen add-ons are specific to my 
application/framework and would need some extra work to extract it.
Maybe in the future when it is more polished ... but not at the moment.

You might wanna try getting familiar with the parser/compiler api and try to 
implement something like the example I showed you.
There have been a few people on the mailing list that used the DSL for their 
internal   frameworks (some shared part of their code) 
http://code.google.com/p/protostuff/wiki/JavaBeanModelCompiler

Original comment by david.yu...@gmail.com on 31 Oct 2012 at 5:05