Re: 2.3.33 pre-vote testing
So at the end, I did this (quoting the commit message): Renamed some ZeroArgumentNonVoidMethodPolicy-es to reflect the meaning more precisely (on the expense of having really long enum names): - BOTH_PROPERTY_AND_METHOD to BOTH_METHOD_AND_PROPERTY_UNLESS_BEAN_PROPERTY_READ_METHOD - PROPERTY_ONLY to PROPERTY_ONLY_UNLESS_BEAN_PROPERTY_READ_METHOD This way it's now also true that the ZeroArgumentNonVoidMethodPolicy just specifies "How to show 0 argument non-void public methods to templates", as now all the exceptions related to Java Beans are described for the enum values. On Sun, Apr 21, 2024 at 4:51 AM Simon Hartley wrote: > I don't know if it makes sense given the method fine tuning stuff, but > here are two approaches: > 1. First choose which methods are exposed and then choose how they can be > accessed in the template, > i.e. which ones are "properties" (i.e. hash items) > 2. First determine what methods we are going to treat as properties and > then do exposure afterwards (methods and/or properties) > > Would it be clearer to rename in ZeroArgumentNonVoidMethodPolicy > so BOTH_PROPERTY_AND_METHOD becomes BOTH_HASH_ITEM_AND_METHOD ? > > For exposureLevel, we could choose to split it by adding > recordExposureLevel (defaulting to USE_DEFAULT or UNSET, with a value of > e.g. -1), > rather than adding a million variations to the existing exposureLevel > flags. > > Cheers, > Simon > > > > > On Sunday, 14 April 2024 at 12:43:50 BST, Daniel Dekany < > daniel.dek...@gmail.com> wrote: > > > > > > There's no "EXPOSE" variant for that, at the moment. We had to add > something like EXPOSE_PROPERTIES_ONLY_EXCEPT_FOR_RECORDS_AND_VALUE_TYPES, > though with a less comical and more future-proof name. > > On Sun, Apr 14, 2024 at 12:29 PM Simon Hartley > wrote: > > > > I experimented with setting: > > exposureLevel=freemarker.ext.beans.BeansWrapper.EXPOSE_PROPERTIES_ONLY > > > > This seems to prevent records from using anything but the bean > properties, > > so the components in the record don't get exposed as hash items. > > Is there some equivalent so that I could have beans act just as beans > > and records act just (more or less) as records (at least as a plan for > the future)? > > Or to filter out methods which don't conform to > ZeroArgumentNonVoidMethodPolicy (plus indexed methods)? > > > > Cheers, > > Simon > > > > > > > > > > On Thursday, 11 April 2024 at 09:42:02 BST, Daniel Dekany < > daniel.dek...@gmail.com> wrote: > > > > > > > > > > > > > So what I plant to do is renaming things to something like these > > > (suggestion for better names are welcome): > > > > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_METHOD > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY > > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY_AND_METHOD > > > > > > And then maybe I would also add policies where we don't care about > > > bean stuff, as it should be in theory with records. I don't think many > > > user will want such a purist approach, but it can be useful in > > > ensuring that our implementation is sound (because then it should be > > > possible to implement such a policy). > > > > -- > Best regards, > > Daniel Dekany > -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
The way I see it, Java developers usually don't know much about FreeMarker details like how certain methods can be accessed in the template language (i.e., as a method, as a sub-variable, etc,). But they know which plain Java methods they want to make accessible ("expose") for templates from security/maintainability reasons. That's why it's better that that's the first step. After that, if someone actually writes templates, and is annoyed by how some members are accessed in the template language by default, then there's a context and motivation to look into FreeMarker details, and hopefully find the desired settings. On Sun, Apr 21, 2024 at 4:51 AM Simon Hartley wrote: > I don't know if it makes sense given the method fine tuning stuff, but > here are two approaches: > 1. First choose which methods are exposed and then choose how they can be > accessed in the template, > i.e. which ones are "properties" (i.e. hash items) > 2. First determine what methods we are going to treat as properties and > then do exposure afterwards (methods and/or properties) > > Would it be clearer to rename in ZeroArgumentNonVoidMethodPolicy > so BOTH_PROPERTY_AND_METHOD becomes BOTH_HASH_ITEM_AND_METHOD ? > > For exposureLevel, we could choose to split it by adding > recordExposureLevel (defaulting to USE_DEFAULT or UNSET, with a value of > e.g. -1), > rather than adding a million variations to the existing exposureLevel > flags. > > Cheers, > Simon > > > > > On Sunday, 14 April 2024 at 12:43:50 BST, Daniel Dekany < > daniel.dek...@gmail.com> wrote: > > > > > > There's no "EXPOSE" variant for that, at the moment. We had to add > something like EXPOSE_PROPERTIES_ONLY_EXCEPT_FOR_RECORDS_AND_VALUE_TYPES, > though with a less comical and more future-proof name. > > On Sun, Apr 14, 2024 at 12:29 PM Simon Hartley > wrote: > > > > I experimented with setting: > > exposureLevel=freemarker.ext.beans.BeansWrapper.EXPOSE_PROPERTIES_ONLY > > > > This seems to prevent records from using anything but the bean > properties, > > so the components in the record don't get exposed as hash items. > > Is there some equivalent so that I could have beans act just as beans > > and records act just (more or less) as records (at least as a plan for > the future)? > > Or to filter out methods which don't conform to > ZeroArgumentNonVoidMethodPolicy (plus indexed methods)? > > > > Cheers, > > Simon > > > > > > > > > > On Thursday, 11 April 2024 at 09:42:02 BST, Daniel Dekany < > daniel.dek...@gmail.com> wrote: > > > > > > > > > > > > > So what I plant to do is renaming things to something like these > > > (suggestion for better names are welcome): > > > > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_METHOD > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY > > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY_AND_METHOD > > > > > > And then maybe I would also add policies where we don't care about > > > bean stuff, as it should be in theory with records. I don't think many > > > user will want such a purist approach, but it can be useful in > > > ensuring that our implementation is sound (because then it should be > > > possible to implement such a policy). > > > > -- > Best regards, > > Daniel Dekany > -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
I don't know if it makes sense given the method fine tuning stuff, but here are two approaches: 1. First choose which methods are exposed and then choose how they can be accessed in the template, i.e. which ones are "properties" (i.e. hash items) 2. First determine what methods we are going to treat as properties and then do exposure afterwards (methods and/or properties) Would it be clearer to rename in ZeroArgumentNonVoidMethodPolicy so BOTH_PROPERTY_AND_METHOD becomes BOTH_HASH_ITEM_AND_METHOD ? For exposureLevel, we could choose to split it by adding recordExposureLevel (defaulting to USE_DEFAULT or UNSET, with a value of e.g. -1), rather than adding a million variations to the existing exposureLevel flags. Cheers, Simon On Sunday, 14 April 2024 at 12:43:50 BST, Daniel Dekany wrote: There's no "EXPOSE" variant for that, at the moment. We had to add something like EXPOSE_PROPERTIES_ONLY_EXCEPT_FOR_RECORDS_AND_VALUE_TYPES, though with a less comical and more future-proof name. On Sun, Apr 14, 2024 at 12:29 PM Simon Hartley wrote: > > I experimented with setting: > exposureLevel=freemarker.ext.beans.BeansWrapper.EXPOSE_PROPERTIES_ONLY > > This seems to prevent records from using anything but the bean properties, > so the components in the record don't get exposed as hash items. > Is there some equivalent so that I could have beans act just as beans > and records act just (more or less) as records (at least as a plan for the > future)? > Or to filter out methods which don't conform to > ZeroArgumentNonVoidMethodPolicy (plus indexed methods)? > > Cheers, > Simon > > > > > On Thursday, 11 April 2024 at 09:42:02 BST, Daniel Dekany > wrote: > > > > > > > So what I plant to do is renaming things to something like these > > (suggestion for better names are welcome): > > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_METHOD > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY_AND_METHOD > > > > And then maybe I would also add policies where we don't care about > > bean stuff, as it should be in theory with records. I don't think many > > user will want such a purist approach, but it can be useful in > > ensuring that our implementation is sound (because then it should be > > possible to implement such a policy). -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
For ZeroArgumentNonVoidMethodPolicy, the hash square bracket syntax (e.g. obj["price"]) is not mentioned in its JavaDoc. It's present in the release notes, which is how I discovered it. On Sunday, 14 April 2024 at 12:43:50 BST, Daniel Dekany wrote: There's no "EXPOSE" variant for that, at the moment. We had to add something like EXPOSE_PROPERTIES_ONLY_EXCEPT_FOR_RECORDS_AND_VALUE_TYPES, though with a less comical and more future-proof name. On Sun, Apr 14, 2024 at 12:29 PM Simon Hartley wrote: > > I experimented with setting: > exposureLevel=freemarker.ext.beans.BeansWrapper.EXPOSE_PROPERTIES_ONLY > > This seems to prevent records from using anything but the bean properties, > so the components in the record don't get exposed as hash items. > Is there some equivalent so that I could have beans act just as beans > and records act just (more or less) as records (at least as a plan for the > future)? > Or to filter out methods which don't conform to > ZeroArgumentNonVoidMethodPolicy (plus indexed methods)? > > Cheers, > Simon > > > > > On Thursday, 11 April 2024 at 09:42:02 BST, Daniel Dekany > wrote: > > > > > > > So what I plant to do is renaming things to something like these > > (suggestion for better names are welcome): > > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_METHOD > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY_AND_METHOD > > > > And then maybe I would also add policies where we don't care about > > bean stuff, as it should be in theory with records. I don't think many > > user will want such a purist approach, but it can be useful in > > ensuring that our implementation is sound (because then it should be > > possible to implement such a policy). -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
There's no "EXPOSE" variant for that, at the moment. We had to add something like EXPOSE_PROPERTIES_ONLY_EXCEPT_FOR_RECORDS_AND_VALUE_TYPES, though with a less comical and more future-proof name. On Sun, Apr 14, 2024 at 12:29 PM Simon Hartley wrote: > > I experimented with setting: > exposureLevel=freemarker.ext.beans.BeansWrapper.EXPOSE_PROPERTIES_ONLY > > This seems to prevent records from using anything but the bean properties, > so the components in the record don't get exposed as hash items. > Is there some equivalent so that I could have beans act just as beans > and records act just (more or less) as records (at least as a plan for the > future)? > Or to filter out methods which don't conform to > ZeroArgumentNonVoidMethodPolicy (plus indexed methods)? > > Cheers, > Simon > > > > > On Thursday, 11 April 2024 at 09:42:02 BST, Daniel Dekany > wrote: > > > > > > > So what I plant to do is renaming things to something like these > > (suggestion for better names are welcome): > > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_METHOD > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY_AND_METHOD > > > > And then maybe I would also add policies where we don't care about > > bean stuff, as it should be in theory with records. I don't think many > > user will want such a purist approach, but it can be useful in > > ensuring that our implementation is sound (because then it should be > > possible to implement such a policy). -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
I experimented with setting: exposureLevel=freemarker.ext.beans.BeansWrapper.EXPOSE_PROPERTIES_ONLY This seems to prevent records from using anything but the bean properties, so the components in the record don't get exposed as hash items. Is there some equivalent so that I could have beans act just as beans and records act just (more or less) as records (at least as a plan for the future)? Or to filter out methods which don't conform to ZeroArgumentNonVoidMethodPolicy (plus indexed methods)? Cheers, Simon On Thursday, 11 April 2024 at 09:42:02 BST, Daniel Dekany wrote: > So what I plant to do is renaming things to something like these > (suggestion for better names are welcome): > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_METHOD > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY_AND_METHOD > > And then maybe I would also add policies where we don't care about > bean stuff, as it should be in theory with records. I don't think many > user will want such a purist approach, but it can be useful in > ensuring that our implementation is sound (because then it should be > possible to implement such a policy).
Re: 2.3.33 pre-vote testing
So what I plant to do is renaming things to something like these (suggestion for better names are welcome): ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_METHOD ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY_AND_METHOD And then maybe I would also add policies where we don't care about bean stuff, as it should be in theory with records. I don't think many user will want such a purist approach, but it can be useful in ensuring that our implementation is sound (because then it should be possible to implement such a policy). On Wed, Apr 3, 2024 at 8:38 PM Simon Hartley wrote: > > > Hm... I have to think about what future requirements we could run > > into, and if therefore it's actually a better idea to go the other way > > around, that is, to address the existence of Java Bean properties > > inside ZeroArgumentNonVoidMethodPolicy (i.e., include BEAN_PROPS > > this-and-that in the enum names). > > I'm also still thinking things through, including > BeansWrapper.EXPOSE_PROPERTIES_ONLY > > > the main issue with this > > new setback in the Java language design is exactly that I can only > > tell that it's a zero argument method that returns non-void, but I > > don't know if it's an accessor, or it sends out mails to all users if > > I call it, or what. (When these started with "get"/"is", at least you > > had a strong guess.) > > Good point: there's no language difference between e.g. > an adjective/state method "active" and a verb/operation method "activate". > (Well, there are components in records, but nothing to distinguish things in > normal classes.) > > > Fixed it, and thanks for spotting this! > > Great! Thank you very much. > > > Cheers, > Simon > > > > On Wednesday, 3 April 2024 at 17:03:54 BST, Daniel Dekany > wrote: > > > > > > > NonBeanAccessorsPolicy.XXX (as opposed to > > ZeroArgumentNonVoidMethodPolicy.XXX) > > Hm... I have to think about what future requirements we could run > into, and if therefore it's actually a better idea to go the other way > around, that is, to address the existence of Java Bean properties > inside ZeroArgumentNonVoidMethodPolicy (i.e., include BEAN_PROPS > this-and-that in the enum names). And also, the main issue with this > new setback in the Java language design is exactly that I can only > tell that it's a zero argument method that returns non-void, but I > don't know if it's an accessor, or it sends out mails to all users if > I call it, or what. (When these started with "get"/"is", at least you > had a strong guess.) > > > For 2.3.32: > > * non-bean class accessors could only be methods > > * bean class accessors could be methods and properties > > Some mostly terminology related clarifications for this. The > FreeMarker template language doesn't have anything called properties. > The Java Bean specification talks about properties, and hence > BeansWrapper (and hence DefaultObjectWrapper, which is its subclass). > In tempataes, Java Bean properties are only exposed as sub-variables > (like foo.bar), not as methods with that(!) name (i.e. "bar"). That > the Java Beans property read method (foo.getBar(), or foo.isBar()) is > also exposed is unrelated to the fact that it's a Java Bean property > read method. It's because Java Beans expose them as "actions" (I don't > know why, but that what they did). The name of these actions (usually) > differs from the property name ("foo" VS "getFoo"). > > > * non-bean record accessors could only be methods > > By default, yes. Though the MethodAppearanceFineTuner was always pluggable. > > > * bean record accessors are generally a mistake > > Actually, they are probably often there on purpose, since existing > libraries expect "properties" exposed via getXxx/isXxx methods. > Because they decided to break this pattern (instead of doing what > people have been asking for since forever), now we will sometimes end > up with hacks like @lombok.Getter public record MyRecord(String bar, > boolean accessible) { }. In this case, myRecrod.bar() and > myRecord.getBar() are both accessor methods to get the value of "bar", > and there was no intention to create a "getBar" > property/sub-variable/component/attribute/whatever-we-call-it. > > > With the current implementation, both of the following cause an error when > > the "active" property is used! > > record MyRecord(boolean isActive) { > >public boolean active() { > > Maybe people who do that deserve their fate. :) So, if you have no > active() there, then myRecord.active gives a boolean, because that's > just an accidental Java Bean property in this case, and then > myRecord.isActive will not give a boolean (but a method), since that > method now was taken over by the Java Beans logic. Not great, but > maybe not too bad. But, if you add MyRecord.active() to that class as > well, then that's a Java Bean "action" (the term for things meant to > be exposed as methods), and by d
Re: 2.3.33 pre-vote testing
Thanks Daniel, Jacques Le 11/04/2024 à 10:31, Daniel Dekany a écrit : Fix published to the snapshot repo. On Wed, Apr 10, 2024 at 2:27 PM Daniel Dekany wrote: Indeed, that convenience method was missed. Will fix that... when I get there, like hopefully in a day or so. (One can still just use config.setTemplateLoader(new freemarker.ext.jakarta.servlet.WebappTemplateLoader(...)) though). On Wed, Apr 10, 2024 at 11:03 AM Jacques Le Roux wrote: Hi, It seems we found an issue that could be related to https://issues.apache.org/jira/browse/FREEMARKER-218 It's at bottom of https://issues.apache.org/jira/browse/OFBIZ-12935 TIA Jacques Le 12/03/2024 à 11:16, Jacques Le Roux a écrit : Hi Daniel, We have started testing with https://issues.apache.org/jira/browse/OFBIZ-12934. For now we only crossed things to change in OFBiz that makes sense. We will let you informed in case we cross real issues. Thanks Jacques Le 12/03/2024 à 01:18, Daniel Dekany a écrit : By the way... if there are bugs, behavior can change with the Java version, the break points being Java 8, Java 9, and Java 16 (or just 17, as that's what's widely used in reality). On Mon, Mar 11, 2024 at 12:00 PM Christoph Rueger wrote: No regressions in our test suite. Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany < daniel.dek...@gmail.com>: Please test if the next release breaks anything. Then if it looks right, I will update building instructions, and do other more boring checks (distro zip contents, etc), and start a release voting. Change log: https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache *snapshot* Maven repo only: apache-snapshot-repository https://repository.apache.org/content/repositories/snapshots/ false true (Of course you can also download the jar directly, but be careful to pick the latest: https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/ ) -- Best regards, Daniel Dekany -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
Fix published to the snapshot repo. On Wed, Apr 10, 2024 at 2:27 PM Daniel Dekany wrote: > > Indeed, that convenience method was missed. Will fix that... when I > get there, like hopefully in a day or so. (One can still just use > config.setTemplateLoader(new > freemarker.ext.jakarta.servlet.WebappTemplateLoader(...)) though). > > On Wed, Apr 10, 2024 at 11:03 AM Jacques Le Roux > wrote: > > > > Hi, > > > > It seems we found an issue that could be related to > > https://issues.apache.org/jira/browse/FREEMARKER-218 > > > > It's at bottom of https://issues.apache.org/jira/browse/OFBIZ-12935 > > > > TIA > > > > Jacques > > > > Le 12/03/2024 à 11:16, Jacques Le Roux a écrit : > > > Hi Daniel, > > > > > > We have started testing with > > > https://issues.apache.org/jira/browse/OFBIZ-12934. > > > > > > For now we only crossed things to change in OFBiz that makes sense. > > > > > > We will let you informed in case we cross real issues. > > > > > > Thanks > > > > > > Jacques > > > > > > Le 12/03/2024 à 01:18, Daniel Dekany a écrit : > > >> By the way... if there are bugs, behavior can change with the Java > > >> version, the break points being Java 8, Java 9, and Java 16 (or just > > >> 17, as that's what's widely used in reality). > > >> > > >> On Mon, Mar 11, 2024 at 12:00 PM Christoph Rueger > > >> wrote: > > >>> No regressions in our test suite. > > >>> > > >>> Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany < > > >>> daniel.dek...@gmail.com>: > > >>> > > Please test if the next release breaks anything. Then if it looks > > right, I will update building instructions, and do other more boring > > checks (distro zip contents, etc), and start a release voting. > > > > Change log: > > > > https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html > > > > Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache > > *snapshot* Maven repo only: > > > > > > apache-snapshot-repository > > > > https://repository.apache.org/content/repositories/snapshots/ > > false > > true > > > > > > (Of course you can also download the jar directly, but be careful to > > pick the latest: > > > > https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/ > > ) > > > > -- > > Best regards, > > Daniel Dekany > > > > >> > > >> > > > > -- > Best regards, > Daniel Dekany -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
Indeed, that convenience method was missed. Will fix that... when I get there, like hopefully in a day or so. (One can still just use config.setTemplateLoader(new freemarker.ext.jakarta.servlet.WebappTemplateLoader(...)) though). On Wed, Apr 10, 2024 at 11:03 AM Jacques Le Roux wrote: > > Hi, > > It seems we found an issue that could be related to > https://issues.apache.org/jira/browse/FREEMARKER-218 > > It's at bottom of https://issues.apache.org/jira/browse/OFBIZ-12935 > > TIA > > Jacques > > Le 12/03/2024 à 11:16, Jacques Le Roux a écrit : > > Hi Daniel, > > > > We have started testing with > > https://issues.apache.org/jira/browse/OFBIZ-12934. > > > > For now we only crossed things to change in OFBiz that makes sense. > > > > We will let you informed in case we cross real issues. > > > > Thanks > > > > Jacques > > > > Le 12/03/2024 à 01:18, Daniel Dekany a écrit : > >> By the way... if there are bugs, behavior can change with the Java > >> version, the break points being Java 8, Java 9, and Java 16 (or just > >> 17, as that's what's widely used in reality). > >> > >> On Mon, Mar 11, 2024 at 12:00 PM Christoph Rueger > >> wrote: > >>> No regressions in our test suite. > >>> > >>> Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany < > >>> daniel.dek...@gmail.com>: > >>> > Please test if the next release breaks anything. Then if it looks > right, I will update building instructions, and do other more boring > checks (distro zip contents, etc), and start a release voting. > > Change log: > > https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html > > Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache > *snapshot* Maven repo only: > > > apache-snapshot-repository > > https://repository.apache.org/content/repositories/snapshots/ > false > true > > > (Of course you can also download the jar directly, but be careful to > pick the latest: > > https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/ > ) > > -- > Best regards, > Daniel Dekany > > >> > >> -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
Hi, It seems we found an issue that could be related to https://issues.apache.org/jira/browse/FREEMARKER-218 It's at bottom of https://issues.apache.org/jira/browse/OFBIZ-12935 TIA Jacques Le 12/03/2024 à 11:16, Jacques Le Roux a écrit : Hi Daniel, We have started testing with https://issues.apache.org/jira/browse/OFBIZ-12934. For now we only crossed things to change in OFBiz that makes sense. We will let you informed in case we cross real issues. Thanks Jacques Le 12/03/2024 à 01:18, Daniel Dekany a écrit : By the way... if there are bugs, behavior can change with the Java version, the break points being Java 8, Java 9, and Java 16 (or just 17, as that's what's widely used in reality). On Mon, Mar 11, 2024 at 12:00 PM Christoph Rueger wrote: No regressions in our test suite. Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany < daniel.dek...@gmail.com>: Please test if the next release breaks anything. Then if it looks right, I will update building instructions, and do other more boring checks (distro zip contents, etc), and start a release voting. Change log: https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache *snapshot* Maven repo only: apache-snapshot-repository https://repository.apache.org/content/repositories/snapshots/ false true (Of course you can also download the jar directly, but be careful to pick the latest: https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/ ) -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
> Hm... I have to think about what future requirements we could run > into, and if therefore it's actually a better idea to go the other way > around, that is, to address the existence of Java Bean properties > inside ZeroArgumentNonVoidMethodPolicy (i.e., include BEAN_PROPS > this-and-that in the enum names). I'm also still thinking things through, including BeansWrapper.EXPOSE_PROPERTIES_ONLY > the main issue with this > new setback in the Java language design is exactly that I can only > tell that it's a zero argument method that returns non-void, but I > don't know if it's an accessor, or it sends out mails to all users if > I call it, or what. (When these started with "get"/"is", at least you > had a strong guess.) Good point: there's no language difference between e.g. an adjective/state method "active" and a verb/operation method "activate". (Well, there are components in records, but nothing to distinguish things in normal classes.) > Fixed it, and thanks for spotting this! Great! Thank you very much. Cheers, Simon On Wednesday, 3 April 2024 at 17:03:54 BST, Daniel Dekany wrote: > NonBeanAccessorsPolicy.XXX (as opposed to ZeroArgumentNonVoidMethodPolicy.XXX) Hm... I have to think about what future requirements we could run into, and if therefore it's actually a better idea to go the other way around, that is, to address the existence of Java Bean properties inside ZeroArgumentNonVoidMethodPolicy (i.e., include BEAN_PROPS this-and-that in the enum names). And also, the main issue with this new setback in the Java language design is exactly that I can only tell that it's a zero argument method that returns non-void, but I don't know if it's an accessor, or it sends out mails to all users if I call it, or what. (When these started with "get"/"is", at least you had a strong guess.) > For 2.3.32: > * non-bean class accessors could only be methods > * bean class accessors could be methods and properties Some mostly terminology related clarifications for this. The FreeMarker template language doesn't have anything called properties. The Java Bean specification talks about properties, and hence BeansWrapper (and hence DefaultObjectWrapper, which is its subclass). In tempataes, Java Bean properties are only exposed as sub-variables (like foo.bar), not as methods with that(!) name (i.e. "bar"). That the Java Beans property read method (foo.getBar(), or foo.isBar()) is also exposed is unrelated to the fact that it's a Java Bean property read method. It's because Java Beans expose them as "actions" (I don't know why, but that what they did). The name of these actions (usually) differs from the property name ("foo" VS "getFoo"). > * non-bean record accessors could only be methods By default, yes. Though the MethodAppearanceFineTuner was always pluggable. > * bean record accessors are generally a mistake Actually, they are probably often there on purpose, since existing libraries expect "properties" exposed via getXxx/isXxx methods. Because they decided to break this pattern (instead of doing what people have been asking for since forever), now we will sometimes end up with hacks like @lombok.Getter public record MyRecord(String bar, boolean accessible) { }. In this case, myRecrod.bar() and myRecord.getBar() are both accessor methods to get the value of "bar", and there was no intention to create a "getBar" property/sub-variable/component/attribute/whatever-we-call-it. > With the current implementation, both of the following cause an error when > the "active" property is used! > record MyRecord(boolean isActive) { > public boolean active() { Maybe people who do that deserve their fate. :) So, if you have no active() there, then myRecord.active gives a boolean, because that's just an accidental Java Bean property in this case, and then myRecord.isActive will not give a boolean (but a method), since that method now was taken over by the Java Beans logic. Not great, but maybe not too bad. But, if you add MyRecord.active() to that class as well, then that's a Java Bean "action" (the term for things meant to be exposed as methods), and by default methods shadow properties with clashing names (although that's configurable via BeansWrapper.methodsShadowItems). > record MyRecord(boolean active) { > public boolean isActive() { That I expect to be a typical use-case, because of the backward compatibility hacks needed sometimes. I missed that case in the JUnit tests, and as the usual punishment for that, of course it was broken. Fixed it, and thanks for spotting this! https://github.com/apache/freemarker/commit/9cc2b9cb6d1196fffa010430920331a36e7cbf49 Also deployed to the snapshot repo (https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/). On Mon, Apr 1, 2024 at 6:49 PM Simon Hartley wrote: > > In terms of language, for a record's read methods, Java calls them accessors. > For beans, I'm used to the term getter, but when expandi
Re: 2.3.33 pre-vote testing
> NonBeanAccessorsPolicy.XXX (as opposed to ZeroArgumentNonVoidMethodPolicy.XXX) Hm... I have to think about what future requirements we could run into, and if therefore it's actually a better idea to go the other way around, that is, to address the existence of Java Bean properties inside ZeroArgumentNonVoidMethodPolicy (i.e., include BEAN_PROPS this-and-that in the enum names). And also, the main issue with this new setback in the Java language design is exactly that I can only tell that it's a zero argument method that returns non-void, but I don't know if it's an accessor, or it sends out mails to all users if I call it, or what. (When these started with "get"/"is", at least you had a strong guess.) > For 2.3.32: > * non-bean class accessors could only be methods > * bean class accessors could be methods and properties Some mostly terminology related clarifications for this. The FreeMarker template language doesn't have anything called properties. The Java Bean specification talks about properties, and hence BeansWrapper (and hence DefaultObjectWrapper, which is its subclass). In tempataes, Java Bean properties are only exposed as sub-variables (like foo.bar), not as methods with that(!) name (i.e. "bar"). That the Java Beans property read method (foo.getBar(), or foo.isBar()) is also exposed is unrelated to the fact that it's a Java Bean property read method. It's because Java Beans expose them as "actions" (I don't know why, but that what they did). The name of these actions (usually) differs from the property name ("foo" VS "getFoo"). > * non-bean record accessors could only be methods By default, yes. Though the MethodAppearanceFineTuner was always pluggable. > * bean record accessors are generally a mistake Actually, they are probably often there on purpose, since existing libraries expect "properties" exposed via getXxx/isXxx methods. Because they decided to break this pattern (instead of doing what people have been asking for since forever), now we will sometimes end up with hacks like @lombok.Getter public record MyRecord(String bar, boolean accessible) { }. In this case, myRecrod.bar() and myRecord.getBar() are both accessor methods to get the value of "bar", and there was no intention to create a "getBar" property/sub-variable/component/attribute/whatever-we-call-it. > With the current implementation, both of the following cause an error when > the "active" property is used! > record MyRecord(boolean isActive) { >public boolean active() { Maybe people who do that deserve their fate. :) So, if you have no active() there, then myRecord.active gives a boolean, because that's just an accidental Java Bean property in this case, and then myRecord.isActive will not give a boolean (but a method), since that method now was taken over by the Java Beans logic. Not great, but maybe not too bad. But, if you add MyRecord.active() to that class as well, then that's a Java Bean "action" (the term for things meant to be exposed as methods), and by default methods shadow properties with clashing names (although that's configurable via BeansWrapper.methodsShadowItems). > record MyRecord(boolean active) { > public boolean isActive() { That I expect to be a typical use-case, because of the backward compatibility hacks needed sometimes. I missed that case in the JUnit tests, and as the usual punishment for that, of course it was broken. Fixed it, and thanks for spotting this! https://github.com/apache/freemarker/commit/9cc2b9cb6d1196fffa010430920331a36e7cbf49 Also deployed to the snapshot repo (https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/). On Mon, Apr 1, 2024 at 6:49 PM Simon Hartley wrote: > > In terms of language, for a record's read methods, Java calls them accessors. > For beans, I'm used to the term getter, but when expanding to also describe > how boolean return methods are handled, > the term accessor is again used. It seems that zero-argument non-void is > trying to be distinct from the term accessor, > because that's what we believe is necessary for backwards compatibility and > compatibility with beans > (and a project could have a mixture of bean and non-bean style classes). > > But trying to move the problem slightly, what do you think of the following > idea? > NonBeanAccessorsPolicy.XXX (as opposed to ZeroArgumentNonVoidMethodPolicy.XXX) > Note: I've used a plural here to try to highlight we're saying the methods > are non-bean, rather than the classes. > So how does this help us when there's a conflict? > We've implied that logic for bean accessors may be being applied as well; > this can be supplemented with documentation. > Also not every future option should hang off ZeroArgumentNonVoidMethodPolicy, > since our original intent was to describe non-bean related behavior. > > > For 2.3.32: > * non-bean class accessors could only be methods > * bean class accessors could be methods and properties > * non-bean record
Re: 2.3.33 pre-vote testing
Bean style accessor (which is a getter): getName() Non-bean style accessor: name() A property in the template has to choose whether to refer to getName() or name(). I did use a confusing case of this where I noticed people's tendency to use isXyz for a boolean field name, rather than xyz. With version 2.3.32, records were treated like other classes, so as well as calling methods directly, you could use the property syntax in the template which would recognise methods which followed the bean accessor naming convention. When opting-in to the new version 2.3.33 features, for records using property syntax in the template, both methods following the bean accessor convention, as well as methods following the non-bean accessor convention are considered. When the class is first accessed, a mapping is created between methods and property names. For the examples I gave, the assumption is that beans would take precedence and the property "active" would map to the "isActive" method in both cases. As there seems to be an error, either I've not understood something or there's a quality of implementation issue that needs to be resolved. It's only a backwards compatibility error if we release it in its current state. The current enum added in 2.3.33 (which I suggested renaming) is only to determine whether non-bean style accessors should be considered at all. The assumption is that bean accessors would work as they always have. ZeroArgumentNonVoidMethodPolicy.METHOD_ONLY - the 2.3.32 status quo (the non-bean accessors would not be considered as properties) ZeroArgumentNonVoidMethodPolicy.BOTH_PROPERTY_AND_METHOD - the 2.3.33 value for records when opting in to incompatible improvements (non-bean accessors are also considered as properties) ZeroArgumentNonVoidMethodPolicy.PROPERTY_ONLY - non-bean accessors are considered as properties, but are no longer callable directly as methods So... what if I used the PROPERTY_ONLY value and then used my evil example: record Evil(boolean active, boolean isActive) {} Would the "active" property map to isActive() and active isn't useable at all (assuming bean accessor methods beat non-bean)? (I guess that currently it would fail similarly to the other 2 examples), There are lots of things we could call "policy" here (different ways of looking at the problem). In this preview version we have a single enum used for two settings (one for records, one for normal classes). I think we're still working out the consequences of these and whether they're a good idea. We did want mixed in order to be as backwards compatible as possible for people already using records. Another driving force is the desire to offer a solution that can also allow classes to use non-bean accessors as properties. Possibly that approach has led to the headaches we're finding here, but all options may have their own trade-offs. Simon On Monday, 1 April 2024 at 18:07:48 BST, Denis Bredelet wrote: Hello, I am talking as an outsider since I never touched the accessors configuration. Would it make sense to have three policies? BeanAccessorsPolicy GetterStyleAccessorsPolicy DefaultAccessorsPolicy (= mixed, as Simon highlighted conflicts are already errors so it is backward-compatible.) — Denis. > Le 1 avr. 2024 à 17:49, Simon Hartley a > écrit : > > In terms of language, for a record's read methods, Java calls them accessors. > For beans, I'm used to the term getter, but when expanding to also describe > how boolean return methods are handled, > the term accessor is again used. It seems that zero-argument non-void is > trying to be distinct from the term accessor, > because that's what we believe is necessary for backwards compatibility and > compatibility with beans > (and a project could have a mixture of bean and non-bean style classes). > > But trying to move the problem slightly, what do you think of the following > idea? > NonBeanAccessorsPolicy.XXX (as opposed to ZeroArgumentNonVoidMethodPolicy.XXX) > Note: I've used a plural here to try to highlight we're saying the methods > are non-bean, rather than the classes. > So how does this help us when there's a conflict? > We've implied that logic for bean accessors may be being applied as well; > this can be supplemented with documentation. > Also not every future option should hang off ZeroArgumentNonVoidMethodPolicy, > since our original intent was to describe non-bean related behavior. > > > For 2.3.32: > * non-bean class accessors could only be methods > * bean class accessors could be methods and properties > * non-bean record accessors could only be methods > * bean record accessors are generally a mistake > > For 2.3.33: > * non-bean class accessors were added to address use cases for both records > and classes. > * we haven't introduced an option to turn-off bean accessors for records to > solve the problem for records > * for some projects, an option to turn-off bean accessors for classes may be > u
Re: 2.3.33 pre-vote testing
Hello, I am talking as an outsider since I never touched the accessors configuration. Would it make sense to have three policies? BeanAccessorsPolicy GetterStyleAccessorsPolicy DefaultAccessorsPolicy (= mixed, as Simon highlighted conflicts are already errors so it is backward-compatible.) — Denis. > Le 1 avr. 2024 à 17:49, Simon Hartley a > écrit : > > In terms of language, for a record's read methods, Java calls them accessors. > For beans, I'm used to the term getter, but when expanding to also describe > how boolean return methods are handled, > the term accessor is again used. It seems that zero-argument non-void is > trying to be distinct from the term accessor, > because that's what we believe is necessary for backwards compatibility and > compatibility with beans > (and a project could have a mixture of bean and non-bean style classes). > > But trying to move the problem slightly, what do you think of the following > idea? > NonBeanAccessorsPolicy.XXX (as opposed to ZeroArgumentNonVoidMethodPolicy.XXX) > Note: I've used a plural here to try to highlight we're saying the methods > are non-bean, rather than the classes. > So how does this help us when there's a conflict? > We've implied that logic for bean accessors may be being applied as well; > this can be supplemented with documentation. > Also not every future option should hang off ZeroArgumentNonVoidMethodPolicy, > since our original intent was to describe non-bean related behavior. > > > For 2.3.32: > * non-bean class accessors could only be methods > * bean class accessors could be methods and properties > * non-bean record accessors could only be methods > * bean record accessors are generally a mistake > > For 2.3.33: > * non-bean class accessors were added to address use cases for both records > and classes. > * we haven't introduced an option to turn-off bean accessors for records to > solve the problem for records > * for some projects, an option to turn-off bean accessors for classes may be > useful, > but some projects would want a mixture > * where there is a mixture here are some approaches: > - prefer exposing bean properties (more likely to be backwards compatible?) > - prefer exposing non-bean properties (would work better with records?) > - error (force the user to resolve ambiguity by either using a method > invocation or changing their Java code) > - expose both (collisions?) > > > Property collisions > --- > > What happens when a record has fields/components of both active and isActive? > record Evil(boolean active, boolean isActive) {} > > With the current implementation, both of the following cause an error when > the "active" property is used! > record MyRecord(boolean isActive) { > public boolean active() { > return false; > } > // implicit method isActive() > } > record MyRecord(boolean active) { > public boolean isActive() { > return false; > } > // implicit method active() > } > > So collisions are already there, not a potential risk. > > Simon > > > > > > On Monday, 1 April 2024 at 12:35:44 BST, Daniel Dekany > wrote: > > > > > > I think we need the current behavior for the > almost-backward-compatible behavior that incompatibleImprovements > 2.3.33 promises. (Although it's "incompatible", there's a promise that > as far as it's 2.3.x, it only enables changes that are most likely > won't break your application, hence when someone discovers that they > need some of the improvements it brings, they can usually crank it up, > and get all the other improvements too, instead of people having some > unique permutation of "improvements" enabled.) So maybe > ZeroArgumentNonVoidMethodPolicy.PROPERTY_ONLY should be called > PROPERTY_UNLESS_BEAN_PROP_READ_METHOD (oh my...), and > BOTH_PROPERTY_AND_METHOD should called > PROPERTY_UNLESS_BEAN_PROP_READ_METHOD_AND_METHOD (even funnier name). > And then later we can introduce other policies if needed, which are > less backward compatible, but might be seen cleaner or more obvious. > > On Sun, Mar 31, 2024 at 4:49 PM Simon Hartley > wrote: >> >> If I was trying to do something here's an idea or two >> (please don't feel any pressure to implement this, I'm just thinking out >> loud): >> >> How properties are implemented is from two sources: beans and simple >> non-voids. >> When the logic of both is being applied, then it's not a surprise that there >> are some strange interactions. >> If I could enable them separately, then I could turn off bean properties on >> records and have it work as I hoped. >> >> Otherwise perhaps I would need to have a backwards compatibility mode which >> is only enabled when using the default values. >> Or perhaps a setting which said whether beans or simple non-voids take >> precedence. >> >> I'm more than happy with the status quo; a few rough edges aren't the end of >> the world. >> I very much appreciate the effort you've already put
Re: 2.3.33 pre-vote testing
In terms of language, for a record's read methods, Java calls them accessors. For beans, I'm used to the term getter, but when expanding to also describe how boolean return methods are handled, the term accessor is again used. It seems that zero-argument non-void is trying to be distinct from the term accessor, because that's what we believe is necessary for backwards compatibility and compatibility with beans (and a project could have a mixture of bean and non-bean style classes). But trying to move the problem slightly, what do you think of the following idea? NonBeanAccessorsPolicy.XXX (as opposed to ZeroArgumentNonVoidMethodPolicy.XXX) Note: I've used a plural here to try to highlight we're saying the methods are non-bean, rather than the classes. So how does this help us when there's a conflict? We've implied that logic for bean accessors may be being applied as well; this can be supplemented with documentation. Also not every future option should hang off ZeroArgumentNonVoidMethodPolicy, since our original intent was to describe non-bean related behavior. For 2.3.32: * non-bean class accessors could only be methods * bean class accessors could be methods and properties * non-bean record accessors could only be methods * bean record accessors are generally a mistake For 2.3.33: * non-bean class accessors were added to address use cases for both records and classes. * we haven't introduced an option to turn-off bean accessors for records to solve the problem for records * for some projects, an option to turn-off bean accessors for classes may be useful, but some projects would want a mixture * where there is a mixture here are some approaches: - prefer exposing bean properties (more likely to be backwards compatible?) - prefer exposing non-bean properties (would work better with records?) - error (force the user to resolve ambiguity by either using a method invocation or changing their Java code) - expose both (collisions?) Property collisions --- What happens when a record has fields/components of both active and isActive? record Evil(boolean active, boolean isActive) {} With the current implementation, both of the following cause an error when the "active" property is used! record MyRecord(boolean isActive) { public boolean active() { return false; } // implicit method isActive() } record MyRecord(boolean active) { public boolean isActive() { return false; } // implicit method active() } So collisions are already there, not a potential risk. Simon On Monday, 1 April 2024 at 12:35:44 BST, Daniel Dekany wrote: I think we need the current behavior for the almost-backward-compatible behavior that incompatibleImprovements 2.3.33 promises. (Although it's "incompatible", there's a promise that as far as it's 2.3.x, it only enables changes that are most likely won't break your application, hence when someone discovers that they need some of the improvements it brings, they can usually crank it up, and get all the other improvements too, instead of people having some unique permutation of "improvements" enabled.) So maybe ZeroArgumentNonVoidMethodPolicy.PROPERTY_ONLY should be called PROPERTY_UNLESS_BEAN_PROP_READ_METHOD (oh my...), and BOTH_PROPERTY_AND_METHOD should called PROPERTY_UNLESS_BEAN_PROP_READ_METHOD_AND_METHOD (even funnier name). And then later we can introduce other policies if needed, which are less backward compatible, but might be seen cleaner or more obvious. On Sun, Mar 31, 2024 at 4:49 PM Simon Hartley wrote: > > If I was trying to do something here's an idea or two > (please don't feel any pressure to implement this, I'm just thinking out > loud): > > How properties are implemented is from two sources: beans and simple > non-voids. > When the logic of both is being applied, then it's not a surprise that there > are some strange interactions. > If I could enable them separately, then I could turn off bean properties on > records and have it work as I hoped. > > Otherwise perhaps I would need to have a backwards compatibility mode which > is only enabled when using the default values. > Or perhaps a setting which said whether beans or simple non-voids take > precedence. > > I'm more than happy with the status quo; a few rough edges aren't the end of > the world. > I very much appreciate the effort you've already put in and what's been done > is a huge improvement. > > Thank you so much, > Simon > > > > > On Sunday, 31 March 2024 at 02:05:32 BST, Daniel Dekany > wrote: > > > > > > Yeah, it is confusing/complicated if somebody digs into it. So you > have `boolean isAccessible()` in a record. Because it's in a record, > it's a good question what the intent of the author was (plus, now that > the Java language makers make a mess, people will start using the same > pattern in all kind of classes, randomly mixed with old-style > getters). Like maybe it looks as a Java Beans property read
Re: 2.3.33 pre-vote testing
I think we need the current behavior for the almost-backward-compatible behavior that incompatibleImprovements 2.3.33 promises. (Although it's "incompatible", there's a promise that as far as it's 2.3.x, it only enables changes that are most likely won't break your application, hence when someone discovers that they need some of the improvements it brings, they can usually crank it up, and get all the other improvements too, instead of people having some unique permutation of "improvements" enabled.) So maybe ZeroArgumentNonVoidMethodPolicy.PROPERTY_ONLY should be called PROPERTY_UNLESS_BEAN_PROP_READ_METHOD (oh my...), and BOTH_PROPERTY_AND_METHOD should called PROPERTY_UNLESS_BEAN_PROP_READ_METHOD_AND_METHOD (even funnier name). And then later we can introduce other policies if needed, which are less backward compatible, but might be seen cleaner or more obvious. On Sun, Mar 31, 2024 at 4:49 PM Simon Hartley wrote: > > If I was trying to do something here's an idea or two > (please don't feel any pressure to implement this, I'm just thinking out > loud): > > How properties are implemented is from two sources: beans and simple > non-voids. > When the logic of both is being applied, then it's not a surprise that there > are some strange interactions. > If I could enable them separately, then I could turn off bean properties on > records and have it work as I hoped. > > Otherwise perhaps I would need to have a backwards compatibility mode which > is only enabled when using the default values. > Or perhaps a setting which said whether beans or simple non-voids take > precedence. > > I'm more than happy with the status quo; a few rough edges aren't the end of > the world. > I very much appreciate the effort you've already put in and what's been done > is a huge improvement. > > Thank you so much, > Simon > > > > > On Sunday, 31 March 2024 at 02:05:32 BST, Daniel Dekany > wrote: > > > > > > Yeah, it is confusing/complicated if somebody digs into it. So you > have `boolean isAccessible()` in a record. Because it's in a record, > it's a good question what the intent of the author was (plus, now that > the Java language makers make a mess, people will start using the same > pattern in all kind of classes, randomly mixed with old-style > getters). Like maybe it looks as a Java Beans property read method > only accidentally, and they want this property-like thing to be called > "isAccessible". But I think the most likely, by far, is that the > authors are just confused about what the convention now is. Also, > Java's java.beans.Introspector tells us that that's what it is: a Java > Beans property called "accessible". FreeMarker doesn't try to guess if > from the name. Also, this happens to be the most backward compatible > behavior too. > > The end result is as below. > > These will work: > myRecord.accessible - boolean value, because it's a Java Beans > property called "accessible" > myRecord.isAccessible() - which returns boolean, because a such a > public method exists in Java, and therefore people expect it to work > like in Java. > > This doesn't work: > myRecord.accessible() - because there's no such method in Java, so it > would be quite absurd > myRecord.isAccessible - is not a boolean value, but a method, because > that's how it always was with JavaBean property read methods. > > And then, you say, maybe myRecord.isAccessible should also be a > boolean? I don't know... It's more backward incompatibility risk for > sure. > > Also, note that if something is related to JavaBean properties, the > ZeroArgumentNonVoidMethodPolicy doesn't apply. We decided that it's a > JavaBean property read method, and end of story. > > That the ZeroArgumentNonVoidMethodPolicy name doesn't convey the exact > meaning is true. Not sure what a better name could be though, that's > not comically long. > > On Sat, Mar 30, 2024 at 1:11 AM Simon Hartley > wrote: > > > > Similarly, for a record with a field (component) called isActive, > > its property name is currently "active" and not "isActive". > > Additionally, this exposed property is callable as a method even when the > > setting is PROPERTY_ONLY, > > due to it being considered a bean property and not a record property. > > > > Is this the compromise we're making and something we'll live with, > > or should we add more complexity so that this doesn't always apply? > > > > > > > > On Friday, 29 March 2024 at 23:29:31 GMT, Simon Hartley > > wrote: > > > > > > > > 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 whe
Re: 2.3.33 pre-vote testing
If I was trying to do something here's an idea or two (please don't feel any pressure to implement this, I'm just thinking out loud): How properties are implemented is from two sources: beans and simple non-voids. When the logic of both is being applied, then it's not a surprise that there are some strange interactions. If I could enable them separately, then I could turn off bean properties on records and have it work as I hoped. Otherwise perhaps I would need to have a backwards compatibility mode which is only enabled when using the default values. Or perhaps a setting which said whether beans or simple non-voids take precedence. I'm more than happy with the status quo; a few rough edges aren't the end of the world. I very much appreciate the effort you've already put in and what's been done is a huge improvement. Thank you so much, Simon On Sunday, 31 March 2024 at 02:05:32 BST, Daniel Dekany wrote: Yeah, it is confusing/complicated if somebody digs into it. So you have `boolean isAccessible()` in a record. Because it's in a record, it's a good question what the intent of the author was (plus, now that the Java language makers make a mess, people will start using the same pattern in all kind of classes, randomly mixed with old-style getters). Like maybe it looks as a Java Beans property read method only accidentally, and they want this property-like thing to be called "isAccessible". But I think the most likely, by far, is that the authors are just confused about what the convention now is. Also, Java's java.beans.Introspector tells us that that's what it is: a Java Beans property called "accessible". FreeMarker doesn't try to guess if from the name. Also, this happens to be the most backward compatible behavior too. The end result is as below. These will work: myRecord.accessible - boolean value, because it's a Java Beans property called "accessible" myRecord.isAccessible() - which returns boolean, because a such a public method exists in Java, and therefore people expect it to work like in Java. This doesn't work: myRecord.accessible() - because there's no such method in Java, so it would be quite absurd myRecord.isAccessible - is not a boolean value, but a method, because that's how it always was with JavaBean property read methods. And then, you say, maybe myRecord.isAccessible should also be a boolean? I don't know... It's more backward incompatibility risk for sure. Also, note that if something is related to JavaBean properties, the ZeroArgumentNonVoidMethodPolicy doesn't apply. We decided that it's a JavaBean property read method, and end of story. That the ZeroArgumentNonVoidMethodPolicy name doesn't convey the exact meaning is true. Not sure what a better name could be though, that's not comically long. On Sat, Mar 30, 2024 at 1:11 AM Simon Hartley wrote: > > Similarly, for a record with a field (component) called isActive, > its property name is currently "active" and not "isActive". > Additionally, this exposed property is callable as a method even when the > setting is PROPERTY_ONLY, > due to it being considered a bean property and not a record property. > > Is this the compromise we're making and something we'll live with, > or should we add more complexity so that this doesn't always apply? > > > > On Friday, 29 March 2024 at 23:29:31 GMT, Simon Hartley > wrote: > > > > 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 -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
Yeah, it is confusing/complicated if somebody digs into it. So you have `boolean isAccessible()` in a record. Because it's in a record, it's a good question what the intent of the author was (plus, now that the Java language makers make a mess, people will start using the same pattern in all kind of classes, randomly mixed with old-style getters). Like maybe it looks as a Java Beans property read method only accidentally, and they want this property-like thing to be called "isAccessible". But I think the most likely, by far, is that the authors are just confused about what the convention now is. Also, Java's java.beans.Introspector tells us that that's what it is: a Java Beans property called "accessible". FreeMarker doesn't try to guess if from the name. Also, this happens to be the most backward compatible behavior too. The end result is as below. These will work: myRecord.accessible - boolean value, because it's a Java Beans property called "accessible" myRecord.isAccessible() - which returns boolean, because a such a public method exists in Java, and therefore people expect it to work like in Java. This doesn't work: myRecord.accessible() - because there's no such method in Java, so it would be quite absurd myRecord.isAccessible - is not a boolean value, but a method, because that's how it always was with JavaBean property read methods. And then, you say, maybe myRecord.isAccessible should also be a boolean? I don't know... It's more backward incompatibility risk for sure. Also, note that if something is related to JavaBean properties, the ZeroArgumentNonVoidMethodPolicy doesn't apply. We decided that it's a JavaBean property read method, and end of story. That the ZeroArgumentNonVoidMethodPolicy name doesn't convey the exact meaning is true. Not sure what a better name could be though, that's not comically long. On Sat, Mar 30, 2024 at 1:11 AM Simon Hartley wrote: > > Similarly, for a record with a field (component) called isActive, > its property name is currently "active" and not "isActive". > Additionally, this exposed property is callable as a method even when the > setting is PROPERTY_ONLY, > due to it being considered a bean property and not a record property. > > Is this the compromise we're making and something we'll live with, > or should we add more complexity so that this doesn't always apply? > > > > On Friday, 29 March 2024 at 23:29:31 GMT, Simon Hartley > wrote: > > > > 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 -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
Similarly, for a record with a field (component) called isActive, its property name is currently "active" and not "isActive". Additionally, this exposed property is callable as a method even when the setting is PROPERTY_ONLY, due to it being considered a bean property and not a record property. Is this the compromise we're making and something we'll live with, or should we add more complexity so that this doesn't always apply? On Friday, 29 March 2024 at 23:29:31 GMT, Simon Hartley wrote: 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
Re: 2.3.33 pre-vote testing
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 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
Re: 2.3.33 pre-vote testing
> 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 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 > 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
Re: 2.3.33 pre-vote testing
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 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).
Re: 2.3.33 pre-vote testing
Cool. I'm glad it's all in hand. If you do decide to update the comment, perhaps also add the inverted test to what I suggested, in order to record that expectation. Cheers, Simon On Thursday, 28 March 2024 at 15:28:53 GMT, Daniel Dekany wrote: My approach was that from the perspective of a dynamic language, the array type is accessible even if the element type is not exposed. That is, FreeMarker can get its elements, and length. If then later it tries to access members of an element, that's a separate matter, and it might succeed, because even though the declared class is not exposed, some types it implements or extends might be. (It's true that the comment should mention primitives though.)
Re: 2.3.33 pre-vote testing
My approach was that from the perspective of a dynamic language, the array type is accessible even if the element type is not exposed. That is, FreeMarker can get its elements, and length. If then later it tries to access members of an element, that's a separate matter, and it might succeed, because even though the declared class is not exposed, some types it implements or extends might be. (It's true that the comment should mention primitives though.) On Thu, Mar 28, 2024 at 3:29 AM Simon Hartley wrote: > > Hey Daniel. > > The fix you've done doesn't seem to take into account that some arrays should > be inaccessible. > I assume that's the case and that the following test should be added: > > assertFalse(_JavaVersions.JAVA_9.isAccessibleAccordingToModuleExports(getSomeInternalClass().arrayType())); > > > Here's one idea for a fix: > > Package accessedPackage = accessedClass.getPackage(); // null for arrays and > primitives! > if (accessedPackage == null) { > Class componentClass = accessedClass.getComponentType(); // null > for non-arrays! > if (componentClass != null) { > accessedPackage = componentClass.getPackage(); > } > } > if (accessedPackage == null) { > return true; > } > > > P.S. > That Class.arrayType() method was added in Java12, but if that's a problem > then it's implementation is a one liner anyway: > > public Class arrayType() { > return Array.newInstance(this, 0).getClass(); > } > > P.P.S > Class has a componentType() method that was added in 12, > but there already existed getComponentType() which is identical. > > > Cheers, > Simon > > > > > > On Thursday, 28 March 2024 at 00:40:46 GMT, Daniel Dekany > wrote: > > > Yes, thanks for running into that! That was a bug with new code that > checks if we have access to a class according to Java 9+ modules. It > was because I didn't realize that for the class of an array, > Class.getPackage() returns null. The fixed version was pushed to the > Maven snapshot repo already. -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
Hey Daniel. The fix you've done doesn't seem to take into account that some arrays should be inaccessible. I assume that's the case and that the following test should be added: assertFalse(_JavaVersions.JAVA_9.isAccessibleAccordingToModuleExports(getSomeInternalClass().arrayType())); Here's one idea for a fix: Package accessedPackage = accessedClass.getPackage(); // null for arrays and primitives! if (accessedPackage == null) { Class componentClass = accessedClass.getComponentType(); // null for non-arrays! if (componentClass != null) { accessedPackage = componentClass.getPackage(); } } if (accessedPackage == null) { return true; } P.S. That Class.arrayType() method was added in Java12, but if that's a problem then it's implementation is a one liner anyway: public Class arrayType() { return Array.newInstance(this, 0).getClass(); } P.P.S Class has a componentType() method that was added in 12, but there already existed getComponentType() which is identical. Cheers, Simon On Thursday, 28 March 2024 at 00:40:46 GMT, Daniel Dekany wrote: Yes, thanks for running into that! That was a bug with new code that checks if we have access to a class according to Java 9+ modules. It was because I didn't realize that for the class of an array, Class.getPackage() returns null. The fixed version was pushed to the Maven snapshot repo already.
Re: Re: 2.3.33 pre-vote testing
Yes, thanks for running into that! That was a bug with new code that checks if we have access to a class according to Java 9+ modules. It was because I didn't realize that for the class of an array, Class.getPackage() returns null. The fixed version was pushed to the Maven snapshot repo already. On Thu, Mar 28, 2024 at 1:36 AM Gaetan wrote: > > Hello, > > While testing i stumbled upon an issue with a list. > > Before the version update we had no error doing for example > > `<#assign permissions = display.getBasePermissionList()>` > > Where `getBasePermissionList` would return an array. > > With the new version an error is thrown and we must change the > `permission` from an array to a list. > > So my understanding is that a List is required now. Is this a wanted > change ? > > Gaetan > > On 2024/03/12 10:16:52 Jacques Le Roux wrote: > > Hi Daniel, > > > > We have started testing with > https://issues.apache.org/jira/browse/OFBIZ-12934. > > > > For now we only crossed things to change in OFBiz that makes sense. > > > > We will let you informed in case we cross real issues. > > > > Thanks > > > > Jacques > > > > Le 12/03/2024 à 01:18, Daniel Dekany a écrit : > > > By the way... if there are bugs, behavior can change with the Java > > > version, the break points being Java 8, Java 9, and Java 16 (or just > > > 17, as that's what's widely used in reality). > > > > > > On Mon, Mar 11, 2024 at 12:00 PM Christoph Rueger > wrote: > > >> No regressions in our test suite. > > >> > > >> Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany < > > >> daniel.dek...@gmail.com>: > > >> > > >>> Please test if the next release breaks anything. Then if it looks > > >>> right, I will update building instructions, and do other more boring > > >>> checks (distro zip contents, etc), and start a release voting. > > >>> > > >>> Change log: > > >>> > > >>> > https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html > > >>> > > >>> Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache > > >>> *snapshot* Maven repo only: > > >>> > > >>> > > >>> apache-snapshot-repository > > >>> > > >>> https://repository.apache.org/content/repositories/snapshots/ > > >>> false > > >>> true > > >>> > > >>> > > >>> (Of course you can also download the jar directly, but be careful to > > >>> pick the latest: > > >>> > > >>> > https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/ > > >>> ) > > >>> > > >>> -- > > >>> Best regards, > > >>> Daniel Dekany > > >>> > > > > > > > > -- Best regards, Daniel Dekany
RE: Re: 2.3.33 pre-vote testing
Hello, While testing i stumbled upon an issue with a list. Before the version update we had no error doing for example `<#assign permissions = display.getBasePermissionList()>` Where `getBasePermissionList` would return an array. With the new version an error is thrown and we must change the `permission` from an array to a list. So my understanding is that a List is required now. Is this a wanted change ? Gaetan On 2024/03/12 10:16:52 Jacques Le Roux wrote: > Hi Daniel, > > We have started testing with https://issues.apache.org/jira/browse/OFBIZ-12934. > > For now we only crossed things to change in OFBiz that makes sense. > > We will let you informed in case we cross real issues. > > Thanks > > Jacques > > Le 12/03/2024 à 01:18, Daniel Dekany a écrit : > > By the way... if there are bugs, behavior can change with the Java > > version, the break points being Java 8, Java 9, and Java 16 (or just > > 17, as that's what's widely used in reality). > > > > On Mon, Mar 11, 2024 at 12:00 PM Christoph Rueger wrote: > >> No regressions in our test suite. > >> > >> Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany < > >> daniel.dek...@gmail.com>: > >> > >>> Please test if the next release breaks anything. Then if it looks > >>> right, I will update building instructions, and do other more boring > >>> checks (distro zip contents, etc), and start a release voting. > >>> > >>> Change log: > >>> > >>> https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html > >>> > >>> Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache > >>> *snapshot* Maven repo only: > >>> > >>> > >>> apache-snapshot-repository > >>> > >>> https://repository.apache.org/content/repositories/snapshots/ > >>> false > >>> true > >>> > >>> > >>> (Of course you can also download the jar directly, but be careful to > >>> pick the latest: > >>> > >>> https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/ > >>> ) > >>> > >>> -- > >>> Best regards, > >>> Daniel Dekany > >>> > > > > >
Re: 2.3.33 pre-vote testing
Sorry for previous mail, here is the original thread : https://lists.apache.org/thread/t4c9z7wkcp3dbdokmnjd32fcptq8h9tz Gaetan On 3/26/24 14:16, Gaetan wrote: Hello, While testing i stumbled upon an issue with a list. Before the version update we had no error doing for example `<#assign permissions = display.getBasePermissionList()>` Where `getBasePermissionList` would return an array. With the new version an error is thrown and we must change the `permission` from an array to a list. So my understanding is that a List is required now. Is this a wanted change ? Gaetan On 2024/03/12 10:16:52 Jacques Le Roux wrote: > Hi Daniel, > > We have started testing with https://issues.apache.org/jira/browse/OFBIZ-12934. > > For now we only crossed things to change in OFBiz that makes sense. > > We will let you informed in case we cross real issues. > > Thanks > > Jacques > > Le 12/03/2024 à 01:18, Daniel Dekany a écrit : > > By the way... if there are bugs, behavior can change with the Java > > version, the break points being Java 8, Java 9, and Java 16 (or just > > 17, as that's what's widely used in reality). > > > > On Mon, Mar 11, 2024 at 12:00 PM Christoph Rueger wrote: > >> No regressions in our test suite. > >> > >> Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany < > >> daniel.dek...@gmail.com>: > >> > >>> Please test if the next release breaks anything. Then if it looks > >>> right, I will update building instructions, and do other more boring > >>> checks (distro zip contents, etc), and start a release voting. > >>> > >>> Change log: > >>> > >>> https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html > >>> > >>> Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache > >>> *snapshot* Maven repo only: > >>> > >>> > >>> apache-snapshot-repository > >>> > >>> https://repository.apache.org/content/repositories/snapshots/ > >>> false > >>> true > >>> > >>> > >>> (Of course you can also download the jar directly, but be careful to > >>> pick the latest: > >>> > >>> https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/ > >>> ) > >>> > >>> -- > >>> Best regards, > >>> Daniel Dekany > >>> > > > > >
Re: 2.3.33 pre-vote testing
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). On Thu, Mar 7, 2024 at 6:56 PM Daniel Dekany wrote: > > Please test if the next release breaks anything. Then if it looks > right, I will update building instructions, and do other more boring > checks (distro zip contents, etc), and start a release voting. > > Change log: > https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html > > Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache > *snapshot* Maven repo only: > > > apache-snapshot-repository > > https://repository.apache.org/content/repositories/snapshots/ > false > true > > > (Of course you can also download the jar directly, but be careful to > pick the latest: > https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/) > > -- > Best regards, > Daniel Dekany -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
Hi Daniel, We have started testing with https://issues.apache.org/jira/browse/OFBIZ-12934. For now we only crossed things to change in OFBiz that makes sense. We will let you informed in case we cross real issues. Thanks Jacques Le 12/03/2024 à 01:18, Daniel Dekany a écrit : By the way... if there are bugs, behavior can change with the Java version, the break points being Java 8, Java 9, and Java 16 (or just 17, as that's what's widely used in reality). On Mon, Mar 11, 2024 at 12:00 PM Christoph Rueger wrote: No regressions in our test suite. Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany < daniel.dek...@gmail.com>: Please test if the next release breaks anything. Then if it looks right, I will update building instructions, and do other more boring checks (distro zip contents, etc), and start a release voting. Change log: https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache *snapshot* Maven repo only: apache-snapshot-repository https://repository.apache.org/content/repositories/snapshots/ false true (Of course you can also download the jar directly, but be careful to pick the latest: https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/ ) -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
By the way... if there are bugs, behavior can change with the Java version, the break points being Java 8, Java 9, and Java 16 (or just 17, as that's what's widely used in reality). On Mon, Mar 11, 2024 at 12:00 PM Christoph Rueger wrote: > > No regressions in our test suite. > > Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany < > daniel.dek...@gmail.com>: > > > Please test if the next release breaks anything. Then if it looks > > right, I will update building instructions, and do other more boring > > checks (distro zip contents, etc), and start a release voting. > > > > Change log: > > > > https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html > > > > Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache > > *snapshot* Maven repo only: > > > > > > apache-snapshot-repository > > > > https://repository.apache.org/content/repositories/snapshots/ > > false > > true > > > > > > (Of course you can also download the jar directly, but be careful to > > pick the latest: > > > > https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/ > > ) > > > > -- > > Best regards, > > Daniel Dekany > > -- Best regards, Daniel Dekany
Re: 2.3.33 pre-vote testing
No regressions in our test suite. Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany < daniel.dek...@gmail.com>: > Please test if the next release breaks anything. Then if it looks > right, I will update building instructions, and do other more boring > checks (distro zip contents, etc), and start a release voting. > > Change log: > > https://freemarker.apache.org/builds/2.3.33-preview/_html/versions_2_3_33.html > > Maven dependency version is 2.3.33-SNAPHSOT, and it's in the Apache > *snapshot* Maven repo only: > > > apache-snapshot-repository > > https://repository.apache.org/content/repositories/snapshots/ > false > true > > > (Of course you can also download the jar directly, but be careful to > pick the latest: > > https://repository.apache.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.33-SNAPSHOT/ > ) > > -- > Best regards, > Daniel Dekany >