[
https://issues.apache.org/jira/browse/JEXL-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17080644#comment-17080644
]
Henri Biestro commented on JEXL-329:
As much as possible, JEXL tries to be a good platform - and memory - citizen
even wrt class loading by keeping the exterior world softly reachable .
The customary contract when supplying a class loader to JEXL is that its
lifecycle is under *your* control; JEXL is definitely *not* the owner of any
class loader - considered as a system/provided resource - , it merely
references it and uses it in a unobtrusive way so you can change it. This still
does seem like proper behavior.
If you ever need to change the class loader instance, you call
JexlEngine.setClassLoader and JEXL will not preclude the now old version to be
GCed along its loaded classes. The script cache is cleared and it is also soft
ref-ed for the same reason.
Furthermore, scripts instances themselves detect class loader changes (when
they are not the same as the Uberspect) in which case their cached
Jexl{Getter,Setter,Method,...} are cleared and re-introspection through new
class loader performed; useful when JexlScript themselves are made members of
other classes.
Since the Uberspect can be used on its own, it follows the same unobtrusive
access to your provided class loader so soft ref it is. And since the
Introspector is also soft ref-ed (it caches a lot of info), it may be necessary
to recreate it which requires the class loader held by the Uberspect.
This has been used to implement automatic reloading of JEXL namespace libraries
in a (closed source) server. (thread owning a watch service on a directory used
to instantiate a class loader on that directory, JEXL using that class loader).
And this soft-referencing as proved efficient at avoiding class loading memory
leaks.
> Uberspect may loose its Classloader
> ---
>
> Key: JEXL-329
> URL: https://issues.apache.org/jira/browse/JEXL-329
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
>
> In the current implementation Uberspect keeps references to its Introspector
> and ClassLoader via SoftReference. This means that when memory is short it
> can loose not only Introspector reference, which is OK, but also ClassLoader
> that was specified for resolving constructors, which looks like a bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
