I've worked out what my confusion was: I was setting it to METHOD_ONLY and then becoming confused that the bean get method still worked as a property. Of course, this setting only affects zero-argument non-void methods which ALSO aren't bean getter methods.
I think that means that if a class was using non-bean style and has a field called isActive, then if you create a method for it called isActive, then its property name is "active", not "isActive" (even when set to BOTH_PROPERTY_AND_METHOD or PROPERTY_ONLY). i.e. It's not exposed as both "active" (from the bean property syntax) and "isActive" (from the non-bean style). I hope that's right and all as intended! Cheers, Simon On Friday, 29 March 2024 at 23:03:29 GMT, Daniel Dekany <daniel.dek...@gmail.com> wrote: > I've found that setting nonRecordZeroArgumentNonVoidMethodPolicy doesn't seem > to do anything It surely works in general (it tried it of course, and has test coverage, etc.), so give some information to figure out what the problem is. How's the relevant part of your configuration look (see https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html#version_hisotry_freemarker_183_java_side), what kind of object you have put into the data-model, and how you tried to access it in the template, and what happened? > I don't understand its default in the ClassIntrospectorBuilder. > It's currently METHOD_ONLY, but shouldn't it be BOTH_PROPERTY_AND_METHOD? In 2.3.x, no, because BOTH_PROPERTY_AND_METHOD is too backward incompatible. Also it's a debatable decision, but we don't have to deal with that dilemma at least until incompatibleImprovements can do more dramatic changes when set to 2.4.0. (That's when I thought we could just give the recommended value to everything by default. We got a lot of settings with bad historical defaults.) > Additionally, I question the name using "nonRecord" [...] both value classes > and values records seem to use non-bean style properties. Good point! It should be called defaultZeroArgumentNonVoidMethodPolicy instead. I will do that... unless someone has a better name. -- Best regards, Daniel Dekany
