To determine if DeclaredType aka class instances are falsey we generate code to check if they are null.

While that seems like a good idea in the context of Javascript in most Java codebases today things are not null and if they are it is often a serious bug. JStachio exacerbates this because it will hide it instead of failing fast like you would if you were to write rendering code manually or using more programmatic templating like JTE or Rocker.

In my opinion this violates JStachio core philosophy of being as typesafe as possible and failing as fast as possible preferable during compile time.

Thus I propose an option where we support TYPE_USE @Nullable annotations like JSpecify (not released yet), Eclipses and kind of Intellijs. Yes there are other nullable annotations that are not TYPE_USE but those are far more difficult to support (frankly that ones that do not... they are fucking wrong and is disappointing because TYPE_USE has been around since JDK 8 but I will leave that rant for another day... findbugs aka spotbugs)

What we will do is check if there is annotation is present on the DeclaredType that has a simple name of Nullable (potentially configurable) and if it is then we will do null checking otherwise it is assumed it is nonnull like a native type (and currently Optional as Optional already has this behavior).

As a side note this will increase rendering performance slightly but that is not the reason we want to do it.

This is a lot of work but worth it. I'm not sure if I can get it in before end of year which I plan on 1.0.0.

cc @sviperll

EDIT

I should go over the various level of support of nullable we want to achieve

EXHAUST_NULLABLE

Not implemented yet

Force sectioning on a nullable variable

Example:

@JStache
public record Model(@Nullable String message){}

Template code like below will fail during compilation:

{{message}}

As message could be null.

To correct it would be to do the following:

{{#message}}
{{.}} non null case
{{/message}}
{{^message}}
null case
{{/message}}

NULL_CHECK_DISABLE

✅ implemented see:
NO_NULL_CHECKING

#134 and #164

Remove conditional checking if a variable is null if it is not @Nullable

Currently anytime a section is accessed we check if its not null.

Example:

{{model.action.message}}

The code generated is roughly like:

if (model != null) { 
   if (model.action() != null) {
      format(model.action().message());
   }
}

Notice that action got called twice. It maybe a separate feature that we store the action return results as variable but it is relevant to nullable support as there is no guarantee calling the method twice will yield the same results. Furthermore the above hides potential bugs if we are expecting action to never be null.

Anyway NULL_CHECK_DISABLE turned on would yield code like:

format(model.action().message())

N.B. That NULL_CHECK_DISABLE does not necessarily need to read nullable annotations to work unlike EXHAUST_NULLABLE.

NULL_CHECK_DOTTED_PATH

Not implemented

There also could be various levels of NULL_CHECK_DISABLE in the case of dotted paths. That is maybe only the first name in path (model in this case) is checked or not checked. Or maybe non dotted paths are treated differently

For example:

{{#model}}
{{/model}}

Should generate:

if(model != null) {
}

But maybe not. If nullable annotations are not available we need to assume they are testing for null to prevent NPE and thus we would always generate the above code for an undotted name (model).

The question is what to do for:

{{#model.action}}
{{/model.action}}

Should model only be checked? Should model and action be checked? Should only action (last in dotted name) be checked?

Need to get feedback. EXHAUST_NULLABLE is not going to work at the moment or anything that needs to absolutely confirm something is nullable as TYPE_USE annotations are not available across compile time boundaries unless we do some --add-modules hacks to load up Symbol.

Furthermore a separate feature that overlaps is storing property accessors on the stack as variables to avoid repeatedly calling the accessor methods.