You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the {Constructor,Field,Method}Access classes first delegate to AccessClassLoader when an accessor is requested and the ACL in turn delegates to the parent classloader, and generates the accessor if it is not found. ie, it uses the parent class loader as a cache
this can be an expensive operation, eg if the parent classloader is a network loader, and as such is not a very good cache
i submitted a pull request (#51) that works around this by only querying the parent class loader if the accessor has been generated, but it hasn't been commented on or accepted
an alternative would be to identify the accessor classes in the parent classloader and throw an exception there (rather than query the network). however, i don't see a reasonably safe means of identifying generated class names (the naming scheme involves appending "{Constructor,Field,Method}Access" which could well show up in a user class name). i'd be willing to submit a pull request that used more-easily-filtered names if that approach would be preferred (eg EsotericSoftwareOriginalNameFieldAccess), though i prefer the former deterministic approach
The text was updated successfully, but these errors were encountered:
the {Constructor,Field,Method}Access classes first delegate to AccessClassLoader when an accessor is requested and the ACL in turn delegates to the parent classloader, and generates the accessor if it is not found. ie, it uses the parent class loader as a cache
this can be an expensive operation, eg if the parent classloader is a network loader, and as such is not a very good cache
i submitted a pull request (#51) that works around this by only querying the parent class loader if the accessor has been generated, but it hasn't been commented on or accepted
an alternative would be to identify the accessor classes in the parent classloader and throw an exception there (rather than query the network). however, i don't see a reasonably safe means of identifying generated class names (the naming scheme involves appending "{Constructor,Field,Method}Access" which could well show up in a user class name). i'd be willing to submit a pull request that used more-easily-filtered names if that approach would be preferred (eg EsotericSoftwareOriginalNameFieldAccess), though i prefer the former deterministic approach
The text was updated successfully, but these errors were encountered: