[BUG][JAVA] Field generation boolean vs Boolean, is vs get getter

[fafee-io]

The current code always generates boolean fields with the wrapper type, as Boolean, while at the same time sets the getter to be "is" as in: isMyBooleanField().

This is the worst combination of behaviours, because the "is" getter should only be used with the primitive version of the type. The code does nothing to determine which should be used, the default 'boolean' -> 'Boolean' .typeMapping entry gets triggered from the default getTypeDeclaration method, and then the only possibility for boolean fields is to have the getter set with the prefix "is", from the toBooleanGetter method.

This causes the generated model classes to behave incorrectly when used with stuff that expects the standards, for example BeanUtils, BeanWrapperImpl of Spring, or indeed most everything (that expects the "get" getter due to the wrapper type Boolean). The boolean fields are either deemed inaccessible or simply skipped because these implementations don't find the getter.

This is referenced in a number of issues:
7764
7261
7617
Some of these are very old and for 2.x this PR suggests a few methods, by changing the template.
The current template code in pojo.mustache no longer looks like this, and also, users shouldn't have to change the templates just to get the correct behaviour.

[scara]

+1

get in the getter is also required to let @NotNull work as expected: using is doesn't trigger the validation as expected being a boolean not nullable.

HTH,
Matteo

[fafee-io]

I went ahead and made the correction as seen in the PR.

Unfortunately, due to the fact that the pre-existing method toBooleanGetter() only gets the name of the field, the logic to determine "is" vs "get" couldn't go there.
Again unfortunately, the very large method fromProperty() wasn't yet overriden in AbstractJavaCodegen from the defaults and in it, the getter is technically determined earlier than the type (datatypeWithEnum - this is used in the pojo.mustache template) - so I ended up doing what you can see in the commit.
To me this seems like a very java specific thing, so changing the interface for toBooleanGetter() or messing with the default fromProperty () felt like a bad idea.