@Nullable @NotEmpty and Identifiers (and the like)

[Chad La Joie]

Right.  That annotations needs to be truthful.  In the example you give,
getThing() can return null at some points in time, so @Nullable is
appropriate.  If you put an empty check in the setter, then you could
add @NotEmpty as well.

If getThing() should never be nullable then it either needs to be passed
in at construction time or you need a builder for producing Foos.  What
initialize(), validate() or any other such method checks and errors out
on is orthogonal to those annotations.

On 4/17/12 10:28 AM, Rod Widdowson wrote:
> So here's a question, mostly for Chad.
> 
> As I've been working through the IdP unit tests I've been adding the obvious Annotations to code which predates the conventions in
> https://wiki.shibboleth.net/confluence/display/DEV/Java+Coding+Conventions being solidified.
> 
> A pretty common paradigm is:
> 
> class Foo extends AbstractInitializableComponent {
> 
>   private String thing;
>  
>   public String getThing() {...}
> 
>   public void setThing(String newThing) {...}
> 
>   public void doInitialize() { 
>     ...
>     if (null == thing) {
> 	throw("thing cannot be null of empty");
>     }
> 
> }
> 
> 'thing' is often the identifier, but not always.
> 
> My question is, with what annotation should getThing() be garnished? Strictly speaking it should be @Nullable, but we do add the
> test to make sure that after initialization it will never be null or empty.  There is obvious code and/or annotations which can be
> added to make sure that getThing() will never return null with that in place stage we could make getThing @NonNull @NotEmpty.
> 
> But should we or do we just live with getThing() being @Nullable.
> 
> Note that I am *NOT* proposing that we add a new annotation.
> 
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net