Program: 15520
Project: 15520
Buggy source:
/** 
 * Creates a new instance and sets which of the non-backward-compatible bugfixes/improvements should be enabled. Note that the specified versions corresponds to the   {@code incompatible_improvements} configuration setting, andcan be changed later, with  {@link #setIncompatibleImprovements(Version)} for example. <p><b>About the "incompatible improvements" setting</b> <p>This setting value is the FreeMarker version number where the not 100% backward compatible bug fixes and improvements that you want to enable were already implemented. In new projects you should set this to the FreeMarker version that you are actually using. In older projects it's also usually better to keep this high, however you better check the changes activated (find them below), at least if not only the 3rd version number (the micro version) of  {@code incompatibleImprovements} is increased. Generally, as far as you only increase thelast version number of this setting, the changes are always low risk. The default value is 2.3.0 to maximize backward compatibility, but that value isn't recommended. <p>Bugfixes and improvements that are fully backward compatible, also those that are important security fixes, are enabled regardless of the incompatible improvements setting. <p>An important consequence of setting this setting is that now your application will check if the stated minimum FreeMarker version requirement is met. Like if you set this setting to 2.3.22, but accidentally the application is deployed with FreeMarker 2.3.21, then FreeMarker will fail, telling that a higher version is required. After all, the fixes/improvements you have requested aren't available on a lower version. <p>Note that as FreeMarker's minor (2nd) or major (1st) version number increments, it's possible that emulating some of the old bugs will become unsupported, that is, even if you set this setting to a low value, it silently wont bring back the old behavior anymore. Information about that will be present here. <p>Currently the effects of this setting are: <ul> <li><p> 2.3.0: This is the lowest supported value, the version used in older projects. This is the default in the FreeMarker 2.3.x series. </li> <li><p> 2.3.19 (or higher): Bug fix: Wrong  {@code #} tags were printed as static text instead ofcausing parsing error when there was no correct  {@code #} or {@code @} tag earlier in thesame template. </li> <li><p> 2.3.20 (or higher):  {@code ?html} will escape apostrophe-quotes just like {@code ?xhtml} does. Utilizingthis is highly recommended, because otherwise if interpolations are used inside attribute values that use apostrophe-quotation (<tt>&lt;foo bar='${val}'&gt;</tt>) instead of plain quotation mark (<tt>&lt;foo bar="${val}"&gt;</tt>), they might produce HTML/XML that's not well-formed. Note that {@code ?html} didn't do this because long ago there was no cross-browser way of doing this, but it's not aconcern anymore. </li> <li><p> 2.3.21 (or higher): <ul> <li><p> The <em>default</em> of the  {@code object_wrapper} setting ({@link #getObjectWrapper()}) changes from  {@link ObjectWrapper#DEFAULT_WRAPPER} to another almost identical {@link DefaultObjectWrapper} singleton,returned by  {@link DefaultObjectWrapperBuilder#build()}. The new default object wrapper's "incompatible improvements" version is set to the same as of the   {@link Configuration}. See   {@link BeansWrapper#BeansWrapper(Version)} for further details. Furthermore, the new defaultobject wrapper doesn't allow changing its settings; setter methods throw  {@link IllegalStateException}). (If anything tries to call setters on the old default in your application, that's a dangerous bug that won't remain hidden now. As the old default is a singleton too, potentially shared by independently developed components, most of them expects the out-of-the-box behavior from it (and the others are necessarily buggy). Also, then concurrency glitches can occur (and even pollute the class introspection cache) because the singleton is modified after publishing to other threads.) Furthermore the new default object wrapper shares class introspection cache with other  {@link BeansWrapper}-s created with   {@link BeansWrapperBuilder}, which has an impact as  {@link BeansWrapper#clearClassIntrospecitonCache()} will be disallowed; see more about it there.</li> <li><p> The  {@code ?iso_...} built-ins won't show the time zone offset for {@link java.sql.Time} values anymore,because most databases store time values that aren't in any time zone, but just store hour, minute, second, and decimal second field values. If you still want to show the offset (like for PostgreSQL "time with time zone" columns you should), you can force showing the time zone offset by using {@code myTime?string.iso_fz} (and its other variants).</li> <li><p> {@code ?is_enumerable} correctly returns {@code false} for Java methods get from Java objects thatare wrapped with  {@link BeansWrapper} and its subclasses, like {@link DefaultObjectWrapper}. Although method values implement   {@link TemplateSequenceModel} (because of a historical design quirk in{@link BeansWrapper}), trying to   {@code #list} them will cause error, hence they aren't enumerable.</li> <li><p> {@code ?c} will return {@code "INF"},   {@code "-INF"} and {@code "NaN"} for positive/negative infinityand IEEE floating point Not-a-Number, respectively. These are the XML Schema compatible representations of these special values. Earlier it has returned what  {@link DecimalFormat} did with US locale, none ofwhich was understood by any (common) computer language. </li> <li><p> FTL hash literals that repeat keys now only have the key once with  {@code ?keys}, and only has the last value associated to that key with   {@code ?values}. This is consistent with the behavior of  {@code hash[key]} and how maps work in Java.       </li> <li><p>In most cases (where FreeMarker is able to do that), for  {@link TemplateLoader}-s that use  {@link URLConnection},   {@code URLConnection#setUseCaches(boolean)} will called with {@code false}, so that only FreeMarker will do caching, not the URL scheme's handler. See   {@link URLTemplateLoader#setURLConnectionUsesCaches(Boolean)} for more details.</li> <li><p> The default of the  {@code template_loader} setting ({@link Configuration#getTemplateLoader()}) changes to   {@code null}, which means that FreeMarker will not find any templates. Earlier the default was a   {@link FileTemplateLoader} that used the current directory as the root. This wasdangerous and fragile as you usually don't have good control over what the current directory will be. Luckily, the old default almost never looked for the templates at the right place anyway, so pretty much all applications had to set the  {@code template_loader} setting, so it's unlikelythat changing the default breaks your application. </li> <li><p> Right-unlimited ranges become readable (like listable), so  {@code <#list 1.. as i>...</#list>} works.Earlier they were only usable for slicing (like  {@code hits[10..]}). </li> <li><p> Empty ranges return   {@link Constants#EMPTY_SEQUENCE} instead of an empty {@link SimpleSequence}. This is in theory backward compatible, as the API only promises to give something that implements  {@link TemplateSequenceModel}. </li> <li><p> Unclosed comments (  {@code <#-- ...}) and   {@code #noparse}-s won't be silently closed at the end of template anymore, but cause a parsing error instead. </li> </ul> </li> <li><p> 2.3.22 (or higher): <ul> <li><p>  {@link DefaultObjectWrapper} has some substantial changes with {@code incompatibleImprovements} 2.3.22;check them out at  {@link DefaultObjectWrapper#DefaultObjectWrapper(Version)}. It's important to know that if you set the   {@code object_wrapper} setting (to an other value than {@code "default"}), rather than leaving it on its default value, the   {@code object_wrapper} won't inherit the{@code incompatibleImprovements} of the {@link Configuration}. In that case, if you want the 2.3.22 improvements of   {@link DefaultObjectWrapper}, you have to set it in the   {@link DefaultObjectWrapper}object itself too! (Note that it's OK to use a   {@link DefaultObjectWrapper} with a different{@code incompatibleImprovements} version number than that of the {@link Configuration}, if that's really what you want.) </li> <li><p> In templates,   {@code .template_name} will <em>always</em> return the main (top level) template's name.It won't be affected by  {@code #include} and {@code #nested} anymore. This is unintended, a bug with{@code incompatible_improvement} 2.3.22 (a consequence of the lower level fixing described in the nextpoint). The old behavior of  {@code .template_name} is restored if you set{@code incompatible_improvement} to 2.3.23 (while {@link Configurable#getParent()}) of  {@link Environment} keeps the changed behavior shown in the next point). </li> <li><p> {@code #include} and {@code #nested} doesn't change the parent {@link Template} (see{@link Configurable#getParent()}) of the   {@link Environment} anymore to the {@link Template} that'sincluded or whose namespace  {@code #nested} "returns" to. Thus, the parent of {@link Environment} willbe now always the main  {@link Template}. (The main   {@link Template} is the {@link Template} whose{@code process} or {@code createProcessingEnvironment} method was called to initiate the outputgeneration.) Note that apart from the effect on FTL's  {@code .template_name} (seeprevious point), this should only matter if you have set settings directly on  {@link Template} objects,and almost nobody does that. Also note that macro calls have never changed the  {@link Environment}parent to the   {@link Template} that contains the macro definition, so this mechanism was always broken.As now we consistently never change the parent, the behavior when calling macros didn't change. </li> <li><p> When using  {@code freemarker.ext.servlet.FreemarkerServlet}: <ul> <li> <p>When using custom JSP tag libraries: Fixes bug where some kind of values, when put into the JSP <em>page</em> scope (via   {@code #global} or via the JSP{@code PageContext} API) and later read back with the JSP {@code PageContext} API (typically in acustom JSP tag), might come back as FreeMarker  {@link TemplateModel} objects instead of as objectswith a standard Java type. Other Servlet scopes aren't affected. It's highly unlikely that something expects the presence of this bug. The affected values are of the FTL types listed below, and to trigger the bug, they either had to be created directly in the template (like as an FTL literal or with  {@code ?date}/  {@code time}/  {@code datetime}), or you had to use  {@link DefaultObjectWrapper} or {@link SimpleObjectWrapper} (or a subclass of them):<ul> <li>FTL date/time/date-time values may came back as  {@link SimpleDate}-s, now they come back as  {@link java.util.Date java.util.Date}-s instead.</li> <li>FTL sequence values may came back as   {@link SimpleSequence}-s, now they come back as  {@link java.util.List}-s as expected. This at least stands assuming that the  {@link Configuration#setSetting(String,String) object_wrapper} configuration setting is asubclass of  {@link BeansWrapper} (such as {@link DefaultObjectWrapper}, which is the default), but that's practically always the case in applications that use FreeMarker's JSP extension (otherwise it can still work, but it depends on the quality and capabilities of the  {@link ObjectWrapper} implementation).</li><li>FTL hash values may came back as  {@link SimpleHash}-es, now they come back as  {@link java.util.Map}-s as expected (again, assuming that the object wrapper is a subclass of  {@link BeansWrapper}, like preferably   {@link DefaultObjectWrapper}, which is also the default). </li> <li>FTL collection values may came back as   {@link SimpleCollection}-s, now they come back as  {@link java.util.Collection}-s as expected (again, assuming that the object wrapper is a subclass of   {@link BeansWrapper}, like preferably   {@link DefaultObjectWrapper}).</li> </ul> </li> <li><p> Initial   {@code "["} in the {@code TemplatePath} init-paramhas special meaning; it's used for specifying multiple comma separated locations, like in {@code <param-value>[ WEB-INF/templates, classpath:com/example/myapp/templates ]</param-value>}</li> <li><p> Initial <tt>"{"</tt> in the   {@code TemplatePath} init-param is reserved for future purposes, andthus will throw exception. </li> </ul> </li> </ul> </li> <li><p> 2.3.23 (or higher): <ul> <li><p> Fixed a loophole in the implementation of the long existing parse-time rule that says that {@code #break}, in the FTL source code itself, must occur nested inside a breakable directive, such as  {@code #list} or {@code #switch}. This check could be circumvented with   {@code #macro} or{@code #function}, like this:  {@code <#list 1..1 as x><#macro callMeLater><#break></#macro></#list><@callMeLater />}. After activating this fix, this will be a parse time error. </li> <li><p> If you have used   {@code incompatible_improvements} 2.3.22 earlier, know that there the behavior of the{@code .template_name} special variable used in templates was accidentally altered, but now it'srestored to be backward compatible with 2.3.0. (Ironically, the restored legacy behavior itself is broken when it comes to macro invocations, we just keep it for backward compatibility. If you need fixed behavior, use  {@code .current_template_name} or {@code .main_template_name} instead.)</li> </ul> </li> <li><p> 2.3.24 (or higher): <ul> <li><p> Templates whose name ends with  {@code ftlh} "file" extension will automatically get{@link HTMLOutputFormat#INSTANCE} output format, and those with {@code ftlx} extensionautomatically get  {@link XMLOutputFormat#INSTANCE} output format. (See:{@link #setOutputFormat(OutputFormat)}, in both cases with  {@link #setAutoEscaping(boolean) auto_escaping} on. (These can be overridden with{@link #setTemplateConfigurers(TemplateConfigurerFactory) template_configurers}.) The "file" extensions aren't case sensitive. </li> </ul> </li> </ul>
 * @throws IllegalArgumentException If  {@code incompatibleImmprovements} refers to a version that wasn't released yet when the currentlyused FreeMarker version was released, or is less than 2.3.0, or is  {@code null}.
 * @since 2.3.21
 */
