| Interface and Description |
|---|
| freemarker.template.TemplateMethodModel
Use
TemplateMethodModelEx instead. This interface is from the old times when the only kind of
value you could pass in was string. |
| Class and Description |
|---|
| freemarker.template.utility.CaptureOutput
Use block-assignments instead, as
<assign x>...</assign>. |
| freemarker.ext.ant.FreemarkerXmlTask
FMPP is a more complete solution.
|
| freemarker.ext.jdom.NodeListModel
Use
NodeModel instead. |
| freemarker.ext.xml.NodeListModel
Use
NodeModel instead. |
| freemarker.template.SimpleList
Use SimpleSequence instead.
|
| Field and Description |
|---|
| freemarker.template.Configuration.DEFAULT_INCOMPATIBLE_ENHANCEMENTS
Use
Configuration.DEFAULT_INCOMPATIBLE_IMPROVEMENTS instead. |
| freemarker.template.Configuration.INCOMPATIBLE_ENHANCEMENTS
Use
Configuration.INCOMPATIBLE_IMPROVEMENTS instead. |
| freemarker.template.Configuration.PARSED_DEFAULT_INCOMPATIBLE_ENHANCEMENTS
Use
Configuration.DEFAULT_INCOMPATIBLE_IMPROVEMENTS instead. |
| freemarker.core.ParseException.specialConstructor
Will be remove without replacement in 2.4.
|
| Method and Description |
|---|
| freemarker.template.TemplateException.getCauseException()
Use
TemplateException.getCause() instead, as this can't return runtime exceptions and errors as is. |
| freemarker.template.Configuration.getDefaultConfiguration()
The usage of the static singleton (the "default")
Configuration instance can easily cause erroneous, unpredictable
behavior. This is because multiple independent software components may use
FreeMarker internally inside the same application, so they will interfere
because of the common Configuration instance. Each such component
should use its own private Configuration object instead, that it
typically creates with new Configuration() when the component
is initialized. |
| freemarker.template.Configuration.getIncompatibleEnhancements()
Use
Configuration.getIncompatibleImprovements() instead. |
| freemarker.ext.beans.BeansWrapper.getInstance(Object, ModelFactory)
override
BeansWrapper.getModelFactory(Class) instead. Using this
method will now bypass wrapper caching (if it's enabled) and always
result in creation of a new wrapper. This method will be removed in 2.4 |
| freemarker.template.Configuration.getParsedIncompatibleEnhancements()
Use
Configuration.getIncompatibleImprovements() instead. |
| freemarker.core.Configurable.getSetting(String)
This method was always defective, and certainly it always
will be. Don't use it. (Simply, it's hardly possible in general to
convert setting values to text in a way that ensures that
Configurable.setSetting(String, String) will work with them correctly.) |
| freemarker.core.Configurable.getSettings()
This method was always defective, and certainly it always
will be. Don't use it. (Simply, it's hardly possible in general to
convert setting values to text in a way that ensures that
Configurable.setSettings(Properties) will work with them correctly.) |
| freemarker.template.Configuration.getVersionNumber()
Use
Configuration.getVersion() instead. |
| freemarker.template.utility.StringUtil.HTMLEnc(String)
Use
StringUtil.XHTMLEnc(String) instead, because it escapes apostrophe-quote too. |
| freemarker.template.utility.DeepUnwrap.premissiveUnwrap(TemplateModel)
the name of this method is mistyped. Use
DeepUnwrap.permissiveUnwrap(TemplateModel) instead. |
| freemarker.template.Configuration.setDefaultConfiguration(Configuration)
Using the "default"
Configuration instance can
easily lead to erroneous, unpredictable behaviour.
See more here.... |
| freemarker.template.Configuration.setIncompatibleEnhancements(String)
Use
Configuration.setIncompatibleImprovements(Version) instead. |
| freemarker.template.Configuration.setStrictSyntaxMode(boolean)
Only
true (the default) value will be supported sometimes in the future. |