A recent commit contains:
> + @PluginAttribute(value = "blocking", defaultValue = "true") > final boolean blocking, > Using a String default for a non-string attribute seems like a punch in the eye ;-) This really feels unnatural. Currently, I cannot say: @PluginAttribute(value = "blocking", defaultValue = true) final boolean blocking, @PluginAttribute(value = "someInt", defaultValue = 123) final int blocking, That would require the annotation attribute's defaultValue to be typed as an Object which is illegal. I suggest: @BooleanPluginAttribute(value = "someBool", defaultValue = true) final boolean blocking @IntPluginAttribute(value = "someInt", defaultValue = 123) final int blocking If not, then at least say: @PluginAttribute(value = "blocking", defaultValue = TRUE) and do a static import of TRUE from our Strings class (assuming you'd add TRUE to Strings). If we are going to do typed configuration with a custom annotation mechanism it seems inevitable to have to go with IntPluginAttribute, and so on. Using mixed types looks very odd. Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
