[
https://issues.apache.org/jira/browse/FREEMARKER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864310#comment-17864310
]
Dániel Dékány edited comment on FREEMARKER-227 at 7/9/24 5:38 PM:
------------------------------------------------------------------
But {{classicCompatibleMode}} {{true}} emulates other odd legacy 1.7.x behavior
as well... And now that I took a closer look, it's quite horrific sometimes.
Like comparisons, if the two types are not compatible, are done by converting
both values to string, and then comparing the strings. I assume because 1.x
only had string type and the container types initially. But it's a very fragile
mechanism combined with 2.x features, as how you convert values to strings
depends on settings like {{number_format}}, {{locale}}, etc. (This wasn't even
properly documented, but I have improved that now.) Also, implicit boolean to
string conversion is by design weird/broken (as in 1.x).
So, can't you get away with the {{TempalteExceptionHandler}} mechanism instead?
was (Author: ddekany):
But {{classicCompatibleMode}} {{true}} emulates other odd legacy 1.7.x behavior
as well... And now that I took a closer look, it's quite horrific sometimes.
Like comparisons, if the two types are not compatible, are done by converting
both values to string, and then comparing the strings. I assume because 1.x
only had string type and the container types initially. But it's a very fragile
mechanism combined with 2.x features, as how you convert values to strings
depends on settings like {{number_format}}, {{locale}}, etc. (This wasn't even
properly documented, but I have improved that now.) So, can't you get away with
the {{TempalteExceptionHandler}} mechanism instead?
> ClassicCompatible setting doesn't work with sequence built-ins as expected
> --------------------------------------------------------------------------
>
> Key: FREEMARKER-227
> URL: https://issues.apache.org/jira/browse/FREEMARKER-227
> Project: Apache Freemarker
> Issue Type: Bug
> Affects Versions: 2.3.30, 2.3.33
> Reporter: Natalia Shashok
> Priority: Major
> Fix For: 2.3.34
>
>
> When turning classic compatible mode to true, usage of seq_contains,
> seq_index_of, seq_last_index_of built-ins becomes unstable.
> Consider the following template:
> <#setting classic_compatible=true>
> <#if eight?seq_contains(1)> </#if>
> If the next values are passed to generate a document:
> eight=[ "2", "1", "3"]
> then generation fails with the following error:
>
> {code:java}
> Expression has thrown an unchecked exception; see the cause exception.The
> blamed expression:==> eight?seq_contains(1) [in nameless template at line 2,
> column 6]
> ----FTL stack trace ("~" means nesting-related): - Failed at: #if
> eight?seq_contains(1) [in nameless template at line 2, column 1]----
> Caused by:java.lang.NullPointerException: null{code}
> After further investigation it was found out that
> 1) seq_ built-ins react badly on integers, whether the integer is actually
> contained within the sequence or not;
> 2) seq_ built-ins work correctly on strings if the strings passed to
> built-ins is contained within the sequence, but will fail with the same
> NullPointerException if the string isn't contained within the sequence;
> 3) it does not matter whether the built-ins are used in conditional
> expressions - it was tested in interpolations as well.
> This behavior was found out in versions 2.3.30 and was tested to be still
> present in 2.3.33.
> Is there any way to mitigate these errors upon using classic_compatible mode?
> Any help would be greatly appreciated.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
