-
Epic
-
Resolution: Done
-
High
-
None
-
Make class loading predictable
Our original Binding implementation made few assumptions as to what would be a valid access – essentially allowing anything to happen and attempting to do something sane. This really papered over a number of races in the system, which should have been solved via proper lifecycle rather than trying to fudge things.
One example is the Augmentable's inability to list all present augmentations, for which we have a separate AugmentationHolder interface. This design is driven by the need to have a Class which needs to be mapped – and that Class would then be introspected, its models found and if you squint just right, you could arrive at a decision that yeah, I can represent this data as that class.
We have fleshed out our lifecycle in OSGi, which is the only dynamic environment we support, so that there is a capture of schema/ClassLoader interplay – which means we do not have to fudge anything, we just propagate it as a wiring problem. We are still to see a problem with this approach.
One key benefit is that class loading (and unloading) is predictable and therefore we should ditch legacy complexities.