public Configuration(Version incompatibleImprovements){
  super(incompatibleImprovements);
  checkFreeMarkerVersionClash();
  NullArgumentException.check("String_Node_Str",incompatibleImprovements);
  this.incompatibleImprovements=incompatibleImprovements;
  createTemplateCache();
  loadBuiltInSharedVariables();
}

Fixed version (ground truth):
/** 
 * Creates a new instance and sets which of the non-backward-compatible bugfixes/improvements should be enabled. Note that the specified versions corresponds to the   {@code incompatible_improvements} configuration setting, andcan be changed later, with  {@link #setIncompatibleImprovements(Version)} for example. <p><b>About the "incompatible improvements" setting</b> <p>This setting value is the FreeMarker version number where the not 100% backward compatible bug fixes and improvements that you want to enable were already implemented. In new projects you should set this to the FreeMarker version that you are actually using. In older projects it's also usually better to keep this high, however you better check the changes activated (find them below), at least if not only the 3rd version number (the micro version) of  {@code incompatibleImprovements} is increased. Generally, as far as you only increase thelast version number of this setting, the changes are always low risk. The default value is 2.3.0 to maximize backward compatibility, but that value isn't recommended. <p>Bugfixes and improvements that are fully backward compatible, also those that are important security fixes, are enabled regardless of the incompatible improvements setting. <p>An important consequence of setting this setting is that now your application will check if the stated minimum FreeMarker version requirement is met. Like if you set this setting to 2.3.22, but accidentally the application is deployed with FreeMarker 2.3.21, then FreeMarker will fail, telling that a higher version is required. After all, the fixes/improvements you have requested aren't available on a lower version. <p>Note that as FreeMarker's minor (2nd) or major (1st) version number increments, it's possible that emulating some of the old bugs will become unsupported, that is, even if you set this setting to a low value, it silently wont bring back the old behavior anymore. Information about that will be present here. <p>Currently the effects of this setting are: <ul> <li><p> 2.3.0: This is the lowest supported value, the version used in older projects. This is the default in the FreeMarker 2.3.x series. </li> <li><p> 2.3.19 (or higher): Bug fix: Wrong  {@code #} tags were printed as static text instead ofcausing parsing error when there was no correct  {@code #} or {@code @} tag earlier in thesame template. </li> <li><p> 2.3.20 (or higher):  {@code ?html} will escape apostrophe-quotes just like {@code ?xhtml} does. Utilizingthis is highly recommended, because otherwise if interpolations are used inside attribute values that use apostrophe-quotation (<tt>&lt;foo bar='${val}'&gt;</tt>) instead of plain quotation mark (<tt>&lt;foo bar="${val}"&gt;</tt>), they might produce HTML/XML that's not well-formed. Note that {@code ?html} didn't do this because long ago there was no cross-browser way of doing this, but it's not aconcern anymore. </li> <li><p> 2.3.21 (or higher): <ul> <li><p> The <em>default</em> of the  {@code object_wrapper} setting ({@link #getObjectWrapper()}) changes from  {@link ObjectWrapper#DEFAULT_WRAPPER} to another almost identical {@link DefaultObjectWrapper} singleton,returned by  {@link DefaultObjectWrapperBuilder#build()}. The new default object wrapper's "incompatible improvements" version is set to the same as of the   {@link Configuration}. See   {@link BeansWrapper#BeansWrapper(Version)} for further details. Furthermore, the new defaultobject wrapper doesn't allow changing its settings; setter methods throw  {@link IllegalStateException}). (If anything tries to call setters on the old default in your application, that's a dangerous bug that won't remain hidden now. As the old default is a singleton too, potentially shared by independently developed components, most of them expects the out-of-the-box behavior from it (and the others are necessarily buggy). Also, then concurrency glitches can occur (and even pollute the class introspection cache) because the singleton is modified after publishing to other threads.) Furthermore the new default object wrapper shares class introspection cache with other  {@link BeansWrapper}-s created with   {@link BeansWrapperBuilder}, which has an impact as  {@link BeansWrapper#clearClassIntrospecitonCache()} will be disallowed; see more about it there.</li> <li><p> The  {@code ?iso_...} built-ins won't show the time zone offset for {@link java.sql.Time} values anymore,because most databases store time values that aren't in any time zone, but just store hour, minute, second, and decimal second field values. If you still want to show the offset (like for PostgreSQL "time with time zone" columns you should), you can force showing the time zone offset by using {@code myTime?string.iso_fz} (and its other variants).</li> <li><p> {@code ?is_enumerable} correctly returns {@code false} for Java methods get from Java objects thatare wrapped with  {@link BeansWrapper} and its subclasses, like {@link DefaultObjectWrapper}. Although method values implement   {@link TemplateSequenceModel} (because of a historical design quirk in{@link BeansWrapper}), trying to   {@code #list} them will cause error, hence they aren't enumerable.</li> <li><p> {@code ?c} will return {@code "INF"},   {@code "-INF"} and {@code "NaN"} for positive/negative infinityand IEEE floating point Not-a-Number, respectively. These are the XML Schema compatible representations of these special values. Earlier it has returned what  {@link DecimalFormat} did with US locale, none ofwhich was understood by any (common) computer language. </li> <li><p> FTL hash literals that repeat keys now only have the key once with  {@code ?keys}, and only has the last value associated to that key with   {@code ?values}. This is consistent with the behavior of  {@code hash[key]} and how maps work in Java.       </li> <li><p>In most cases (where FreeMarker is able to do that), for  {@link TemplateLoader}-s that use  {@link URLConnection},   {@code URLConnection#setUseCaches(boolean)} will called with {@code false}, so that only FreeMarker will do caching, not the URL scheme's handler. See   {@link URLTemplateLoader#setURLConnectionUsesCaches(Boolean)} for more details.</li> <li><p> The default of the  {@code template_loader} setting ({@link Configuration#getTemplateLoader()}) changes to   {@code null}, which means that FreeMarker will not find any templates. Earlier the default was a   {@link FileTemplateLoader} that used the current directory as the root. This wasdangerous and fragile as you usually don't have good control over what the current directory will be. Luckily, the old default almost never looked for the templates at the right place anyway, so pretty much all applications had to set the  {@code template_loader} setting, so it's unlikelythat changing the default breaks your application. </li> <li><p> Right-unlimited ranges become readable (like listable), so  {@code <#list 1.. as i>...</#list>} works.Earlier they were only usable for slicing (like  {@code hits[10..]}). </li> <li><p> Empty ranges return   {@link Constants#EMPTY_SEQUENCE} instead of an empty {@link SimpleSequence}. This is in theory backward compatible, as the API only promises to give something that implements  {@link TemplateSequenceModel}. </li> <li><p> Unclosed comments (  {@code <#-- ...}) and   {@code #noparse}-s won't be silently closed at the end of template anymore, but cause a parsing error instead. </li> </ul> </li> <li><p> 2.3.22 (or higher): <ul> <li><p>  {@link DefaultObjectWrapper} has some substantial changes with {@code incompatibleImprovements} 2.3.22;check them out at  {@link DefaultObjectWrapper#DefaultObjectWrapper(Version)}. It's important to know that if you set the   {@code object_wrapper} setting (to an other value than {@code "default"}), rather than leaving it on its default value, the   {@code object_wrapper} won't inherit the{@code incompatibleImprovements} of the {@link Configuration}. In that case, if you want the 2.3.22 improvements of   {@link DefaultObjectWrapper}, you have to set it in the   {@link DefaultObjectWrapper}object itself too! (Note that it's OK to use a   {@link DefaultObjectWrapper} with a different{@code incompatibleImprovements} version number than that of the {@link Configuration}, if that's really what you want.) </li> <li><p> In templates,   {@code .template_name} will <em>always</em> return the main (top level) template's name.It won't be affected by  {@code #include} and {@code #nested} anymore. This is unintended, a bug with{@code incompatible_improvement} 2.3.22 (a consequence of the lower level fixing described in the nextpoint). The old behavior of  {@code .template_name} is restored if you set{@code incompatible_improvement} to 2.3.23 (while {@link Configurable#getParent()}) of  {@link Environment} keeps the changed behavior shown in the next point). </li> <li><p> {@code #include} and {@code #nested} doesn't change the parent {@link Template} (see{@link Configurable#getParent()}) of the   {@link Environment} anymore to the {@link Template} that'sincluded or whose namespace  {@code #nested} "returns" to. Thus, the parent of {@link Environment} willbe now always the main  {@link Template}. (The main   {@link Template} is the {@link Template} whose{@code process} or {@code createProcessingEnvironment} method was called to initiate the outputgeneration.) Note that apart from the effect on FTL's  {@code .template_name} (seeprevious point), this should only matter if you have set settings directly on  {@link Template} objects,and almost nobody does that. Also note that macro calls have never changed the  {@link Environment}parent to the   {@link Template} that contains the macro definition, so this mechanism was always broken.As now we consistently never change the parent, the behavior when calling macros didn't change. </li> <li><p> When using  {@code freemarker.ext.servlet.FreemarkerServlet}: <ul> <li> <p>When using custom JSP tag libraries: Fixes bug where some kind of values, when put into the JSP <em>page</em> scope (via   {@code #global} or via the JSP{@code PageContext} API) and later read back with the JSP {@code PageContext} API (typically in acustom JSP tag), might come back as FreeMarker  {@link TemplateModel} objects instead of as objectswith a standard Java type. Other Servlet scopes aren't affected. It's highly unlikely that something expects the presence of this bug. The affected values are of the FTL types listed below, and to trigger the bug, they either had to be created directly in the template (like as an FTL literal or with  {@code ?date}/  {@code time}/  {@code datetime}), or you had to use  {@link DefaultObjectWrapper} or {@link SimpleObjectWrapper} (or a subclass of them):<ul> <li>FTL date/time/date-time values may came back as  {@link SimpleDate}-s, now they come back as  {@link java.util.Date java.util.Date}-s instead.</li> <li>FTL sequence values may came back as   {@link SimpleSequence}-s, now they come back as  {@link java.util.List}-s as expected. This at least stands assuming that the  {@link Configuration#setSetting(String,String) object_wrapper} configuration setting is asubclass of  {@link BeansWrapper} (such as {@link DefaultObjectWrapper}, which is the default), but that's practically always the case in applications that use FreeMarker's JSP extension (otherwise it can still work, but it depends on the quality and capabilities of the  {@link ObjectWrapper} implementation).</li><li>FTL hash values may came back as  {@link SimpleHash}-es, now they come back as  {@link java.util.Map}-s as expected (again, assuming that the object wrapper is a subclass of  {@link BeansWrapper}, like preferably   {@link DefaultObjectWrapper}, which is also the default). </li> <li>FTL collection values may came back as   {@link SimpleCollection}-s, now they come back as  {@link java.util.Collection}-s as expected (again, assuming that the object wrapper is a subclass of   {@link BeansWrapper}, like preferably   {@link DefaultObjectWrapper}).</li> </ul> </li> <li><p> Initial   {@code "["} in the {@code TemplatePath} init-paramhas special meaning; it's used for specifying multiple comma separated locations, like in {@code <param-value>[ WEB-INF/templates, classpath:com/example/myapp/templates ]</param-value>}</li> <li><p> Initial <tt>"{"</tt> in the   {@code TemplatePath} init-param is reserved for future purposes, andthus will throw exception. </li> </ul> </li> </ul> </li> <li><p> 2.3.23 (or higher): <ul> <li><p> Fixed a loophole in the implementation of the long existing parse-time rule that says that {@code #break}, in the FTL source code itself, must occur nested inside a breakable directive, such as  {@code #list} or {@code #switch}. This check could be circumvented with   {@code #macro} or{@code #function}, like this:  {@code <#list 1..1 as x><#macro callMeLater><#break></#macro></#list><@callMeLater />}. After activating this fix, this will be a parse time error. </li> <li><p> If you have used   {@code incompatible_improvements} 2.3.22 earlier, know that there the behavior of the{@code .template_name} special variable used in templates was accidentally altered, but now it'srestored to be backward compatible with 2.3.0. (Ironically, the restored legacy behavior itself is broken when it comes to macro invocations, we just keep it for backward compatibility. If you need fixed behavior, use  {@code .current_template_name} or {@code .main_template_name} instead.)</li> </ul> </li> <li><p> 2.3.24 (or higher): <ul> <li><p> Templates whose name ends with  {@code ftlh} "file" extension will automatically get{@link HTMLOutputFormat#INSTANCE} output format, and those with {@code ftlx} extensionautomatically get  {@link XMLOutputFormat#INSTANCE} output format. (See:{@link #setOutputFormat(OutputFormat)}, in both cases with  {@link #setAutoEscaping(boolean) auto_escaping} on. (These can be overridden with{@link #setTemplateConfigurers(TemplateConfigurerFactory) template_configurers}.) The "file" extensions aren't case sensitive. </li> <li><p> Expressions inside interpolations that were inside <em>string literal expressions</em> (not <code>${...}</code>-s in general), like in <code>&lt;#assign s="Hello ${name}!"&gt;, has always used   {@code incompatbileImprovement}-s 0 (2.3.0 in effect). </li> </ul> </li> </ul>
 * @throws IllegalArgumentException If  {@code incompatibleImmprovements} refers to a version that wasn't released yet when the currentlyused FreeMarker version was released, or is less than 2.3.0, or is  {@code null}.
 * @since 2.3.21
 */
public Configuration(Version incompatibleImprovements){
  super(incompatibleImprovements);
  checkFreeMarkerVersionClash();
  NullArgumentException.check("String_Node_Str",incompatibleImprovements);
  this.incompatibleImprovements=incompatibleImprovements;
  createTemplateCache();
  loadBuiltInSharedVariables();
}