This is an automated email from the ASF dual-hosted git repository.
ddekany pushed a commit to branch 2.3-gae
in repository https://gitbox.apache.org/repos/asf/freemarker.git
commit 8050768b35b0dab051e4eb18a083b239e4e104bd
Author: ddekany <ddek...@apache.org>
AuthorDate: Fri Jan 6 19:44:46 2023 +0100
Version history improvements
---
src/manual/en_US/book.xml | 61 +++++++++++++++++++++++++----------------------
1 file changed, 32 insertions(+), 29 deletions(-)
diff --git a/src/manual/en_US/book.xml b/src/manual/en_US/book.xml
index 675fad2c..c1124a0a 100644
--- a/src/manual/en_US/book.xml
+++ b/src/manual/en_US/book.xml
@@ -30147,16 +30147,17 @@ TemplateModel x = env.getVariable("x"); // get
variable x</programlisting>
<programlisting role="output">"fullName":
null,</programlisting>
- <para>Note with this approach you don't complicate the
+ <para>Note that with this approach you don't complicate the
template anymore to avoid printing quotation marks. Of
course, <literal>?cn</literal> works on numerical and
- boolean values as well.</para>
+ boolean values as well (and of course those won't be quoted,
+ only strings).</para>
</listitem>
<listitem>
- <para><literal>c_format</literal>-s which are not merely for
- backward compatibility, the number formatting changes
- relatively to how <literal>?c</literal> did it in earlier
+ <para><literal>c_format</literal>-s other than
+ <literal>"legacy"</literal> use slightly different number
+ formatting than <literal>?c</literal> did in earlier
versions. The change affects some non-whole numbers, and
whole numbers with over 100 digits. The goal of this change
is to make the formatting lossless, and also to avoiding
@@ -30168,12 +30169,14 @@ TemplateModel x = env.getVariable("x"); // get
variable x</programlisting>
<para>Setting the <link
linkend="pgui_config_incompatible_improvements_how_to_set"><literal>incompatible_improvements</literal>
setting</link> to 2.3.32 will change the default of
- <literal>c_format</literal> to <literal>"JavaScript or
- JSON"</literal>, which has these number formatting changes
- (just like all <literal>c_format</literal>-s that aren't
- just to emulate old behavior have). But this only affects
- number formatting done with <literal>?c</literal>,
- <literal>?cn</literal>, and with <quote>c</quote>
+ <literal>c_format</literal> for <literal>"legacy"</literal>
+ to <literal>"JavaScript or JSON"</literal>, and therefore
+ changes number formatting too.</para>
+
+ <para>Of course, all this only affects number formatting
+ done with <literal>?c</literal>, <literal>?cn</literal>, and
+ with <literal>"c"</literal> (or
+ <literal>"computer"</literal>)
<literal>number_format</literal>, and not number formatting
in general.</para>
</listitem>
@@ -30238,11 +30241,11 @@ TemplateModel x = env.getVariable("x"); // get
variable x</programlisting>
returns a
<literal>freemarker.core.TemplateNumberFormat</literal>, and
deprecated <literal>getCNumberFormat()</literal> that returns a
- <literal>java.text.NumberFormat</literal>. The new
- <literal>?c</literal> behavior (see earlier) is only reflected
- by the new method, and what the deprecated methods returns is
- stuck at 2.3.31 <literal>incompatible_improvements</literal>
- mode.</para>
+ <literal>java.text.NumberFormat</literal>. The behavior defined
+ in the <literal>CFormat</literal> (see earlier) is only
+ reflected exactly by the return value of the new method. The
+ deprecated method returns a format that's a best effort
+ approximation.</para>
</listitem>
<listitem>
@@ -30258,6 +30261,15 @@ TemplateModel x = env.getVariable("x"); // get
variable x</programlisting>
PR 83</link>)</para>
</listitem>
+ <listitem>
+ <para>Fixed performance bug with XML processing
+ (<literal>freemarker.ext.dom</literal>) when converting an XML
+ element that contains lots of text nodes (instead of a single
+ big text node) to a string. (<link
+ xlink:href="https://github.com/apache/freemarker/pull/82";>GitHub
+ PR 82</link>)</para>
+ </listitem>
+
<listitem>
<para>Improved <literal>StringUtil.jsStringEnc</literal> and
<literal>javaSctringEnc</literal> to support quoting. Also
@@ -30270,7 +30282,7 @@ TemplateModel x = env.getVariable("x"); // get
variable x</programlisting>
<para><link
xlink:href="https://issues.apache.org/jira/browse/FREEMARKER-198";>FREEMARKER-198</link>:
Fixed possible deadlock when the
- <literal>Configuration</literal> and
+ <literal>Configuration</literal>, and
<literal>DefaultObjectWrapper</literal> class
<emphasis>static</emphasis> initialization is triggered in
different threads around the same time. (In the very unlikely
@@ -30285,24 +30297,15 @@ TemplateModel x = env.getVariable("x"); // get
variable x</programlisting>
xlink:href="https://issues.apache.org/jira/browse/FREEMARKER-190";>FREEMARKER-190</link>:
Updated dom4j version used during FreeMarker project compilation
from 1.3 to 2.1.3. Users can still use FreeMarker with dom4j 1.3
- (mostly just luck, but it works), also anyway almost nobody uses
- FreeMarker's dom4j support (which is long deprecated). We were
- forced to do this change because old dom4j versions have
+ (mostly just luck, but it works). FreeMarker's dom4j support is
+ long deprecated anyway, and almost nobody uses it anyway. We
+ were forced to do this change because old dom4j versions have
security vulnerabilities, and although FreeMarker is not
affected by them (like we do not pull in dom4j as dependency
into the projects of our users), we were flagged as vulnerable
at certain places for merely supporting 1.3.</para>
</listitem>
- <listitem>
- <para>Fixed performance bug with XML processing
- (<literal>freemarker.ext.dom</literal>) when converting an XML
- element that contains lots of text nodes (instead of a single
- big text node) to a string. (<link
- xlink:href="https://github.com/apache/freemarker/pull/82";>GitHub
- PR 82</link>)</para>
- </listitem>
-
<listitem>
<para>Slightly improved
<literal>DefaultMemberAccessPolicy-rules</literal> (used by
