Program: 15629
Project: 15629
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>The setting value is the FreeMarker version number where the bugfixes/improvements to enable were already implemented (but possibly wasn't active by default, as that would break backward-compatibility). <p>The default value is 2.3.0 for maximum backward-compatibility when upgrading  {@code freemkarer.jar} under anexisting application. For actively developed applications usually you should set this to the highest possible value where the 1st or 2nd version is still the same as in the version where you have started development. As far as the 1st and 2nd version number remains, these changes are always very low-risk, so usually they don't break anything. Of course, you are still encouraged to read the list of changes below. <p>Note that at FreeMarker 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. <p>This setting doesn't affect important not-fully-backward compatible security fixes; they are always enabled, regardless of what you set 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> </ul>
 * @throws IllegalArgumentException if {@code incompatibleImmprovements} is greater than the current FreeMarkerversion, or less than 2.3.0.
 * @since 2.3.21
 */
public Configuration(Version incompatibleImprovements){
  super(incompatibleImprovements);
  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>The setting value is the FreeMarker version number where the bugfixes/improvements to enable were already implemented (but possibly wasn't active by default, as that would break backward-compatibility). <p>The default value is 2.3.0 for maximum backward-compatibility when upgrading  {@code freemkarer.jar} under anexisting application. For actively developed applications usually you should set this to the highest possible value where the 1st or 2nd version is still the same as in the version where you have started development. As far as the 1st and 2nd version number remains, these changes are always very low-risk, so usually they don't break anything. Of course, you are still encouraged to read the list of changes below. <p>Note that at FreeMarker 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. <p>This setting doesn't affect important not-fully-backward compatible security fixes; they are always enabled, regardless of what you set 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>  {@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 where  {@code #nested} "returns" to. Thus, the parent of {@link Environment} will be nowalways 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 all this only matters if you have set settings directly on  {@link Template} objects, and almostnobody does that. Also note that macro calls have never changed the  {@link Environment} parent to the{@link Template} that contains the macro definition, so there's no change there.   </li> </ul> </li> </ul>
 * @throws IllegalArgumentException if {@code incompatibleImmprovements} is greater than the current FreeMarkerversion, or less than 2.3.0.
 * @since 2.3.21
 */
public Configuration(Version incompatibleImprovements){
  super(incompatibleImprovements);
  NullArgumentException.check("String_Node_Str",incompatibleImprovements);
  this.incompatibleImprovements=incompatibleImprovements;
  createTemplateCache();
  loadBuiltInSharedVariables();
}