Despite that builders aren't meant to be used as long-lived objects (singletons), the builder is thread-safe after you have stopped calling its setters and it was safely published (see JSR 133) to other threads. This can be useful if you have to put the builder into an IoC container, rather than the singleton it produces.
The main benefit of using a builder instead of a {@link BeansWrapper} constructor is that this way theinternal object wrapping-related caches (most notably the class introspection cache) will come from a global, JVM-level (more precisely, {@code freemarker.jar}-class-loader-level) cache. Also the {@link BeansWrapper} singletonsthemselves are stored in this global cache. Some of the wrapping-related caches are expensive to build and can take significant amount of memory. Using builders, components that use FreeMarker will share {@link BeansWrapper}instances and said caches even if they use separate FreeMarker {@link Configuration}-s. (Many Java libraries use FreeMarker internally, so {@link Configuration} sharing is not an option.)
Note that the returned {@link BeansWrapper} instances are only weak-referenced from inside the builder mechanism,so singletons are garbage collected when they go out of usage, just like non-singletons.
About the object wrapping-related caches:
Class introspection cache: Stores information about classes that once had to be wrapped. The cache is stored in the static fields of certain FreeMarker classes. Thus, if you have two {@link BeansWrapper}instances, they might share the same class introspection cache. But if you have two {@code freemarker.jar}-s (typically, in two Web Application's {@code WEB-INF/lib} directories), those won'tshare their caches (as they don't share the same FreeMarker classes). Also, currently there's a separate cache for each permutation of the property values that influence class introspection: {@link BeansWrapperBuilder#setExposeFields(boolean) expose_fields} and{@link BeansWrapperBuilder#setExposureLevel(int) exposure_level}. So only {@link BeansWrapper} where thoseproperties are the same may share class introspection caches among each other.
Model caches: These are local to a {@link BeansWrapper}. {@link BeansWrapperBuilder} returns the same{@link BeansWrapper} instance for equivalent properties (unless the existing instance was garbage collectedand thus a new one had to be created), hence these caches will be re-used too. {@link BeansWrapper} instancesare cached in the static fields of FreeMarker too, but there's a separate cache for each Thread Context Class Loader, which in a servlet container practically means a separate cache for each Web Application (each servlet context). (This is like so because for resolving class names to classes FreeMarker uses the Thread Context Class Loader, so the result of the resolution can be different for different Thread Context Class Loaders.) The model caches are:
Static model caches: These are used by the hash returned by {@link BeansWrapper#getEnumModels()} and{@link BeansWrapper#getStaticModels()}, for caching {@link TemplateModel}-s for the static methods/fields and Java 5 enums that were accessed through them. To use said hashes, you have to put them explicitly into the data-model or expose them to the template explicitly otherwise, so in most applications these caches aren't unused.
Instance model cache: By default off (see {@link BeansWrapper#setUseCache(boolean)}). Caches the {@link TemplateModel}-s for all Java objects that were accessed from templates.
Note that what this method documentation says about {@link BeansWrapper} also applies to{@link DefaultObjectWrapperBuilder}. @since 2.3.21
| |