Program: 15670
Project: 15670
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. But if you develop a new application with, say, 2.3.21, it's probably a good idea to set this from 2.3.0 to 2.3.21. As far as the 1st and 2nd version number remains, these changes are always very low-risk changes, so usually they don't break anything in older applications either. <p>This setting doesn't affect some important non-backward compatible security fixes; they are always enabled, regardless of what you set here. <p>Incrementing this setting is a good way of preparing for the next minor (2nd) or major (1st) version number increases. When that happens, it's possible that some old behavior become unsupported, that is, even if you set this setting to a low value, it might wont bring back the old behavior anymore. <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. </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}'></tt>) instead of plain quotation mark (<tt>&lt;foo bar="${val}"></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#getResult()}. 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> 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> </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. But if you develop a new application with, say, 2.3.21, it's probably a good idea to set this from 2.3.0 to 2.3.21. As far as the 1st and 2nd version number remains, these changes are always very low-risk changes, so usually they don't break anything in older applications either. <p>This setting doesn't affect some important non-backward compatible security fixes; they are always enabled, regardless of what you set here. <p>Incrementing this setting is a good way of preparing for the next minor (2nd) or major (1st) version number increases. When that happens, it's possible that some old behavior become unsupported, that is, even if you set this setting to a low value, it might wont bring back the old behavior anymore. <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. </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}'></tt>) instead of plain quotation mark (<tt>&lt;foo bar="${val}"></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#getResult()}. 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> 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> </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();
}