> 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. On Fri, Mar 29, 2024 at 8:20 PM Simon Hartley <[email protected]> wrote: > > I've found that setting nonRecordZeroArgumentNonVoidMethodPolicy doesn't seem > to do anything (set via Configuration.setSettings). > > I don't understand its default in the ClassIntrospectorBuilder. > It's currently METHOD_ONLY, but shouldn't it be BOTH_PROPERTY_AND_METHOD? > > Additionally, I question the name using "nonRecord". > If I look the current preview JEP for value classes > (https://openjdk.org/jeps/401), > the examples for both value classes and values records seem to use non-bean > style properties. > > Cheers, > Simon > > > > On Monday, 18 March 2024 at 07:50:08 GMT, Daniel Dekany > <[email protected]> wrote: > > > Anyone else is planning to do more about this? Note that it can be > useful to try it on multiple Java versions (like on 8, 11, 17 - the > actual expected break points are 8, 9, 16). -- Best regards, Daniel Dekany
