You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@freemarker.apache.org by Daniel Dekany <da...@gmail.com> on 2024/03/07 17:56:37 UTC
2.3.33 pre-vote testing
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:
<repository>
<id>apache-snapshot-repository</id>
<url>https://repository.apache.org/content/repositories/snapshots/</url>
<releases><enabled>false</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</repository>
(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
Posted by Simon Hartley <sc...@yahoo.co.uk.INVALID>.
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 <da...@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
<sc...@yahoo.co.uk.invalid> 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 <da...@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
Re: 2.3.33 pre-vote testing
Posted by Daniel Dekany <da...@gmail.com>.
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
<sc...@yahoo.co.uk.invalid> 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.dekany@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
> <sc...@yahoo.co.uk.invalid> 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.dekany@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
Posted by Daniel Dekany <da...@gmail.com>.
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
<sc...@yahoo.co.uk.invalid> 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.dekany@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
> <sc...@yahoo.co.uk.invalid> 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.dekany@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
Posted by Simon Hartley <sc...@yahoo.co.uk.INVALID>.
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 <da...@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
<sc...@yahoo.co.uk.invalid> 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 <da...@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
Re: 2.3.33 pre-vote testing
Posted by Daniel Dekany <da...@gmail.com>.
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
<sc...@yahoo.co.uk.invalid> 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 <da...@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
Re: 2.3.33 pre-vote testing
Posted by Simon Hartley <sc...@yahoo.co.uk.INVALID>.
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 <da...@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).
Re: 2.3.33 pre-vote testing
Posted by Daniel Dekany <da...@gmail.com>.
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
<sc...@yahoo.co.uk.invalid> 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 <da...@gmail.com> 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
> <sc...@yahoo.co.uk.invalid> 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 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 <da...@gmail.com> 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
> > <sc...@yahoo.co.uk.invalid> 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 <da...@gmail.com> 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
> > > <sc...@yahoo.co.uk.invalid> 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 <sc...@yahoo.co.uk.invalid> 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
> >
> >
> >
> > --
> > Best regards,
> > Daniel Dekany
>
>
>
> --
> Best regards,
> Daniel Dekany
--
Best regards,
Daniel Dekany
Re: 2.3.33 pre-vote testing
Posted by Simon Hartley <sc...@yahoo.co.uk.INVALID>.
> 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 <da...@gmail.com> 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
<sc...@yahoo.co.uk.invalid> 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 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 <da...@gmail.com> 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
> <sc...@yahoo.co.uk.invalid> 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 <da...@gmail.com> 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
> > <sc...@yahoo.co.uk.invalid> 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 <sc...@yahoo.co.uk.invalid> 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
>
>
>
> --
> Best regards,
> Daniel Dekany
--
Best regards,
Daniel Dekany
Re: 2.3.33 pre-vote testing
Posted by Daniel Dekany <da...@gmail.com>.
> 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
<sc...@yahoo.co.uk.invalid> 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 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 <da...@gmail.com> 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
> <sc...@yahoo.co.uk.invalid> 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 <da...@gmail.com> 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
> > <sc...@yahoo.co.uk.invalid> 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 <sc...@yahoo.co.uk.invalid> 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
>
>
>
> --
> Best regards,
> Daniel Dekany
--
Best regards,
Daniel Dekany
Re: 2.3.33 pre-vote testing
Posted by Simon Hartley <sc...@yahoo.co.uk.INVALID>.
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 <br...@mac.com.invalid> 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 <sc...@yahoo.co.uk.INVALID> 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 <da...@gmail.com> 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
> <sc...@yahoo.co.uk.invalid> 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 <da...@gmail.com> 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
>> <sc...@yahoo.co.uk.invalid> 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 <sc...@yahoo.co.uk.invalid> 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
>
>
>
> --
> Best regards,
> Daniel Dekany
Re: 2.3.33 pre-vote testing
Posted by Denis Bredelet <br...@mac.com.INVALID>.
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 <sc...@yahoo.co.uk.INVALID> 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 <da...@gmail.com> 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
> <sc...@yahoo.co.uk.invalid> 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 <da...@gmail.com> 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
>> <sc...@yahoo.co.uk.invalid> 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 <sc...@yahoo.co.uk.invalid> 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
>
>
>
> --
> Best regards,
> Daniel Dekany
Re: 2.3.33 pre-vote testing
Posted by Simon Hartley <sc...@yahoo.co.uk.INVALID>.
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 <da...@gmail.com> 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
<sc...@yahoo.co.uk.invalid> 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 <da...@gmail.com> 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
> <sc...@yahoo.co.uk.invalid> 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 <sc...@yahoo.co.uk.invalid> 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
--
Best regards,
Daniel Dekany
Re: 2.3.33 pre-vote testing
Posted by Daniel Dekany <da...@gmail.com>.
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
<sc...@yahoo.co.uk.invalid> 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 <da...@gmail.com> 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
> <sc...@yahoo.co.uk.invalid> 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 <sc...@yahoo.co.uk.invalid> 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
--
Best regards,
Daniel Dekany
Re: 2.3.33 pre-vote testing
Posted by Simon Hartley <sc...@yahoo.co.uk.INVALID>.
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 <da...@gmail.com> 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
<sc...@yahoo.co.uk.invalid> 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 <sc...@yahoo.co.uk.invalid> 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
Posted by Daniel Dekany <da...@gmail.com>.
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
<sc...@yahoo.co.uk.invalid> 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 <sc...@yahoo.co.uk.invalid> 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
Posted by Simon Hartley <sc...@yahoo.co.uk.INVALID>.
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 <sc...@yahoo.co.uk.invalid> 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
Posted by Simon Hartley <sc...@yahoo.co.uk.INVALID>.
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 <da...@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
Re: 2.3.33 pre-vote testing
Posted by Daniel Dekany <da...@gmail.com>.
> 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
<sc...@yahoo.co.uk.invalid> 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 <da...@gmail.com> 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
Posted by Simon Hartley <sc...@yahoo.co.uk.INVALID>.
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 <da...@gmail.com> 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
Posted by Daniel Dekany <da...@gmail.com>.
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 <da...@gmail.com> 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:
>
> <repository>
> <id>apache-snapshot-repository</id>
> <url>https://repository.apache.org/content/repositories/snapshots/</url>
> <releases><enabled>false</enabled></releases>
> <snapshots><enabled>true</enabled></snapshots>
> </repository>
>
> (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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <da...@gmail.com> 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
>> <ja...@les7arts.com> 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 <ch...@gmail.com> wrote:
>>>>>> No regressions in our test suite.
>>>>>>
>>>>>> Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany <
>>>>>> daniel.dekany@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:
>>>>>>>
>>>>>>> <repository>
>>>>>>> <id>apache-snapshot-repository</id>
>>>>>>> <url>
>>>>>>> https://repository.apache.org/content/repositories/snapshots/</url>
>>>>>>> <releases><enabled>false</enabled></releases>
>>>>>>> <snapshots><enabled>true</enabled></snapshots>
>>>>>>> </repository>
>>>>>>>
>>>>>>> (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
Posted by Daniel Dekany <da...@gmail.com>.
Fix published to the snapshot repo.
On Wed, Apr 10, 2024 at 2:27 PM Daniel Dekany <da...@gmail.com> 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
> <ja...@les7arts.com> 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 <ch...@gmail.com> wrote:
> > >>> No regressions in our test suite.
> > >>>
> > >>> Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany <
> > >>> daniel.dekany@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:
> > >>>>
> > >>>> <repository>
> > >>>> <id>apache-snapshot-repository</id>
> > >>>> <url>
> > >>>> https://repository.apache.org/content/repositories/snapshots/</url>
> > >>>> <releases><enabled>false</enabled></releases>
> > >>>> <snapshots><enabled>true</enabled></snapshots>
> > >>>> </repository>
> > >>>>
> > >>>> (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
Posted by Daniel Dekany <da...@gmail.com>.
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
<ja...@les7arts.com> 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 <ch...@gmail.com> wrote:
> >>> No regressions in our test suite.
> >>>
> >>> Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany <
> >>> daniel.dekany@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:
> >>>>
> >>>> <repository>
> >>>> <id>apache-snapshot-repository</id>
> >>>> <url>
> >>>> https://repository.apache.org/content/repositories/snapshots/</url>
> >>>> <releases><enabled>false</enabled></releases>
> >>>> <snapshots><enabled>true</enabled></snapshots>
> >>>> </repository>
> >>>>
> >>>> (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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <ch...@gmail.com> wrote:
>>> No regressions in our test suite.
>>>
>>> Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany <
>>> daniel.dekany@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:
>>>>
>>>> <repository>
>>>> <id>apache-snapshot-repository</id>
>>>> <url>
>>>> https://repository.apache.org/content/repositories/snapshots/</url>
>>>> <releases><enabled>false</enabled></releases>
>>>> <snapshots><enabled>true</enabled></snapshots>
>>>> </repository>
>>>>
>>>> (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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <ch...@gmail.com> wrote:
>> No regressions in our test suite.
>>
>> Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany <
>> daniel.dekany@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:
>>>
>>> <repository>
>>> <id>apache-snapshot-repository</id>
>>> <url>
>>> https://repository.apache.org/content/repositories/snapshots/</url>
>>> <releases><enabled>false</enabled></releases>
>>> <snapshots><enabled>true</enabled></snapshots>
>>> </repository>
>>>
>>> (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
Posted by Daniel Dekany <da...@gmail.com>.
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 <ch...@gmail.com> wrote:
>
> No regressions in our test suite.
>
> Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany <
> daniel.dekany@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:
> >
> > <repository>
> > <id>apache-snapshot-repository</id>
> > <url>
> > https://repository.apache.org/content/repositories/snapshots/</url>
> > <releases><enabled>false</enabled></releases>
> > <snapshots><enabled>true</enabled></snapshots>
> > </repository>
> >
> > (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
Posted by Christoph Rueger <ch...@gmail.com>.
No regressions in our test suite.
Am Do., 7. März 2024 um 18:58 Uhr schrieb Daniel Dekany <
daniel.dekany@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:
>
> <repository>
> <id>apache-snapshot-repository</id>
> <url>
> https://repository.apache.org/content/repositories/snapshots/</url>
> <releases><enabled>false</enabled></releases>
> <snapshots><enabled>true</enabled></snapshots>
> </repository>
>
> (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
>