Experience in downstream projects shows what our @Nullable annotation in getters causes a ton of grief: Eclipse with nullness analysis is throwing up a metric ton of warnings in places where non-nullness is inferred from context or is simply not expected.

For List- and Map-returning properties we already provide a sane alternative in the form of nonnullFoo(), which returns an empty List/Map.

For container-like properties we can perhaps reuse 'nonnull' prefix to return an otherwise-empty object. That should help with most of the cases, as such containers will fizzle into nothingness when they meet the datastore. This also mirrors their magic nature of disappearing.

We do not have a reasonable type to return for leaf types, as there is no content we could ever garner – hence we cannot use 'nonnull' prefix. For these we need a suitable prefix, which is TBD, and those methods should be failing if the element does not exist.

We need a short, descriptive prefix for that intent and while in other context we differentiate between imperative 'get' and java.util.Optional 'find', we are locked into a nullable getFoo() for historical reasons. A 'require' prefix is the closes I can think of, but there may be another alternative. Let's assume 'require'.

The contract of 'requireFoo()' would be such that it returns the object if it exists, but will throw a NoSuchElementException if it does not. It would be defined as a default method on the generated interface:

interface Foo extends DataObject {
    @Nullable String getBar();

    default @NonNull String requireBar() {
        return CodeHelpers.require(getBar(), "bar");
    }
}

plus CodeHelpers doing:

public static <T> @NonNull T require(@Nullable T value, @NonNull String name) {
    if (value == null) {
        throw new NoSuchElementException("Value of " + name + " is not present");
    }
    return value;
}