Nullability annotations in the generated abstract classes

[VaibhavSavla]

Is it possible to add some nullability annotations (e.g. org.jetbrains.annotations.NotNull) to the getters and setters in the generated Abstract classes.

As an example, for the below xml attributes

<Attribute name="title" javaType="String" nullable="false" columnName="TITLE" maxLength="50" />
<Attribute name="description" javaType="String" nullable="true" columnName="DESCRIPTION" maxLength="250" />

Is it possible for the generated code to contain nullability annotations as follows

@NotNull
public String getTitle()
{
	// getter code
	return data.getTitle();
}

public void setTitle(@NotNull String newValue)
{
	// setter code
}

@Nullable
public String getDescription()
{
	// getter code
	return data.getDescription();
}

public void setDescription(@Nullable String newValue)
{
	// setter code
}

Would it be somehow possible to achieve this by extending either the MithraGenerator or the Abstract.jsp file

[mohrezaei]

Sorry, this is currently not possible. NotNull is not a standard java annotation and there are at least 7 competing ones!
It should be relatively easy to add the @NotNull annotation to the generator and a flag to turn it on. The user can then choose which variety of NotNull they want by adding an <Import> declaration.

[VaibhavSavla]

Thanks for the quick reply! Would it be possible to get this enhancement? This would help us in making our code more null safe. I am also trying to use Reladomo in a Kotlin project and these annotations would help Kotlin's type system to generate compile time errors instead of the NullPointerException and MithraNullPrimitiveException.

[nikhilnanivadekar]

To avoid the MithraNullPrimitiveException you should have a call to isNull() check generated by Reladomo.

[mohrezaei]

To expand on what Nikhil is saying, no annotation is going to help with MithraNullPrimitiveException. To look at the special null value for a primitive, you must call isFooNull() before calling getFoo(). If you're having serious issues with those, it may be because of mismatches in your database design. In most cases, primitives stored in a database should not be nullable. Your database will be happier too, because it doesn't have to store a special flag for these. In the rare cases where you want the null value to mean something special then the code pattern should always check for this special condition anyway, as above.

The standard java compiler does not support compile time checking of NotNull annotation. Using java code in a Kotlin project isn't going to generate byte code any differently either.

So as far as I can tell, this doesn't help much for your case, nor does it in general, as the only use seems to be for trivial checks in IDEs.