[
https://issues.apache.org/jira/browse/SLING-7319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved SLING-7319.
-------------------------------
Resolution: Fixed
Done in
https://github.com/apache/sling-org-apache-sling-commons-classloader/commit/5a8e15390770a158ed310a600b965233af80b85f
> Dynamic classloader should bootdelegate sun.reflect and jdk.internal.reflect
> -----------------------------------------------------------------------------
>
> Key: SLING-7319
> URL: https://issues.apache.org/jira/browse/SLING-7319
> Project: Sling
> Issue Type: Bug
> Components: Commons
> Affects Versions: Commons ClassLoader 1.4.0
> Reporter: Karl Pauls
> Assignee: Karl Pauls
> Fix For: Commons ClassLoader 1.4.2
>
>
> On java < 9 use of reflection can lead to accessor classes being magically
> generated in the sun.reflect namespace. On java >= 9, the same can happen but
> this time, inside the jdk.internal.reflect namespace. This posses a problem
> for classloaders that don't delegate to the system classloader.
> In case of the commons classloader, we right now delegate this somewhat
> implicitly via the bundle.loadClass don in the BundleProxyClassloader (it
> happens if the framework bootdelegates sun.reflect - which is the case for
> sling). However, in case of java9 we don't bootdelegate jdk.internal.reflect
> - hence, NCDF can happen after a while.
> Granted, one option would be to bootdelegate jdk.internal.reflect as well via
> the framework but in general, it seems the better option to just bootdelegate
> in the commons classloader directly (that makes it independent of the
> framework configuration).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
